Hello, Please find my comments inline. Regards, Shradha Shah On 02/16/2012 03:58 AM, Ben Hutchings wrote: > [I'm just catching up with this after getting my own driver changes into > shape.] > > On Fri, 2012-02-10 at 10:18 -0500, jamal wrote: >> Hi John, >> >> I went backwards to summarize at the top after going through your email. >> >> TL;DR version 0.1: >> you provide a good use case where it makes sense to do things in the >> kernel. IMO, you could make the same arguement if your embedded switch >> could do ACLs, IPv4 forwarding etc. And the kernel bloats. >> I am always bigoted to move all policy control to user space instead of >> bloating in the kernel. > [...] >>> Now here is the potential issue, >>> >>> (G) The frame transmitted from ethx.y with the destination address of >>> veth0 but the embedded switch is not a learning switch. If the FDB >>> update is done in user space its possible (likely?) that the FDB >>> entry for veth0 has not been added to the embedded switch yet. >> >> Ok, got it - so the catch here is the switch is not capable of learning. >> I think this depends on where learning is done. Your intent is to >> use the S/W bridge as something that does the learning for you i.e in >> the kernel. This makes the s/w bridge part of MUST-have-for-this-to-run. >> And that maybe the case for your use case. > [...] > > Well, in addition, there are SR-IOV network adapters that don't have any > bridge. For these, the software bridge is necessary to handle > multicast, broadcast and forwarding between local ports, not only to do > learning. > > Solarflare's implementation of accelerated guest networking (which > Shradha and I are gradually sending upstream) builds on libvirt's > existing support for software bridges and assigns VFs to guests as a > means to offload some of the forwarding. I am also trying to work with bridging using macvtap. Libvirt supports macvtap in four modes; vepa, bridge, private and passthrough mode. Macvtap used in the bridge mode will work similar to a software bridge and will improve performance. > > If and when we implement a hardware bridge, we would probably still want > to keep the software bridge as a fallback. If a guest is dependent on a > VF that's connected to a hardware bridge, it becomes impossible or at > least very disruptive to migrate it to another host that doesn't have a > compatible VF available. > > Ben. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
