On Sat, 2006-01-04 at 17:11 +0200, Stefan Rompf wrote: > Am Samstag 01 April 2006 14:50 schrieb jamal: > > > No stefan - check arpd. Infact if you really want to scale ARP to many > > many entries, you do it in user space. This has been proven more than > > once in the past: Thats the main reason the current daemons exist. It is > > AFAIK the primary purpose of arpd was to overcome a limitation in the number > of ARP cache entries older kernels can handle.
It is an artificial limitation really i.e extending the table size is not complicated at all. You can today do thousands of ARP entries with current code. Try running that vs arpd and you will see a difference. > It is extending, not replacing > the in kernel implementation, taking over the role of active ARP probing is > even optional. But I don't think our opinions are far of. It does seem that way. > For me, these points are important to make my opinion whether something > belongs > into the kernel or not. > > -How complex is the protocol, including workarounds for broken peers Take a look at the arp code for ifdefs and for the 101 bells that 101 types of people need;-> Look at the sysctls associated etc etc It is not exactly simple. > -How important is the protocol to allow some feature on a non-specialized > machine to work It is always easier to tell someone to do things in user space and maintain a lean kernel. Essentially your two points are indicative of the feature-richness requirement. The more feature rich something tends to be, the more it lends itself to be a policy driver (in user space) with mechanisms in the kernel. _All_ control protocols are feature rich (or will be by next week if you want to be practical). > -How often does it run The important thing for this requirement is: we need to find a smart way to cache things in the kernel. The control computation is a separate piece. > -How bad would be a partial failure (OOM kill) If you need to be reliable - it is important. But if you are going to run out of memory, it doesnt matter if you do it in the kernel or user space. > So I'd keep a rather simple but important protocol in kernel, while stuff > like > 802.1X (not running very often, simple failure scenario) or STP and it's > successors that can handle VLANs or load balancing should be userspace, even > though the kernel should be able of a clean shutdown in case the daemon is > killed. Indeed; however, it is not rocket science. There are many well know good-practise approaches to such things. > But I think we're getting too off topic now, I just wanted to make clear that > I'd be quite unhappy if arp handling would be ripped out of the kernel. > Dont worry - its not a half day effort, otherwise some coffee may have already influenced me by now ;-> cheers, jamal - 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
