From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 19B478149D DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 431CE81493 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VBN3ioozJdloKVqUthzT5PrhF9aJ0DkVvhthx4l7/qw=; b=iUk5hio3JAzvBsKzUVzcd9RoW2iuLENjqCm5zOBz/ZRMR70RWPCJzAodNPOotduvI0Isja0vgxZ/lS5WXGN89tHjcnJTzgEfx1jj/wnfubM5Bdxqv64zBgJpFL42kUoOwU9nxzO2JBZaKyMi2fyvzzngfbJ5L4nZRh0RwzaJWAg= From: Vladimir Oltean Date: Thu, 27 Oct 2022 23:39:40 +0000 Message-ID: <20221027233939.x5jtqwiic2kmwonk@skbuf> References: <20221025100024.1287157-1-idosch@nvidia.com> <20221025100024.1287157-1-idosch@nvidia.com> <20221025100024.1287157-11-idosch@nvidia.com> <20221025100024.1287157-11-idosch@nvidia.com> In-Reply-To: <20221025100024.1287157-11-idosch@nvidia.com> <20221025100024.1287157-11-idosch@nvidia.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <8C07B525E266EB4C9C4CD3BD0107336F@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Bridge] [RFC PATCH net-next 10/16] mlxsw: spectrum_switchdev: Add support for locked FDB notifications List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ido Schimmel Cc: "petrm@nvidia.com" , "ivecera@redhat.com" , "netdev@vger.kernel.org" , "razor@blackwall.org" , "bridge@lists.linux-foundation.org" , "roopa@nvidia.com" , "netdev@kapio-technology.com" , "edumazet@google.com" , "mlxsw@nvidia.com" , "jiri@nvidia.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "davem@davemloft.net" On Tue, Oct 25, 2022 at 01:00:18PM +0300, Ido Schimmel wrote: > In Spectrum, learning happens in parallel to the security checks. > Therefore, regardless of the result of the security checks, a learning > notification will be generated by the device and polled later on by the > driver. >=20 > Currently, the driver reacts to learning notifications by programming > corresponding FDB entries to the device. When a port is locked (i.e., > has security checks enabled), this can no longer happen, as otherwise > any host will blindly gain authorization. >=20 > Instead, notify the learned entry as a locked entry to the bridge driver > that will in turn notify it to user space, in case MAB is enabled. User > space can then decide to authorize the host by clearing the "locked" > flag, which will cause the entry to be programmed to the device. >=20 > Signed-off-by: Ido Schimmel > --- So for mlxsw, the hardware/driver always gets learning notifications if learning is enabled (and regardless of MAB being enabled; with the mention that BR_PORT_MAB implies BR_LEARNING and so, with MAB, these notifications always come), and the driver always calls SWITCHDEV_FDB_ADD_T= O_BRIDGE, letting the bridge figure out if it should create a BR_FDB_LOCKED entry or to throw the notification away? Hans' case is different; he needs to configure the HW differently (MAB is more resource intensive). I suppose at some point, in his patch series, he will need to also offload BR_PORT_MAB, something which you didn't need. Ok. The thing is that it will become tricky to know, when adding BR_PORT_MAB to BR_PORT_FLAGS_HW_OFFLOAD, which drivers can offload MAB and which can't, without some prior knowledge. For example, Hans will need to patch mlxsw_sp_port_attr_br_pre_flags_set() to not reject BR_PORT_MAB, even if mlxsw will need to do nothing based on the flag, right?=