[Server-devel] Using bridges and interrupt load

[Jerry Vonau]

Martin Langhoff wrote:
> 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.
>
Yes, that is a cost.

> 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.
> 

A hub may cause a 33mhz pci bus to max-out, due to driver/hardware 
limits. Switching would only delay the onset of limitations, buggy 
drivers and cheap hardware(buffer sizing) could be a disaster on a bridge.

> 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,

Have a read of Performance Issues at:
http://www.cs.northwestern.edu/~zli109/linuxflow/
and
http://facweb.cti.depaul.edu/jyu/Publications/Yu-Linux-TSM2004.pdf

Both deal with the effects of promiscuous mode.

Jerry