<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;">Hi all,<br>I'm currently working on a driver for a new network card which supports filtering by mac address very well. I implemented set_multicast_list for my driver and got some great speed improvements, due to taking advantage of the hardware filtering.<br><br>Unfortunately, when I add this device to a bridge I lose a lot of these improvements due to the bridge switching the device to promiscuous mode. I'm currently looking into how to change the bridge code to take advantage of these optimizations. Could people more familiar with the bridge code take a look and let me know: a. Has this been tried or talked about before? b. Are there any glaring flaws in my design?<br><br>1. Remove dev_set_promiscuity from bridge code in net/bridge/br_if.c<br>2. Fill in the br_dev_set_multicast_list function found in net/bridge/br_device.c<br>3. In net/bridge/br_fdb.c, add code which calls set_multicast_list on each port in a bridge whenever that bridge's address database changes. I believe the two functions that will need to change are fdb_delete and fdb_create.<br>&nbsp;&nbsp;&nbsp; a. We need to always receive multicast traffic, so we can forward it. Set the IFF_ALLMULTI flag on all ports.<br>&nbsp;&nbsp;&nbsp; b. Call set_multicast_list with dev-&gt;mc_list set to the list of addresses in the database for each port.<br>&nbsp;&nbsp;&nbsp; c. Fall back  to promiscuous mode&nbsp;if multicast filtering isn't supported on a port. This should only be for the one port which doesn't support it. The rest can still filter.<br><br>I'll probably be implementing these changes shortly. Hopefully they work how I'm thinking they will.<br>Thanks,<br>David<br></span></body></html>