On Monday 10 August 2009, Fischer, Anna wrote: > If you compare macvtap with traditional QEMU networking interfaces that > are typically used in current bridged setups, then yes, performance will be > different. However, I think that this is not necessarily a fair > comparison, and the performance difference does not come from the > bridge being slow, but simply because you have implemented a better > solution to connect a virtual interface to a backend device that > can be assigned to a VM. There is no reason why you could not do this > for a bridge port as well. It's not necessarily the bridge itself being slow (though some people claim it is) but more the bridge preventing optimizations or making them hard. You already mentioned hardware filtering by unicast and multicast mac addresses, which macvlan already does (for unicast) but which would be relatively complex with a bridge due to the way it does MAC address learning. If we want to do zero copy receives, the hardware will on top of this have to choose the receive buffer based on the mac address, with the buffer provided by the guest. I think this is not easy with macvlan but doable, while I have no idea where you would start using the bridge code. Arnd <>< _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
