Message-ID: <20180611081757.4bf33e8b@xeon-e3>
Date:   Mon, 11 Jun 2018 08:17:57 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Siwei Liu <loseweigh@...il.com>
Cc:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jiri Pirko <jiri@...nulli.us>, kys@...rosoft.com,
        haiyangz@...rosoft.com, David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Stephen Hemminger <sthemmin@...rosoft.com>
Subject: Re: [PATCH net] failover: eliminate callback hell

On Fri, 8 Jun 2018 15:54:38 -0700
Siwei Liu <loseweigh@...il.com> wrote:

> On Wed, Jun 6, 2018 at 2:54 PM, Samudrala, Sridhar
> <sridhar.samudrala@...el.com> wrote:
> >
> >
> > On 6/6/2018 2:24 PM, Stephen Hemminger wrote:  
> >>
> >> On Wed, 6 Jun 2018 15:30:27 +0300
> >> "Michael S. Tsirkin" <mst@...hat.com> wrote:
> >>  
> >>> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:  
> >>>>
> >>>> Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@...workplumber.org wrote:  
> >>>>>
> >>>>> The net failover should be a simple library, not a virtual
> >>>>> object with function callbacks (see callback hell).  
> >>>>
> >>>> Why just a library? It should do a common things. I think it should be a
> >>>> virtual object. Looks like your patch again splits the common
> >>>> functionality into multiple drivers. That is kind of backwards attitude.
> >>>> I don't get it. We should rather focus on fixing the mess the
> >>>> introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> >>>> model.  
> >>>
> >>> So it seems that at least one benefit for netvsc would be better
> >>> handling of renames.
> >>>
> >>> Question is how can this change to 3-netdev happen?  Stephen is
> >>> concerned about risk of breaking some userspace.
> >>>
> >>> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> >>> address, and you said then "why not use existing network namespaces
> >>> rather than inventing a new abstraction". So how about it then? Do you
> >>> want to find a way to use namespaces to hide the PV device for netvsc
> >>> compatibility?
> >>>  
> >> Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> >> startups that all demand eth0 always be present. And VF may come and go.
> >> After this history, there is a strong motivation not to change how kernel
> >> behaves. Switching to 3 device model would be perceived as breaking
> >> existing userspace.  
> >
> >
> > I think it should be possible for netvsc to work with 3 dev model if the
> > only
> > requirement is that eth0 will always be present. With net_failover, you will
> > see eth0 and eth0nsby OR with older distros eth0 and eth1.  It may be an
> > issue
> > if somehow there is userspace requirement that there can be only 2 netdevs,
> > not 3
> > when VF is plugged.
> >
> > eth0 will be the net_failover device and eth0nsby/eth1 will be the netvsc
> > device
> > and the IP address gets configured on eth0. Will this be an issue?
> >  
> Did you realize that the eth0 name in the current 3-netdev code can't
> be consistently persisted across reboot, if you have more than one VFs
> to pair with? On one boot it got eth0/eth0nsby, on the next it may get
> eth1/eth1nsby on the same interface.
> 
> It won't be useable by default until you add some custom udev rules.
> 

I think there is no reason to break things by moving netvsc to 3 device
model. 

The first device probed is always the same on Hyper-V/Azure, and always
comes up as eth0. The order comes from the fact that they are reported
to guest in that order and currently vmbus probe is single threaded.

Powered by blists - more mailing lists