Date: Mon, 30 Mar 2015 14:38:12 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Ian Lepore <ian@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Fabien Thomas <fabient@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <551943B4.90102@selasky.org> In-Reply-To: <20150330120700.GH64665@FreeBSD.org> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> <CAJ-VmonU15_nEGVQNwR52deDf1TbPUz0oAMr%2B3zwNqU_9%2Bo1fw@mail.gmail.com> <20150329210757.GA64665@FreeBSD.org> <1427666182.82583.4.camel@freebsd.org> <55190EA7.9010905@selasky.org> <20150330105913.GF64665@FreeBSD.org> <551933AF.4080300@selasky.org> <20150330120700.GH64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/30/15 14:07, Gleb Smirnoff wrote: > Hans, > > On Mon, Mar 30, 2015 at 01:29:51PM +0200, Hans Petter Selasky wrote: > H> You don't get it fully. Every time a CPU runs out of IDs, it allocates a > H> new 256 long series of numbers. That way the CPUs allocate numbers in > H> sequence. > H> > H> > The suggested code suffers from migration more than what I suggested. E.g. > H> > you can assign V_ip_id_start on CPU 1 then migrate to CPU 2 and assign > H> > V_ip_id_end, yielding in the broken state of the ID generating machine. > H> > Or you can compare start and end on different CPUs, which causes less harm. > H> > H> Surely we need to add the critial_enter() and critical_exit() around > H> this code, it is just meant as an example. > > Making the function heavier and heavier, trying to reduce the probability > of an event that already happens naturally orders of magnitude more often, > than we can can trigger it with our code. > > H> > And still the code doesn't protect against full 65k overflow. One CPU > H> > can emit a burst over 65k packets, and then go on and reuse all the IDs > H> > that other CPUs are using now. > H> > > H> > H> Given sending 65K packets will take some time, using a shared atomic > H> operation will slow down this wraparound more than if it was per CPU. If > H> this is an argument, why do you want to make the ID allocation faster > H> and not slower? Should there perhaps be a DELAY() in there if too many > H> IDs rush out too quickly? > Hi Gleb, Should the IPv4 ID field carry useful information or not? > DELAY() into network stack? Are you serious now or kidding me? If there should be any useful meaning in the 16-bit IP ID field, the value can't be allowed to wrap several times in a millisecond. Given the context from where the network code is running, msleep() is not an option. A _conditional_ DELAY() of 1-2 us, is maybe all we need to prevent the value from wrapping too quickly. It is not perfect and it is indeed consuming more CPU. Or maybe we can add an IPv4 option to escape a 32-bit IP ID field and don't use the 16-bit IP ID field. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?551943B4.90102>