From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a48RM-0001vg-82 for qemu-devel@nongnu.org; Wed, 02 Dec 2015 09:31:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a48RH-0001Tq-4N for qemu-devel@nongnu.org; Wed, 02 Dec 2015 09:31:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a48RG-0001Tk-RE for qemu-devel@nongnu.org; Wed, 02 Dec 2015 09:31:23 -0500 Date: Wed, 2 Dec 2015 16:31:14 +0200 From: "Michael S. Tsirkin" Message-ID: <20151202161042-mutt-send-email-mst@redhat.com> References: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> <20151130095454-mutt-send-email-mst@redhat.com> <565D3DB1.5050902@intel.com> <20151201164327-mutt-send-email-mst@redhat.com> <565EFB59.1000005@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565EFB59.1000005@intel.com> Subject: Re: [Qemu-devel] [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Lan, Tianyu" Cc: qemu-devel@nongnu.org, emil.s.tantilov@intel.com, kvm@vger.kernel.org, ard.biesheuvel@linaro.org, aik@ozlabs.ru, donald.c.skidmore@intel.com, quintela@redhat.com, eddie.dong@intel.com, nrupal.jani@intel.com, agraf@suse.de, blauwirbel@gmail.com, cornelia.huck@de.ibm.com, alex.williamson@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, amit.shah@redhat.com, pbonzini@redhat.com, mark.d.rustad@intel.com, lcapitulino@redhat.com, gerlitz.or@gmail.com 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