Date: Mon, 30 Mar 2015 00:15:33 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Fabien Thomas <fabient@FreeBSD.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150329211533.GB64665@FreeBSD.org> In-Reply-To: <20150328204333.GF51048@funkthat.com> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328172313.GC51048@funkthat.com> <20150328181833.GX64665@FreeBSD.org> <20150328204333.GF51048@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote: J> > J> > I think we can use per-cpu ID counters, each CPU incrementing its J> > J> > own. If we start with random values, then probability of two packets with J> > J> > the same ID emitting at the allowed timeframe will be acceptably small. J> > J> J> > J> Please do not use per-cpu id counters.. That will just push the J> > J> duplicate ids to being more rare, but just as much of a problem... J> > J> J> > J> Please read: J> > J> https://tools.ietf.org/html/rfc6864 J> > J> J> > J> And then implement one hased upon source/dest/protocol... J> > J> > I know about this RFC, but using per-cpu ID counter if a low hanging J> > fruit and is improvement. What is important not only improvement in J> > terms of lowering probability of collision, but also easy improvement in J> > performance, since now global ip_id increment is a cache line thrasher. J> > J> > So, I don't see how existense of the RFC blocks introducing an easy J> > improvement. And if anyone works on implementing the RFC, he shouldn't J> > care what is in head before his work, either global or per-cpu counter. J> J> Your comment: "fix the race", to me reads that it was a final solution, J> not simply a stop gap... J> J> If you had simply said that this is a stop gap till someone properly J> implements RFC6864, that would make it obvious that you were aware of J> it.. Nothing in your commit message said that you were aware that this J> wasn't the correct final solution... Information like that should be J> included in the commit message so people don't assume that this is the J> final solution... J> J> Anyways, are we really sending so many fragments that we are thrashing J> the cache line? I'd imagine a much lower hanging fruit is only provide J> ip_id when a non-atomic packet is being sent... I didn't do a commit that enables discussed feature. What commit message do you refer to? Well, if you are sure that implementing RFC6864 is a much lower hanging fruit than the patch, that I submitted to the list, then you are welcome to implement it. :) As for me, it requires to examine the stack a bit to be sure that we aren't missing anything important. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150329211533.GB64665>