Stephen Hemminger wrote: >>1) Add flag to toggle filter-on-source v/s filter-on-dest. >> >>2) Re-add filter-on-source method to find the correct mac-vlan interface. >> >>3) Add global hash table to map source MACs to vlans. >> >>4) (Optimization to my logic): Add global hash to map destination MAC to vlan. > > > How is this all that different from how Xen and other virtualization code > uses the bridge code now. Harald Welte had a virtual ether device prototype > at some point as well. I don't know how Xen does it, but the mac-vlan code is relatively generic virtual interface logic, so it's likely it would be similar to other virtual interfaces... > It would make sense to push the multiple MAC address support into the generic > netdevice layer, since many kinds of hardware support multiple MAC receive > already, there just isn't a API to handle it. If the driver can't do it, then > obviously you would have to do filtering, like the multicast code does now. We could do this similar to how we did vlans: First put in a pure software solution (similar to what mac-vlan is currently.) When the functionality & API is ironed out there, we can add the hardware acceleration as supported by the various NICs. Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com
