From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a486C-0002QY-8H for qemu-devel@nongnu.org; Wed, 02 Dec 2015 09:09:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4867-0002pW-I5 for qemu-devel@nongnu.org; Wed, 02 Dec 2015 09:09:36 -0500 Received: from mga03.intel.com ([134.134.136.65]:51221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4867-0002pO-CV for qemu-devel@nongnu.org; Wed, 02 Dec 2015 09:09:31 -0500 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> From: "Lan, Tianyu" Message-ID: <565EFB59.1000005@intel.com> Date: Wed, 2 Dec 2015 22:08:25 +0800 MIME-Version: 1.0 In-Reply-To: <20151201164327-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" 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 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. 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. Current patches have some issues. I think we can find solution for them andimprove them step by step.