From: Stephen Hemminger <stephen@networkplumber.org>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Jiri Pirko <jiri@resnulli.us>,
kys@microsoft.com, haiyangz@microsoft.com, davem@davemloft.net,
netdev@vger.kernel.org,
Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [PATCH net] failover: eliminate callback hell
Date: Wed, 6 Jun 2018 15:25:16 -0700 [thread overview]
Message-ID: <20180606152516.5edd5893@xeon-e3> (raw)
In-Reply-To: <e20a6cdf-34b4-cbc9-1dc9-75c436d6c2fe@intel.com>
On Wed, 6 Jun 2018 14:54:04 -0700
"Samudrala, Sridhar" <sridhar.samudrala@intel.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@redhat.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@networkplumber.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?
DPDK drivers in 18.05 depend on 2 device model. Yes it is a bit of mess
but that is the way it is.
next prev parent reply other threads:[~2018-06-06 22:25 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 3:42 [PATCH net] failover: eliminate callback hell Stephen Hemminger
2018-06-05 17:22 ` Samudrala, Sridhar
2018-06-05 17:45 ` Stephen Hemminger
2018-06-05 18:14 ` David Miller
2018-06-05 18:35 ` Michael S. Tsirkin
2018-06-05 18:53 ` Stephen Hemminger
2018-06-05 19:38 ` Michael S. Tsirkin
2018-06-05 21:52 ` Stephen Hemminger
2018-06-05 23:52 ` Samudrala, Sridhar
2018-06-06 3:51 ` Stephen Hemminger
2018-06-06 5:39 ` Samudrala, Sridhar
2018-06-06 6:00 ` Stephen Hemminger
2018-06-06 6:11 ` Samudrala, Sridhar
2018-06-06 21:16 ` Stephen Hemminger
2018-06-06 21:30 ` Michael S. Tsirkin
2018-06-06 22:21 ` Stephen Hemminger
2018-06-11 18:07 ` Michael S. Tsirkin
2018-06-06 12:19 ` Michael S. Tsirkin
2018-06-06 21:17 ` Stephen Hemminger
2018-06-06 7:25 ` Jiri Pirko
2018-06-06 12:30 ` Michael S. Tsirkin
2018-06-06 21:24 ` Stephen Hemminger
2018-06-06 21:47 ` Michael S. Tsirkin
2018-06-06 22:24 ` Stephen Hemminger
2018-06-07 14:57 ` Michael S. Tsirkin
2018-06-07 15:23 ` Stephen Hemminger
2018-06-06 21:54 ` Samudrala, Sridhar
2018-06-06 22:25 ` Stephen Hemminger [this message]
2018-06-07 14:17 ` Alexander Duyck
2018-06-07 14:51 ` Stephen Hemminger
2018-06-07 15:41 ` Michael S. Tsirkin
2018-06-07 16:17 ` Stephen Hemminger
2018-06-07 17:22 ` Michael S. Tsirkin
2018-06-08 18:30 ` Stephen Hemminger
2018-06-08 19:04 ` Michael S. Tsirkin
2018-06-08 22:54 ` Siwei Liu
2018-06-11 15:17 ` Stephen Hemminger
2018-06-08 22:25 ` Siwei Liu
2018-06-08 23:18 ` Stephen Hemminger
2018-06-08 23:44 ` Siwei Liu
2018-06-09 0:02 ` Stephen Hemminger
2018-06-09 0:42 ` Siwei Liu
2018-06-11 15:22 ` Stephen Hemminger
2018-06-11 19:23 ` Siwei Liu
2018-06-11 14:01 ` Michael S. Tsirkin
2018-06-09 1:29 ` Jakub Kicinski
2018-06-11 18:56 ` Siwei Liu
2018-06-12 2:14 ` Michael S. Tsirkin
2018-06-06 21:26 ` Stephen Hemminger
2018-06-11 18:10 ` Michael S. Tsirkin
2018-06-11 19:34 ` Samudrala, Sridhar
2018-06-12 0:08 ` Samudrala, Sridhar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180606152516.5edd5893@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=davem@davemloft.net \
--cc=haiyangz@microsoft.com \
--cc=jiri@resnulli.us \
--cc=kys@microsoft.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sridhar.samudrala@intel.com \
--cc=sthemmin@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.