On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote: > I'm guessing that that wouldn't allow to do unicast filtering for > the guests on the real device without hacking the bridge code for > this special case.
For ingress (i guess you could say for egress as well): we can do it as well today with tc filtering on the host - it is involved but is part of provisioning for a guest IMO. A substantial amount of ethernet switches (ok, not the $5 ones) do filtering at the same level. > The difference to a real bridge is that the > all addresses are completely known in advance, so it doesn't need > promiscous mode for learning. You mean the per-virtual MAC addresses are known in advance, right? This is fine. The bridging or otherwise (like L3 etc) is for interconnecting once you have the provisioning done. And you could build different "broadcast domains" by having multiple bridges. To go off on a slight tangent: I think you have to look at the two types of NICs separately 1) dumb ones where you may have to use the mcast filters in hardware to pretend you have a unicast address per virtual device - those will be really hard to simulate using a separate netdevice per MAC address. Actually your bigger problem on those is tx MAC address selection because that is not built into the hardware. I still think even for these types something above netdevice (bridge, L3 routing, tc action redirect etc) will do. 2) The new NICs being built for virtualization; those allow you to explicitly have clean separation of IO where the only thing that is shared between virtual devices is the wire and the bus (otherwise each has its own registers etc) i.e the hardware is designed with this in mind. In such a case, i think a separate netdevice per single MAC address - possibly tied to a separate CPU should work. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
