[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190225210428-mutt-send-email-mst@kernel.org>
Date: Mon, 25 Feb 2019 21:05:24 -0500
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: si-wei liu <si-wei.liu@...cle.com>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
Siwei Liu <loseweigh@...il.com>, Jiri Pirko <jiri@...nulli.us>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
virtio-dev <virtio-dev@...ts.oasis-open.org>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
Alexander Duyck <alexander.h.duyck@...el.com>,
Jakub Kicinski <kubakici@...pl>,
Jason Wang <jasowang@...hat.com>, liran.alon@...cle.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)
On Mon, Feb 25, 2019 at 05:39:12PM -0800, Stephen Hemminger wrote:
> > >>> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
> > >>> about moving them to a hidden network namespace so that they are not visible from the default namespace.
> > >>> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
> > >>> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
> > >> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
> > >> model as much transparent to a real NIC as possible, while a hidden netns is
> > >> just the vehicle). However, I recall there was resistance around this
> > >> discussion that even the concept of hiding itself is a taboo for Linux
> > >> netdev. I would like to summon potential alternatives before concluding
> > >> 1-netdev is the only solution too soon.
> > >>
> > >> Thanks,
> > >> -Siwei
> > > Your scripts would not work at all then, right?
> > At this point we don't claim images with such usage as SR-IOV live
> > migrate-able. We would flag it as live migrate-able until this ethtool
> > config issue is fully addressed and a transparent live migration
> > solution emerges in upstream eventually.
>
> The hyper-v netvsc with 1-dev model uses a timeout to allow udev to do its rename.
> I proposed a patch to key state change off of the udev rename, but that patch was
> rejected.
Of course that would mean nothing works without udev - was
that the objection? Could you help me find that discussion pls?
--
MST
Powered by blists - more mailing lists