On Mon, Aug 10, 2009 at 09:04:54PM +0200, Arnd Bergmann wrote: > 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 <>< Similar thing for zero copy sends. You need to know when the buffers have been consumed to notify userspace, and this is very hard with a generic bridge in the middle. -- MST _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
