Re: Regarding offloading IPv6 addrconf and ndisc

[Hugo Santos <hsantos@av.it.pt>]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

Hi David,

> If we process these in sequence in software interrupt, everything
> is fine.  Processing of "A" will add the address, and the test
> ping packet "B" will respond properly.
> 
> If you defer "A", everything breaks and the test packet "B" will
> get processed first and not work.

   Is it reasonable to consider that control packet processing needs to
 be serialized with data packet processing? In this particular case, is
 it not the tests that are broken if not giving enough time to the host
 to configure the address? The standards do not specify implementation
 details so no specific processing model should be assumed, and what you
 describe sounds a bit like an ideal model.

> As a secondary reason not to even consider this, it's in the kernel
> already and therefore it is totally impractical to try and remove it.

   I'm not sure if it was clear from my original e-mail, but i'm not
 suggesting removing any of the functionality from the kernel -- it is
 clear the current implementation is useful in out of the box
 deployments. Instead, i would like to know what was the possibility of
 having a bit of new functionality that would allow this specific
 methods to be outsourced to an user-space control application. And by
 specific methods i'm refering to NDISC message processing, "neighbor
 entry needs refreshing" events, etc.

   Hugo


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]