[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87czzr71a4.fsf@waldekranz.com>
Date: Thu, 03 Dec 2020 09:16:03 +0100
From: Tobias Waldekranz <tobias@...dekranz.com>
To: Jay Vosburgh <jay.vosburgh@...onical.com>
Cc: davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
vivien.didelot@...il.com, f.fainelli@...il.com, olteanv@...il.com,
vfalico@...il.com, andy@...yhouse.net, netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 1/4] net: bonding: Notify ports about their initial state
On Wed, Dec 02, 2020 at 16:39, Jay Vosburgh <jay.vosburgh@...onical.com> wrote:
> Tobias Waldekranz <tobias@...dekranz.com> wrote:
>>I could look at hoisting up the linking op before the first
>>notification. My main concern is that this is a new subsystem to me, so
>>I am not sure how to determine the adequate test coverage for a change
>>like this.
>>
>>Another option would be to drop this change from this series and do it
>>separately. It would be nice to have both team and bond working though.
>>
>>Not sure why I am the first to run into this. Presumably the mlxsw LAG
>>offloading would be affected in the same way. Maybe their main use-case
>>is LACP.
>
> I'm not sure about mlxsw specifically, but in the configurations
> I see, LACP is by far the most commonly used mode, with active-backup a
> distant second. I can't recall the last time I saw a production
> environment using balance-xor.
Makes sense. We (Westermo) have a few customers using static LAGs, so it
does happen. That said, LACP is way more common for us as well.
> I think that in the perfect world there should be exactly one
> such notification, and occurring in the proper sequence. A quick look
> at the kernel consumers of the NETDEV_CHANGELOWERSTATE event (mlx5,
> mlxsw, and nfp, looks like) suggests that those shouldn't have an issue.
>
> In user space, however, there are daemons that watch the events,
> and may rely on the current ordering. Some poking around reveals odd
> bugs in user space when events are rearranged, so I think the prudent
> thing is to not mess with what's there now, and just add the one event
> here (i.e., apply your patch as-is).
This is exactly the sort of thing I was worried about. Thank you so much
for testing it!
Powered by blists - more mailing lists