From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jakub Kicinski <kubakici@wp.pl>
Cc: si-wei liu <si-wei.liu@oracle.com>,
"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
Siwei Liu <loseweigh@gmail.com>, Jiri Pirko <jiri@resnulli.us>,
Stephen Hemminger <stephen@networkplumber.org>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
virtualization@lists.linux-foundation.org, "Brandeburg,
Jesse" <jesse.brandeburg@intel.com>,
Alexander Duyck <alexander.h.duyck@intel.com>,
Jason Wang <jasowang@redhat.com>,
liran.alon@oracle.com
Subject: Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
Date: Thu, 28 Feb 2019 15:14:55 -0500 [thread overview]
Message-ID: <20190228151349-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190228115641.7afe6f09@cakuba.netronome.com>
On Thu, Feb 28, 2019 at 11:56:41AM -0800, Jakub Kicinski wrote:
> On Thu, 28 Feb 2019 14:36:56 -0500, Michael S. Tsirkin wrote:
> > > It is a bit of a the chicken or the egg situation ;) But users can
> > > just blacklist, too. Anyway, I think this is far better than module
> > > parameters
> >
> > Sorry I'm a bit confused. What is better than what?
>
> I mean that blacklist net_failover or module param to disable
> net_failover and handle in user space are better than trying to solve
> the renaming at kernel level (either by adding module params that make
> the kernel rename devices or letting user space change names of running
> devices if they are slaves).
>
> > > for twiddling kernel-based interface naming policy.. :S
> >
> > I see your point. But my point is slave names don't really matter, only
> > master name matters. So I am not sure there's any policy worth talking
> > about here.
>
> Oh yes, I don't disagree with you, but others seems to want to rename
> the auto-bonded lower devices. Which can be done trivially if it was
> a daemon in user space instantiating the auto-bond. We are just
> providing a basic version of auto-bonding in the kernel. If there are
> extra requirements on policy, or naming - the whole thing is better
> solved in user space.
OK so it seems that you would be happy with a combination of the module
parameter disabling failover completely and renaming primary in kernel?
Did I get it right?
--
MST
next prev parent reply other threads:[~2019-02-28 20:15 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 18:59 [RFC PATCH net-next v6 0/4] Enable virtio_net to act as a backup for a passthru device Sridhar Samudrala
2018-04-10 18:59 ` [RFC PATCH net-next v6 1/4] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit Sridhar Samudrala
2018-04-10 18:59 ` [RFC PATCH net-next v6 2/4] net: Introduce generic bypass module Sridhar Samudrala
2018-04-11 15:51 ` Jiri Pirko
2018-04-11 19:13 ` Samudrala, Sridhar
2018-04-18 9:25 ` Jiri Pirko
2018-04-18 18:43 ` Samudrala, Sridhar
2018-04-18 19:13 ` Jiri Pirko
2018-04-18 19:46 ` Michael S. Tsirkin
2018-04-18 20:32 ` Jiri Pirko
2018-04-18 22:46 ` Samudrala, Sridhar
2018-04-19 6:35 ` Jiri Pirko
2018-04-19 4:08 ` Michael S. Tsirkin
2018-04-19 7:22 ` Jiri Pirko
2018-04-10 18:59 ` [RFC PATCH net-next v6 3/4] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala
2018-04-10 18:59 ` [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework Sridhar Samudrala
2018-04-10 21:26 ` Stephen Hemminger
2018-04-10 22:56 ` Samudrala, Sridhar
2018-04-10 23:28 ` Michael S. Tsirkin
2018-04-10 23:44 ` Siwei Liu
2018-04-10 23:59 ` Stephen Hemminger
2018-04-11 7:50 ` Jiri Pirko
2018-04-11 1:21 ` Michael S. Tsirkin
2018-04-11 7:53 ` Jiri Pirko
2019-02-22 1:14 ` net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework) Siwei Liu
2019-02-22 1:39 ` Michael S. Tsirkin
2019-02-22 3:33 ` [virtio-dev] " si-wei liu
[not found] ` <91d4cbb1-be7a-b53c-6b2a-99bef07e7c53@intel.com>
2019-02-22 7:55 ` si-wei liu
2019-02-22 12:58 ` Rob Miller
2019-02-22 15:14 ` Michael S. Tsirkin
2019-02-26 0:58 ` si-wei liu
2019-02-26 1:39 ` Stephen Hemminger
2019-02-26 2:05 ` Michael S. Tsirkin
2019-02-27 0:49 ` si-wei liu
2019-02-26 2:08 ` Michael S. Tsirkin
2019-02-27 0:17 ` si-wei liu
2019-02-27 21:57 ` Stephen Hemminger
2019-02-27 22:30 ` si-wei liu
2019-02-27 22:38 ` Michael S. Tsirkin
2019-02-27 23:34 ` si-wei liu
2019-02-27 23:50 ` Michael S. Tsirkin
2019-02-28 0:00 ` Liran Alon
2019-02-28 0:03 ` Stephen Hemminger
2019-02-28 0:38 ` Michael S. Tsirkin
2019-02-28 0:38 ` si-wei liu
2019-02-28 0:41 ` Michael S. Tsirkin
2019-02-28 0:52 ` Jakub Kicinski
2019-02-28 1:26 ` Michael S. Tsirkin
2019-02-28 1:52 ` Jakub Kicinski
2019-02-28 4:47 ` Michael S. Tsirkin
2019-02-28 18:13 ` Jakub Kicinski
2019-02-28 19:36 ` Michael S. Tsirkin
2019-02-28 19:56 ` Jakub Kicinski
2019-02-28 20:14 ` Michael S. Tsirkin [this message]
2019-02-28 23:31 ` Jakub Kicinski
2019-03-01 0:20 ` Siwei Liu
2019-03-01 1:05 ` Jakub Kicinski
2019-03-02 0:30 ` Siwei Liu
2019-02-28 9:32 ` si-wei liu
2019-02-28 14:26 ` Michael S. Tsirkin
2019-03-01 1:30 ` si-wei liu
2019-03-01 13:27 ` Michael S. Tsirkin
2019-03-01 20:55 ` si-wei liu
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=20190228151349-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=kubakici@wp.pl \
--cc=liran.alon@oracle.com \
--cc=loseweigh@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=si-wei.liu@oracle.com \
--cc=sridhar.samudrala@intel.com \
--cc=stephen@networkplumber.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).