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
signature.asc
Description: Digital signature
