[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221031083210.fxitourrquc4bo6p@skbuf>
Date: Mon, 31 Oct 2022 08:32:11 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Ido Schimmel <idosch@...dia.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bridge@...ts.linux-foundation.org"
<bridge@...ts.linux-foundation.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"jiri@...dia.com" <jiri@...dia.com>,
"petrm@...dia.com" <petrm@...dia.com>,
"ivecera@...hat.com" <ivecera@...hat.com>,
"roopa@...dia.com" <roopa@...dia.com>,
"razor@...ckwall.org" <razor@...ckwall.org>,
"netdev@...io-technology.com" <netdev@...io-technology.com>,
"mlxsw@...dia.com" <mlxsw@...dia.com>
Subject: Re: [RFC PATCH net-next 10/16] mlxsw: spectrum_switchdev: Add support
for locked FDB notifications
On Sun, Oct 30, 2022 at 10:23:07AM +0200, Ido Schimmel wrote:
> Right. I'm quite reluctant to add the MAB flag to
> BR_PORT_FLAGS_HW_OFFLOAD as part of this patchset for the simple reason
> that it is not really needed. I'm not worried about someone adding it
> later when it is actually needed. We will probably catch the omission
> during code review. Worst case, we have a selftest that will break,
> notifying us that a bug fix is needed.
For drivers which don't emit SWITCHDEV_FDB_ADD_TO_BRIDGE but do offload
BR_PORT_LOCKED (like mv88e6xxx), things will not work correctly on day 1
of BR_PORT_MAB because they are not told MAB is enabled, so they have no
way of rejecting it until things work properly with the offload in place.
It's the same reason for which we have BR_HAIRPIN_MODE | BR_ISOLATED |
BR_MULTICAST_TO_UNICAST in BR_PORT_FLAGS_HW_OFFLOAD, even if nobody acts
upon them.
Powered by blists - more mailing lists