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: > > > On 2017年11月29日 03:27, Jesse Brandeburg wrote: > > > commit 0c195567a8f6e82ea5535cd9f1d54a1626dd233e > > > Author: stephen hemminger <stephen@xxxxxxxxxxxxxxxxxx> > > > Date: Tue Aug 1 19:58:53 2017 -0700 > > > > > > netvsc: transparent VF management > > > > > > 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. > > > > > > Using bonding driver has lots of issues because it 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. > > > > > > Signed-off-by: Stephen Hemminger <sthemmin@xxxxxxxxxxxxx> > > > Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> > > > > > > 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? > > > > 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: > > > > https://mail.gnome.org/archives/networkmanager-list/2017-November/msg00038.html > > > > 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... > > Although "policy should not be in the kernel" is a a great mantra, > it is not practical in the real world. > > 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 had it seemed like no one ever did, and SR-IOV+virtio bonding is 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, because vendors rarely employ developers of the user space orchestrations systems. Is that not the real problem here, potentially? :) _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
