netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Sridhar Samudrala <sridhar.samudrala@intel.com>,
	stephen@networkplumber.org, davem@davemloft.net,
	netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	virtio-dev@lists.oasis-open.org, jesse.brandeburg@intel.com,
	alexander.h.duyck@intel.com, kubakici@wp.pl, jasowang@redhat.com,
	loseweigh@gmail.com, aaron.f.brown@intel.com,
	anjali.singhai@intel.com
Subject: Re: [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
Date: Tue, 22 May 2018 18:32:30 +0300	[thread overview]
Message-ID: <20180522181804-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180522151343.GJ2149@nanopsycho>

On Tue, May 22, 2018 at 05:13:43PM +0200, Jiri Pirko wrote:
> Tue, May 22, 2018 at 03:39:33PM CEST, mst@redhat.com wrote:
> >On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote:
> >> Tue, May 22, 2018 at 03:17:37PM CEST, mst@redhat.com wrote:
> >> >On Tue, May 22, 2018 at 03:14:22PM +0200, Jiri Pirko wrote:
> >> >> Tue, May 22, 2018 at 03:12:40PM CEST, mst@redhat.com wrote:
> >> >> >On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote:
> >> >> >> Tue, May 22, 2018 at 11:06:37AM CEST, jiri@resnulli.us wrote:
> >> >> >> >Tue, May 22, 2018 at 04:06:18AM CEST, sridhar.samudrala@intel.com wrote:
> >> >> >> >>Use the registration/notification framework supported by the generic
> >> >> >> >>failover infrastructure.
> >> >> >> >>
> >> >> >> >>Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> >> >> >> >
> >> >> >> >In previous patchset versions, the common code did
> >> >> >> >netdev_rx_handler_register() and netdev_upper_dev_link() etc
> >> >> >> >(netvsc_vf_join()). Now, this is still done in netvsc. Why?
> >> >> >> >
> >> >> >> >This should be part of the common "failover" code.
> >> >> >> >
> >> >> >> 
> >> >> >> Also note that in the current patchset you use IFF_FAILOVER flag for
> >> >> >> master, yet for the slave you use IFF_SLAVE. That is wrong.
> >> >> >> IFF_FAILOVER_SLAVE should be used.
> >> >> >
> >> >> >Or drop IFF_FAILOVER_SLAVE and set both IFF_FAILOVER and IFF_SLAVE?
> >> >> 
> >> >> No. IFF_SLAVE is for bonding.
> >> >
> >> >What breaks if we reuse it for failover?
> >> 
> >> This is exposed to userspace. IFF_SLAVE is expected for bonding slaves.
> >> And failover slave is not a bonding slave.
> >
> >That does not really answer the question.  I'd claim it's sufficiently
> >like a bond slave for IFF_SLAVE to make sense.
> >
> >In fact you will find that netvsc already sets IFF_SLAVE, and so
> 
> netvsc does the whole failover thing in a wrong way. This patchset is
> trying to fix it.

Maybe, but we don't need gratuitous changes either, especially if they
break userspace.

> >does e.g. the eql driver.
> >
> >The advantage of using IFF_SLAVE is that userspace knows to skip it.  If
> 
> The userspace should know how to skip other types of slaves - team,
> bridge, ovs, etc.
> The "master link" should be the one to look at.
> 

How should existing userspace know which ones to skip and which one is
the master?  Right now userspace seems to assume whatever does not have
IFF_SLAVE should be looked at. Are you saying that's not the right thing
to do and userspace should be fixed? What should userspace do in
your opinion that will be forward compatible with future kernels?

> 
> >we don't set IFF_SLAVE existing userspace tries to use the lowerdev.
> 
> Each master type has a IFF_ master flag and IFF_ slave flag.

Could you give some examples please?

> In private
> flag. I don't see no reason to break this pattern here.

Other masters are setup from userspace, this one is set up automatically
by kernel. So the bar is higher, we need an interface that existing
userspace knows about.  We can't just say "oh if userspace set this up
it should know to skip lowerdevs".

Otherwise multiple interfaces with same mac tend to confuse userspace.

-- 
MST

  reply	other threads:[~2018-05-22 15:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22  2:06 [PATCH net-next v11 0/5] Enable virtio_net to act as a standby for a passthru device Sridhar Samudrala
2018-05-22  2:06 ` [PATCH net-next v11 1/5] net: Introduce generic failover module Sridhar Samudrala
2018-05-22  2:06 ` [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework Sridhar Samudrala
2018-05-22  9:06   ` Jiri Pirko
2018-05-22  9:08     ` Jiri Pirko
2018-05-22 13:12       ` Michael S. Tsirkin
2018-05-22 13:14         ` Jiri Pirko
2018-05-22 13:17           ` Michael S. Tsirkin
2018-05-22 13:26             ` Jiri Pirko
2018-05-22 13:39               ` Michael S. Tsirkin
2018-05-22 15:13                 ` Jiri Pirko
2018-05-22 15:32                   ` Michael S. Tsirkin [this message]
2018-05-22 15:45                     ` Jiri Pirko
2018-05-22 16:52                       ` Michael S. Tsirkin
2018-05-22 17:38                         ` Jiri Pirko
2018-05-22 19:54                           ` Michael S. Tsirkin
2018-05-22 15:28       ` Samudrala, Sridhar
2018-05-22 15:36         ` Shepherd request (P83): Multipath TCP: Present Use Cases and an Upstream Future Jiri Pirko
2018-05-22 15:46           ` Michael S. Tsirkin
2018-05-22 16:12             ` [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework Jiri Pirko
2018-05-22 20:54               ` Samudrala, Sridhar
2018-05-23  6:27                 ` Jiri Pirko
2018-05-23 16:16                   ` Samudrala, Sridhar
2018-05-22  2:06 ` [PATCH net-next v11 3/5] net: Introduce net_failover driver Sridhar Samudrala
2018-05-22  8:59   ` Jiri Pirko
2018-05-22  2:06 ` [PATCH net-next v11 4/5] virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit Sridhar Samudrala
2018-05-22  2:06 ` [PATCH net-next v11 5/5] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala

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=20180522181804-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=aaron.f.brown@intel.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=anjali.singhai@intel.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kubakici@wp.pl \
    --cc=loseweigh@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).