Virtualization - Feb 2018 - [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device

Sat, Feb 24, 2018 at 12:59:04AM CET, stephen at networkplumber.org
wrote:
>On Thu, 22 Feb 2018 13:30:12 -0800
>Alexander Duyck <alexander.duyck at gmail.com> wrote:
>
>> > Again, I undertand your motivation. Yet I don't like your
solution.
>> > But if the decision is made to do this in-driver bonding. I would
like
>> > to see it baing done some generic way:
>> > 1) share the same "in-driver bonding core" code with
netvsc
>> >    put to net/core.
>> > 2) the "in-driver bonding core" will strictly limit the
functionality,
>> >    like active-backup mode only, one vf, one backup, vf netdev
type
>> >    check (so noone could enslave a tap or anything else)
>> > If user would need something more, he should employ team/bond.  
>
>Sharing would be good, but netvsc world would really like to only have
>one visible network device.
Why do you mind? All would be the same, there would be just another
netdevice unused by the vm user (same as the vf netdev).

On Mon, 26 Feb 2018 08:19:24 +0100
Jiri Pirko <jiri at resnulli.us> wrote:
> Sat, Feb 24, 2018 at 12:59:04AM CET, stephen at networkplumber.org wrote:
> >On Thu, 22 Feb 2018 13:30:12 -0800
> >Alexander Duyck <alexander.duyck at gmail.com> wrote:
> >  
> >> > Again, I undertand your motivation. Yet I don't like your
solution.
> >> > But if the decision is made to do this in-driver bonding. I
would like
> >> > to see it baing done some generic way:
> >> > 1) share the same "in-driver bonding core" code
with netvsc
> >> >    put to net/core.
> >> > 2) the "in-driver bonding core" will strictly limit
the functionality,
> >> >    like active-backup mode only, one vf, one backup, vf
netdev type
> >> >    check (so noone could enslave a tap or anything else)
> >> > If user would need something more, he should employ
team/bond.
> >
> >Sharing would be good, but netvsc world would really like to only have
> >one visible network device.  
> 
> Why do you mind? All would be the same, there would be just another
> netdevice unused by the vm user (same as the vf netdev).
> 
I mind because our requirement is no changes to userspace.
No special udev rules, no bonding script, no setup.

Things like cloudinit running on current distro's expect to see a single
eth0.  The VF device show up can also be an issue because distro's have
stupid rules like Network Manager trying to start DHCP on every interface.
We deal with that now by doing stuff like udev rules to get it to stop
but that is still causing user errors.

On Mon, Feb 26, 2018 at 05:02:18PM -0800, Stephen Hemminger
wrote:
> On Mon, 26 Feb 2018 08:19:24 +0100
> Jiri Pirko <jiri at resnulli.us> wrote:
> 
> > Sat, Feb 24, 2018 at 12:59:04AM CET, stephen at networkplumber.org
wrote:
> > >On Thu, 22 Feb 2018 13:30:12 -0800
> > >Alexander Duyck <alexander.duyck at gmail.com> wrote:
> > >  
> > >> > Again, I undertand your motivation. Yet I don't like
your solution.
> > >> > But if the decision is made to do this in-driver
bonding. I would like
> > >> > to see it baing done some generic way:
> > >> > 1) share the same "in-driver bonding core"
code with netvsc
> > >> >    put to net/core.
> > >> > 2) the "in-driver bonding core" will strictly
limit the functionality,
> > >> >    like active-backup mode only, one vf, one backup, vf
netdev type
> > >> >    check (so noone could enslave a tap or anything else)
> > >> > If user would need something more, he should employ
team/bond.
> > >
> > >Sharing would be good, but netvsc world would really like to only
have
> > >one visible network device.  
> > 
> > Why do you mind? All would be the same, there would be just another
> > netdevice unused by the vm user (same as the vf netdev).
> > 
> 
> I mind because our requirement is no changes to userspace.
> No special udev rules, no bonding script, no setup.
Agreed. It is mostly fine from this point of view, except that you need
to know to skip the slaves.  Maybe we could look at some kind of
trick e.g. pretending link is down for slaves?
> Things like cloudinit running on current distro's expect to see a
single
> eth0.  The VF device show up can also be an issue because distro's have
> stupid rules like Network Manager trying to start DHCP on every interface.
> We deal with that now by doing stuff like udev rules to get it to stop
> but that is still causing user errors.
So the ideal of a single net device isn't achieved by netvsc.

Since you have scripts to skip the PT device, can't they
hind the PV slave too? How do they identify the device to skip?

I agree it would be nice to have a way to hide the extra netdev
from userspace.

The benefit of the separation is that each slave device can
be configured with e.g. its own native ethtool commands for
optimum performance.

-- 
MST