On Wed, Dec 02, 2015 at 10:08:25PM +0800, Lan, Tianyu wrote: > On 12/1/2015 11:02 PM, Michael S. Tsirkin wrote: > >>But > >>it requires guest OS to do specific configurations inside and rely on > >>bonding driver which blocks it work on Windows. > >> From performance side, > >>putting VF and virtio NIC under bonded interface will affect their > >>performance even when not do migration. These factors block to use VF > >>NIC passthough in some user cases(Especially in the cloud) which require > >>migration. > > > >That's really up to guest. You don't need to do bonding, > >you can just move the IP and mac from userspace, that's > >possible on most OS-es. > > > >Or write something in guest kernel that is more lightweight if you are > >so inclined. What we are discussing here is the host-guest interface, > >not the in-guest interface. > > > >>Current solution we proposed changes NIC driver and Qemu. Guest Os > >>doesn't need to do special thing for migration. > >>It's easy to deploy > > > > > >Except of course these patches don't even work properly yet. > > > >And when they do, even minor changes in host side NIC hardware across > >migration will break guests in hard to predict ways. > > Switching between PV and VF NIC will introduce network stop and the > latency of hotplug VF is measurable. > For some user cases(cloud service > and OPNFV) which are sensitive to network stabilization and performance, > these are not friend and blocks SRIOV NIC usage in these case. I find this hard to credit. hotplug is not normally a data path operation. > We hope > to find a better way to make SRIOV NIC work in these cases and this is > worth to do since SRIOV NIC provides better network performance compared > with PV NIC. If this is a performance optimization as the above implies, you need to include some numbers, and document how did you implement the switch and how did you measure the performance. > Current patches have some issues. I think we can find > solution for them andimprove them step by step. -- MST -- 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
