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.
next prev parent 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).