[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6562a2bf-72f7-92b6-8a34-489aab6884ce@oracle.com>
Date: Wed, 27 Mar 2019 15:48:55 -0700
From: si-wei liu <si-wei.liu@...cle.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
sridhar.samudrala@...el.com, davem@...emloft.net, kubakici@...pl,
alexander.duyck@...il.com, jiri@...nulli.us,
netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org,
liran.alon@...cle.com, boris.ostrovsky@...cle.com,
vijay.balakrishna@...cle.com
Subject: Re: [PATCH net v3] failover: allow name change on IFF_UP slave
interfaces
On 3/27/2019 3:31 PM, si-wei liu wrote:
>
>
> On 3/27/2019 3:16 PM, Michael S. Tsirkin wrote:
>> On Wed, Mar 27, 2019 at 01:10:10PM -0700, si-wei liu wrote:
>>> Another less safer option is that we just notify userspace anyway
>>> without
>>> sending down/up event around, as I don't see *any real application*
>>> cares
>>> about the link state or whatsoever when it attempts to detect rename.
>> How do you write a race ree handler then? ATM just detecting link up is
>> sufficient and covers 100% of cases. Seems like a good idea to keep it
>> that way.
>>
> What do you mean? Which flag or attribute do you think 100% of the
> userspace regard it as link up? And why userspace that cares about
> name change needs to double check whether link is up or not? I'm
> sorry, but are you sure this is the 100% case that every userspace app
> does it like what you're claiming?
>
> -Siwei
To me even the any flag checking regarding link state is unnecessary as
it's hard for userspace apps to follow precisely the name change
together with the link state. I'm not sure if you still persist in
sending link down/up event. What the userspace apps that care about the
name so far as I see chase the name through ifindex. I'm really doubtful
if link state is that important to them. But if you really need that
consistency I'd say bouncing the link is perhaps the only safe option.
-Siwei
Powered by blists - more mailing lists