Ben Greear wrote: > Stephen Hemminger wrote: >> On Wed, 28 Feb 2007 17:28:09 -0800 >> Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: >> >> >>> Stephen Hemminger wrote: >>> >>>> I was measuring bridging/routing performance and noticed this. >>>> >>>> The current code runs the "all packet" type handlers before calling >>>> the bridge hook. If an application (like some DHCP clients) is >>>> using AF_PACKET, this means that each received packet gets run >>>> through the Berkeley Packet Filter code in sk_run_filter (slow). >>>> >>>> By moving the bridging hook to run first, the packets flowing >>>> through the bridge get filtered out there. This results in a 14% >>>> improvement in performance, but it does mean that some snooping >>>> applications would miss packets if being used on a bridge. The >>>> correct way to see all packets on a bridge is to set the bridge >>>> pseudo-device to promiscuous mode. >>>> >>> Seems it would be better to fix these clients to be more selective as >>> to where they bind. >>> >> >> The problem is any use of BPF is a lose, if it has to be done to all >> traffic. >> > Right, but couldn't you have the dhcp client bind to eth0, eth7, and > br0 (ie, skipping the eth1-6 that comprise the bridge group?) > > The only difficulty I see is having the client know when new devices > come and go, but there are probably > ways to know that without keeping a whole lot of state or probing the > /proc/net/dev (like my own bloated app does :)) > > I envision the client args to be something like --skip-devices "eth1 > eth2 eth3 ..." > > I know you can bind raw packet sockets to individual devices, though I > don't know much about BPF, so it's > possible I'm wrong... > The kernel has to deal with busted applications all the time. And each damn distro and configuration seems to invent it's own new way of doing network configuration. If an normal application has to use something like raw packet filtering, it seems there is a missing API. >>> This breaks the case where you want to see packets on a particular >>> interface, not just the entire bridge, right? >>> >> >> It might be possible to use promisc counter to handle this. >> > Not really, it's perfectly valid to sniff a port in non-promiscuous > mode... > The non-promiscuous mode packets still make it in through the normal receive path. The only packets that don't make up the stack are those that are being bridged. _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/bridge
