netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kys@microsoft.com, haiyangz@microsoft.com, davem@davemloft.net,
	sridhar.samudrala@intel.com, netdev@vger.kernel.org,
	Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [PATCH net] failover: eliminate callback hell
Date: Tue, 5 Jun 2018 11:53:05 -0700	[thread overview]
Message-ID: <20180605115305.502a7ebb@xeon-e3> (raw)
In-Reply-To: <20180605211927-mutt-send-email-mst@kernel.org>

On Tue, 5 Jun 2018 21:35:26 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> Thanks, I think this is nice patch but I wonder whether it can be split
> up somewhat. Not all of it is uncontroversial.

I started that way, but then I was fixing code that was later deleted.
The big change was eliminating the callbacks.

> 
> On Mon, Jun 04, 2018 at 08:42:31PM -0700, Stephen Hemminger wrote:
> >   * The matching of secondary device to primary device policy
> >     is up to the network device. Both net_failover and netvsc
> >     will use MAC for now but can change separately.  
> 
> I actually suspect both will change to a serial number
> down the road.
> 
> >   * The match policy is only used during initial discovery; after
> >     that the secondary device knows what the upper device is because
> >     of the parent/child relationship; no searching is required.  
> 
> That would obviously be an improvement - does it have to be tied with
> rest of changes?

This was not possible with the version of the common code that
is in net now.

> 
> >   * Now, netvsc and net_failover use the same delayed work type
> >     mechanism for setup. Previously, net_failover code was triggering off
> >     name change but a similar policy was rejected for netvsc.
> >     "what is good for the goose is good for the gander"  
> 
> I don't really understand what you are saying here.  I think the delayed
> hack is kind of ugly and seems racy.  Current failover code was rejected
> by whom?  Why is new one good and for whom?  Did you want to do a name
> change in netvsc but it was rejected? Could you clarify please?

See:
   https://patchwork.ozlabs.org/patch/851711/

> 
> >   * The net_failover private device info 'struct net_failover_info'
> >     should have been private to the driver file, not a visible
> >     API.
> > 
> >   * The net_failover device should use SET_NETDEV_DEV
> >     that is intended only for physical devices not virtual devices.  
> 
> You mean should not.

Yes. Virtual device should not set device parent.

> 
> >   * No point in having DocBook style comments on a driver file.
> >     They only make sense on an external exposed API.
> > 
> >   * net_failover only supports Ethernet, so use ether_addr_copy.  
> 
> It is since you need to know about all the things you need to copy, and
> because of mac matching.  But it isn't too much effort to add more
> transports and I don't see value in going in the reverse direction and
> making it more ethernet specific that it already is.

Sure, then do memcpy base on addr_len

> 
> >   * Set permanent and current address of net_failover device
> >     to match the primary.
> > 
> >   * Carrier should be marked off before registering device
> >     the net_failover device.  
> 
> Are above two bugfixes?

Yes.

> 
> >   * Use netdev_XXX for log messages, in net_failover (not dev_xxx)
> > 
> >   * Since failover infrastructure is about linking devices just
> >     use RTNL no need for other locking in init and teardown.
> > 
> >   * Don't bother with ERR_PTR() style return if only possible
> >     return is success or no memory.
> > 
> >   * As much as possible, the terms master and slave should be avoided
> >     because of their cultural connotations.  
> 
> Also for consistency, failover is calling these primary and standby now.

Good, let's standardize on that. 

> 
> > Note; this code has been tested on Hyper-V
> > but is compile tested only on virtio.
> > 
> > Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > ---
> > 
> > Although this patch needs to go into 4.18 (linux-net),  
> 
> I'd rather we focused on fixing bugs in 4.18, and left refactoring to
> 4.19.
>

Either we fix or revert the current code in 4.18.
Sorry, I am not having callback hell code in any vendor or upstream kernel.

  reply	other threads:[~2018-06-05 18:53 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 [this message]
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
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=20180605115305.502a7ebb@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=davem@davemloft.net \
    --cc=haiyangz@microsoft.com \
    --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 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).