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 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.