svn commit: r280759 - head/sys/netinet

[Gleb Smirnoff]

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.