[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220214104217.5asztbbep4utqllh@skbuf>
Date: Mon, 14 Feb 2022 10:42:18 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Nikolay Aleksandrov <nikolay@...dia.com>
CC: Ido Schimmel <idosch@...sch.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
Roopa Prabhu <roopa@...dia.com>, Jiri Pirko <jiri@...dia.com>,
Ido Schimmel <idosch@...dia.com>,
Rafael Richter <rafael.richter@....de>,
Daniel Klauer <daniel.klauer@....de>,
Tobias Waldekranz <tobias@...dekranz.com>
Subject: Re: [RFC PATCH net-next 0/5] Replay and offload host VLAN entries in
DSA
On Mon, Feb 14, 2022 at 12:27:57PM +0200, Nikolay Aleksandrov wrote:
> On 14/02/2022 12:07, Vladimir Oltean wrote:
> > On Mon, Feb 14, 2022 at 11:59:02AM +0200, Ido Schimmel wrote:
> >> Sounds good to me as well. I assume it means patches #1 and #2 will be
> >> changed to make use of this flag and patch #3 will be dropped?
> >
> > Not quite. Patches 1 and 2 will be kept as-is, since fundamentally,
> > their goal is to eliminate a useless SWITCHDEV_PORT_OBJ_ADD event when
> > really nothing has changed (flags == old_flags, no brentry was created).
> >
>
> I don't think that's needed, a two-line change like
> "vlan_already_exists == true && old_flags == flags then do nothing"
> would do the trick in DSA for all drivers and avoid the churn of these patches.
> It will also keep the order of the events consistent with (most of) the rest
> of the bridge. I'd prefer the simpler change which avoids config reverts than
> these two patches.
I understand you prefer the simpler change which avoids reverting the
struct net_bridge_vlan on error, but "vlan_already_exists == true &&
old_flags == flags then do nothing" is not possible in DSA, because DSA
does not know "old_flags" unless we also pass that via
struct switchdev_obj_port_vlan. If we do that, I don't have much of an
objection, but it still seems cleaner to me if the bridge didn't notify
switchdev at all when it has nothing to say.
Or where do you mean to place the two-line change?
Powered by blists - more mailing lists