[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y90y9u+4PxWk4b9E@shredder>
Date: Fri, 3 Feb 2023 18:14:46 +0200
From: Ido Schimmel <idosch@...sch.org>
To: netdev@...io-technology.com
Cc: davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Vladimir Oltean <olteanv@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Hauke Mehrtens <hauke@...ke-m.de>,
Woojung Huh <woojung.huh@...rochip.com>,
"maintainer:MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER"
<UNGLinuxDriver@...rochip.com>, Sean Wang <sean.wang@...iatek.com>,
Landen Chao <Landen.Chao@...iatek.com>,
DENG Qingfang <dqfext@...il.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Clément Léger <clement.leger@...tlin.com>,
Jiri Pirko <jiri@...nulli.us>,
Ivan Vecera <ivecera@...hat.com>,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <razor@...ckwall.org>,
Russell King <linux@...linux.org.uk>,
Christian Marangi <ansuelsmth@...il.com>,
open list <linux-kernel@...r.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-arm-kernel@...ts.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
"open list:RENESAS RZ/N1 A5PSW SWITCH DRIVER"
<linux-renesas-soc@...r.kernel.org>,
"moderated list:ETHERNET BRIDGE" <bridge@...ts.linux-foundation.org>
Subject: Re: [PATCH net-next 1/5] net: bridge: add dynamic flag to switchdev
notifier
On Thu, Feb 02, 2023 at 05:38:06PM +0100, netdev@...io-technology.com wrote:
> On the first question please look here:
> https://lore.kernel.org/netdev/20230119134045.fqdt6zrna5x3iavt@skbuf/
It seems Vladimir also wants the new field to be named 'is_static'
instead of 'is_dyn'. In your reason you mention
'SWITCHDEV_FDB_ADD_TO_BRIDGE', but this is not the interesting case for
the field. This event is used for devices to notify the bridge on new
learned entries. The bridge marks them as "extern_learn" which means
that "dynamic" / "static" flags are irrelevant.
The interesting case for the new field is the bridge to device direction
('SWITCHDEV_FDB_ADD_TO_DEVICE'). Drivers need to be patched to take the
new field into account when deciding the policy to program the entry
with. They can do it just as well if you name the new field 'is_static'
instead of 'is_dyn'.
> On the second question it is what Oltean pointed out to me here...
> https://lore.kernel.org/netdev/20230118230135.szu6a7kvt2mjb3i5@skbuf/
>
> Oltean says there:
> "This is not true, because it assumes that DSA never called port_fdb_add()
> up until now for bridge FDB entries with the BR_FDB_STATIC flag unset,
> which is incorrect (it did)."
>
> Though as I see it, if it is only from the DSA layer on, the new is_dynamic
> flag would not be set anyway in the case he references. And as can be seen
> the change is in the bridge layer, as the rest is just propagating the flag,
> but it ensures that to set this flag that it comes from the user adding an
> FDB entry.
OK, so can't this hunk:
```
if (fdb_info->is_dyn)
fdb_flags |= DSA_FDB_FLAG_DYNAMIC;
```
Become:
```
if (fdb_info->is_dyn && !fdb_info->added_by_user)
fdb_flags |= DSA_FDB_FLAG_DYNAMIC;
```
?
Then there is no need to fold 'added_by_user' into 'is_dyn' in the
bridge driver. I *think* this is the change Vladimir asked you to do.
Powered by blists - more mailing lists