From: Herbert Xu <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 09:56:42 +1000
> Kazunori Miyazawa <[EMAIL PROTECTED]> wrote: > > > > I'm interested in the approach. And I have a couple of comments. > > I think DAD and ND are time critical operations. > > Can the daemons process with confirming to the specs. > > even if it were swapped out? > > Can we prevent the oom killer from killing the daemons? > > These are valid concerns. However, if we can have things like ntpd > live in user-space without causing nuisance, then addrconf should be > fine as well. I have severe doubts actually in this area. And I have practical experience to back up these doubts in this specific case. If you'll remember, quite some time ago, I tried to move all the ipv6 interface address addition and removal out of software interrupt context. The higher level goal of this work was to move the addrconf locking over to RCU, which would fix several races and bugs. Just moving the ipv6 address add/delete out of software interrupt context broke the TAHI and other ipv6 testsuites. The reason was simple. Consider a simple test case that emits an NDISC packet that should cause an interface address to be added, and then it sends a packet which makes sure that host responds to that address. We have those two packets in our queue, as packet "A" and "B". 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. 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. When considering new protocols or features, the "user vs. kernel" argument is something to validly consider. But when it's already there, it will have to live there basically for eternity. It is not like some arbitrary internal kernel module symbol or interface we can deprecate over a 6 month period or something like that. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
