In the XS networking infrastructure we sometimes setup a bridge with an IP address and netblock (as you would with an interface) and then if-and-when the HW interface comes up, we assign the interface to the bridge.
This is a technique used quite a bit on projects like OpenWRT where the main purpose of the device is routing. We use it because we want to associate dhcpd to devices that come and go (the USB-plugged active antennae) and if we let dhcpd bind to the IP address in the bridge, then we can associate the physical device to it when it becomes available with no dhcpd restarts. There is another IP address that we'd like to do the same with - the master 'school server' IP address, which has to be the same and available in several (and often dynamically changing) scenarios. But it is starting to worry me that when we use this technique, the physical interface is brought up in promiscuous mode, and it is left to the kernel networking stack to decide what frames are meant for us, and what frames are not. On interfaces where there is considerable traffic -- a 1Gb LAN for example with a cheap non-switching hub -- there could be quite a bit of traffic not meant for us. This naturally means more interrupts. What I don't know is whether the amount of "noise" created this way is significant for a modern 1GHz i386 cpu that is actually trying to do other stuff. The OpenWRT boxes are there for routing, if there's a bit of CPU churn to get the job done, then it's ok. But the XS is there to provide end-user services -- if interrupt load can eat its capacity to do useful work, I want to be careful with these bridges... Does anyone know more about the irq load caused by this technique? cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
