From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [RFC] virtio-net: help live migrate SR-IOV devices Date: Wed, 29 Nov 2017 20:21:08 -0800 Message-ID: <20171129202108.4aa464b1@cakuba.netronome.com> References: <20171128112722.00003716@intel.com> <0fb552d4-1bfc-e130-4fc1-87b83873916d@redhat.com> <20171129195138.63512ead@cakuba.netronome.com> <20171129201009.4d48dc6d@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jason Wang , Jesse Brandeburg , virtualization@lists.linux-foundation.org, mst@redhat.com, Sridhar Samudrala , Achiad , Peter Waskiewicz Jr , "Singhai, Anjali" , Andy Gospodarek , Or Gerlitz , netdev , Hannes Frederic Sowa To: Stephen Hemminger Return-path: Received: from mail-pl0-f66.google.com ([209.85.160.66]:43104 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751883AbdK3EVM (ORCPT ); Wed, 29 Nov 2017 23:21:12 -0500 Received: by mail-pl0-f66.google.com with SMTP id x4so3515851plv.10 for ; Wed, 29 Nov 2017 20:21:11 -0800 (PST) In-Reply-To: <20171129201009.4d48dc6d@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 29 Nov 2017 20:10:09 -0800, Stephen Hemminger wrote: > On Wed, 29 Nov 2017 19:51:38 -0800 Jakub Kicinski wrote: > > On Thu, 30 Nov 2017 11:29:56 +0800, Jason Wang wrote: =20 > > > On 2017=E5=B9=B411=E6=9C=8829=E6=97=A5 03:27, Jesse Brandeburg wrote:= =20 > > > commit 0c195567a8f6e82ea5535cd9f1d54a1626dd233e > > > Author: stephen hemminger > > > Date:=C2=A0=C2=A0 Tue Aug 1 19:58:53 2017 -0700 > > >=20 > > > =C2=A0=C2=A0=C2=A0 netvsc: transparent VF management > > >=20 > > > =C2=A0=C2=A0=C2=A0 This patch implements transparent fail over from = synthetic NIC > > > to SR-IOV virtual function NIC in Hyper-V environment. It is a > > > better alternative to using bonding as is done now. Instead, the > > > receive and transmit fail over is done internally inside the driver. > > >=20 > > > =C2=A0=C2=A0=C2=A0 Using bonding driver has lots of issues because i= t depends on > > > the script being run early enough in the boot process and with > > > sufficient information to make the association. This patch moves > > > all that functionality into the kernel. > > >=20 > > > =C2=A0=C2=A0=C2=A0 Signed-off-by: Stephen Hemminger > > > =C2=A0=C2=A0=C2=A0 Signed-off-by: David S. Miller > > >=20 > > > If my understanding is correct there's no need to for any extension > > > of virtio spec. If this is true, maybe you can start to prepare the > > > patch? =20 > >=20 > > IMHO this is as close to policy in the kernel as one can get. User > > land has all the information it needs to instantiate that bond/team > > automatically. In fact I'm trying to discuss this with NetworkManager > > folks and Red Hat right now: > >=20 > > https://mail.gnome.org/archives/networkmanager-list/2017-November/msg00= 038.html > >=20 > > Can we flip the argument and ask why is the kernel supposed to be > > responsible for this? It's not like we run DHCP out of the kernel > > on new interfaces... =20 >=20 > Although "policy should not be in the kernel" is a a great mantra, > it is not practical in the real world. >=20 > If you think it can be solved in userspace, then you haven't had to > deal with four different network initialization > systems, multiple orchestration systems and customers on ancient > Enterprise distributions. I would accept that argument if anyone ever tried to get those Enterprise distros to handle this use case. From conversations I=20 had it seemed like no one ever did, and SR-IOV+virtio bonding is=20 what has been done to solve this since day 1 of SR-IOV networking. For practical reasons it's easier to push this into the kernel,=20 because vendors rarely employ developers of the user space orchestrations systems. Is that not the real problem here, potentially? :)