svn commit: r280759 - head/sys/netinet

[Gleb Smirnoff]

  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?

DELAY() into network stack? Are you serious now or kidding me?

-- 
Totus tuus, Glebius.