svn commit: r280759 - head/sys/netinet

Hans Petter Selasky hps at selasky.org
Mon Mar 30 12:37:28 UTC 2015


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




More information about the svn-src-head mailing list