Re: [RFC] virtio-net: help live migrate SR-IOV devices

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 5 Dec 2017 14:29:28 -0800
Jakub Kicinski <kubakici@wp.pl> wrote:

> On Tue, 5 Dec 2017 11:59:17 +0200, achiad shochat wrote:
> > >>>> I second Jacob - having a netdev of one device driver enslave a netdev
> > >>>> of another device driver is an awkward a-symmetric model.
> > >>>> Regardless of whether they share the same backend device.
> > >>>> Only I am not sure the Linux Bond is the right choice.
> > >>>> e.g one may well want to use the virtio device also when the
> > >>>> pass-through device is available, e.g for multicasts, east-west
> > >>>> traffic, etc.
> > >>>> I'm not sure the Linux Bond fits that functionality.
> > >>>> And, as I hear in this thread, it is hard to make it work out of the box.
> > >>>> So I think the right thing would be to write a new dedicated module
> > >>>> for this purpose.    
> > >
> > > This part I can sort of agree with. What if we were to look at
> > > providing a way to somehow advertise that the two devices were meant
> > > to be boded for virtualization purposes? For now lets call it a
> > > "virt-bond". Basically we could look at providing a means for virtio
> > > and VF drivers to advertise that they want this sort of bond. Then it
> > > would just be a matter of providing some sort of side channel to
> > > indicate where you want things like multicast/broadcast/east-west
> > > traffic to go.  
> > 
> > I like this approach.  
> 
> +1 on a separate driver, just enslaving devices to virtio may break
> existing setups.  If people are bonding from user space today, if they
> update their kernel it may surprise them how things get auto-mangled.
> 
> Is what Alex is suggesting a separate PV device that says "I would
> like to be a bond of those two interfaces"?  That would make the HV
> intent explicit and kernel decisions more understandable.

So far, in my experience it still works.
As long as the kernel slaving happens first, it will work.
The attempt to bond an already slaved device will fail and no scripts seem
to check the error return.