On Mon, 07 Aug 2006 08:39:01 -0700 Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > Alex Zeffertt wrote: > > Ben Greear wrote: > > > >> Ard van Breemen wrote: > >> > >>> Hello Ben, > >>> I want to start supporting macvlan's in debian (with debian style > >>> "auto" configuration). > >>> I'm just not so charmed with the name macvlan_config. > >>> Is it ok if I rename that (in the resulting package) to mvconfig? > >> > >> > >> That is fine by me. > >> > >>> I think that macvlan's are essential if you want to do "pure" > >>> vrrp implementations (with mac-address failover). > >> > >> > >> I have re-written the mac-vlan patch a bit lately, primarily to > >> simplify the code and remove functionality I never used (and thus, > >> never tested.) > >> > >> The main changes: > >> > >> * Allow only matching on the destination MAC, not the source. > >> > > > > > > Uh? Surely source MAC matching is what MAC address based VLANs > > (on any platform) should be about. So that you can group hosts into > > VLANs. > > > > > >> * Allow only matching a single MAC address, not a list. > >> (Removed the hash lookup logic as well.) > >> > > > > Why? Surely the point of VLANs is to group *multiple* hosts into > > virtual LANs. > > My needs were different. I wanted to emulate many ethernet NICs with > a single physical NIC. For a while, I was supporting both filter-on-dest > and filter-on-source logic, but since I never used filter-on-source, the > code was rotting and I decided to remove it. > > If there is interest in supporting filter-on-source as well, then > I will certainly consider patches against my patch. And of course, > you are welcome to do a complete fork if you wish (I think that would > be a waste of effort for the most part, however.) > > The old code had locking issues and module-unload issues, so we > will need to do a bit more thinking before we re-add that functionality. > > > This seems to be completely unrelated now to the patch I originally > > sent to this list. This is not a problem in itself, but I can't see > > how the functionality still relates to MAC address based VLANs.... > > Yes, it is quite different, but much of the logic is similar. To > start re-adding the filter-on-source features, I think the following > is needed: > > 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. 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.
