[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180605145222.477e5ae8@xeon-e3>
Date: Tue, 5 Jun 2018 14:52:22 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: kys@...rosoft.com, haiyangz@...rosoft.com, davem@...emloft.net,
sridhar.samudrala@...el.com, netdev@...r.kernel.org,
Stephen Hemminger <sthemmin@...rosoft.com>
Subject: Re: [PATCH net] failover: eliminate callback hell
On Tue, 5 Jun 2018 22:38:43 +0300
"Michael S. Tsirkin" <mst@...hat.com> wrote:
> >
> > See:
> > https://patchwork.ozlabs.org/patch/851711/
>
> Let me try to summarize that:
>
> You wanted to speed up the delayed link up. You had an idea to
> additionally take link up when userspace renames the interface (standby
> one which is also the failover for netvsc).
>
> But userspace might not do any renames, in which case there will
> still be the delay, and so this never got applied.
>
> Is this a good summary?
>
> Davem said delay should go away completely as it's not robust, and I
> think I agree. So I don't think we should make all failover users use
> delay. IIUC failover kept a delay option especially for netvsc to
> minimize the surprise factor. Hopefully we can come up with
> something more robust and drop that option completely.
The timeout was the original solution to how to complete setup after
userspace has had a chance to rename the device. Unfortunately, the whole network
device initialization (cooperation with udev and userspace) is a a mess because
there is no well defined specification, and there are multiple ways userspace
does this in old and new distributions. The timeout has its own issues
(how long, handling errors during that window, what if userspace modifies other
device state); and open to finding a better solution.
My point was that if name change can not be relied on (or used) by netvsc,
then we can't allow it for net_failover either.
Powered by blists - more mailing lists