Using bridges and interrupt load

[Martin Langhoff]

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
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff