Jason Lunz <lunz@xxxxxxxxxxxx> writes: > luke@xxxxxxxxxxxxxx said: > > This still sounds like packet-socket territory to me. Wouldn't it be > > better to clarify/extend the packet-socket interface to cover bridged > > ports? > > I think you can just use a packet socket with BPF; that's what dhcpd > does and it doesn't seem to incur noticable overhead on non-dhcp > traffic. Good point. I had assumed that any per-packet overhead would be unacceptable since the box has to get "maximum" throughput. But we're already running a PACKET-socket based DHCP relay, and I don't think that impacted performance measurably. Thanks for the tip! Still, I find the current semantics of packet sockets on bridged ports pretty confusing. It took me a full day to figure out why I wasn't receiving the packets I wanted, even though tcpdump did. I applied my proposed fix in my local tree: I have a separate clone of the ptype_base hashtable dev.c for specific-protocol handlers that want to run before the bridge, and an ioctl to move a packet-socket into that table. That way the user can choose whether he wants to get packets from enslaved interfaces or not. If Someone Important thinks that change sounds reasonable and should be made in Linux then I can port it to 2.6 and send a patch. Cheers, Luke
