On Wed, 29 Nov 2017 20:10:09 -0800, Stephen Hemminger wrote:

On Wed, 29 Nov 2017 19:51:38 -0800 Jakub Kicinski wrote:

quoted

On Thu, 30 Nov 2017 11:29:56 +0800, Jason Wang wrote:  

quoted

On 2017年11月29日 03:27, Jesse Brandeburg wrote:    
commit 0c195567a8f6e82ea5535cd9f1d54a1626dd233e
Author: stephen hemminger [off-list ref]
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 [off-list ref]
     Signed-off-by: David S. Miller [off-list ref]

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? :)