From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65358C07E9B for ; Tue, 20 Jul 2021 15:13:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 515B060FF2 for ; Tue, 20 Jul 2021 15:13:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237484AbhGTOck (ORCPT ); Tue, 20 Jul 2021 10:32:40 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:47309 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238477AbhGTOLZ (ORCPT ); Tue, 20 Jul 2021 10:11:25 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id B59175816B8; Tue, 20 Jul 2021 10:51:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 20 Jul 2021 10:51:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=rr7CeS p57r9ki00p083nmHdZkD08g6VJi3ri00zZGDg=; b=TJMJ1jHafr/rpl5PIceP9q syX1rFXmkISdPiVMX9dqujREkYRULEbmsqU90X3Bbq7qxLzzn4f1qDUJE140/4fe MK76iEmixKYC8bFbdT1tXWA+Z9np2r9A3KBdivaCe4cRNjx7347E+6JDn7jiira5 jrNAEImAAyM+5YY/Il14GIOhSthVusUg4TP/6nfUDSsBwxvkSzX9i1W6/C925LUe H796xg1O0+s0TM7bulf5cafrAuKHwopqbiK8AXSEJ56tJs3ohc03akO3ODRqa6c8 0hbs03IdDwF325+Qwvrc7v8XxDRA5Ey+UxBC9ugdyy/9odCvHGPGcMkdBmgzeY4A == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfedvgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcuufgt hhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrthhtvg hrnheptdffkeekfeduffevgeeujeffjefhtefgueeugfevtdeiheduueeukefhudehleet necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepihguoh hstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Jul 2021 10:51:26 -0400 (EDT) Date: Tue, 20 Jul 2021 17:51:24 +0300 From: Ido Schimmel To: Vladimir Oltean Cc: "netdev@vger.kernel.org" , Jakub Kicinski , "David S. Miller" , Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Tobias Waldekranz , Roopa Prabhu , Nikolay Aleksandrov , Stephen Hemminger , "bridge@lists.linux-foundation.org" , Grygorii Strashko , Marek Behun , DENG Qingfang Subject: Re: [PATCH v5 net-next 00/10] Let switchdev drivers offload and unoffload bridge ports at their own convenience Message-ID: References: <20210720134655.892334-1-vladimir.oltean@nxp.com> <20210720141200.xgk3mlipp2mzerjl@skbuf> <20210720144617.ptqt5mqlw5stidep@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210720144617.ptqt5mqlw5stidep@skbuf> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jul 20, 2021 at 02:46:18PM +0000, Vladimir Oltean wrote: > On Tue, Jul 20, 2021 at 05:25:08PM +0300, Ido Schimmel wrote: > > If you don't want to change the order, then at least make the > > replay/cleanup optional and set it to 'false' for mlxsw. This should > > mean that the only change in mlxsw should be adding calls to > > switchdev_bridge_port_offload() / switchdev_bridge_port_unoffload() in > > mlxsw_sp_bridge_port_create() / mlxsw_sp_bridge_port_destroy(), > > respectively. > > I mean, I could guard br_{vlan,mdb,fdb}_replay() against NULL notifier > block pointers, and then make mlxsw pass NULL for both the atomic_nb and > blocking_nb. > > But why? How do you deal with a host-joined mdb that was auto-installed > while there was no port under the bridge? mlxsw does not currently support such entries. It's on my TODO list. When we add support for that, we will also take care of the replay. > How does anyone deal with that? What's optional about it? Why would > driver X opt out of it but Y not (apart for the case where driver X > does not offload MDBs at all, that I can understand). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=rr7CeS p57r9ki00p083nmHdZkD08g6VJi3ri00zZGDg=; b=TJMJ1jHafr/rpl5PIceP9q syX1rFXmkISdPiVMX9dqujREkYRULEbmsqU90X3Bbq7qxLzzn4f1qDUJE140/4fe MK76iEmixKYC8bFbdT1tXWA+Z9np2r9A3KBdivaCe4cRNjx7347E+6JDn7jiira5 jrNAEImAAyM+5YY/Il14GIOhSthVusUg4TP/6nfUDSsBwxvkSzX9i1W6/C925LUe H796xg1O0+s0TM7bulf5cafrAuKHwopqbiK8AXSEJ56tJs3ohc03akO3ODRqa6c8 0hbs03IdDwF325+Qwvrc7v8XxDRA5Ey+UxBC9ugdyy/9odCvHGPGcMkdBmgzeY4A == Date: Tue, 20 Jul 2021 17:51:24 +0300 From: Ido Schimmel Message-ID: References: <20210720134655.892334-1-vladimir.oltean@nxp.com> <20210720141200.xgk3mlipp2mzerjl@skbuf> <20210720144617.ptqt5mqlw5stidep@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210720144617.ptqt5mqlw5stidep@skbuf> Subject: Re: [Bridge] [PATCH v5 net-next 00/10] Let switchdev drivers offload and unoffload bridge ports at their own convenience List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Oltean Cc: Andrew Lunn , Florian Fainelli , Jiri Pirko , "netdev@vger.kernel.org" , "bridge@lists.linux-foundation.org" , Vivien Didelot , DENG Qingfang , Grygorii Strashko , Nikolay Aleksandrov , Roopa Prabhu , Jakub Kicinski , Marek Behun , "David S. Miller" , Tobias Waldekranz On Tue, Jul 20, 2021 at 02:46:18PM +0000, Vladimir Oltean wrote: > On Tue, Jul 20, 2021 at 05:25:08PM +0300, Ido Schimmel wrote: > > If you don't want to change the order, then at least make the > > replay/cleanup optional and set it to 'false' for mlxsw. This should > > mean that the only change in mlxsw should be adding calls to > > switchdev_bridge_port_offload() / switchdev_bridge_port_unoffload() in > > mlxsw_sp_bridge_port_create() / mlxsw_sp_bridge_port_destroy(), > > respectively. > > I mean, I could guard br_{vlan,mdb,fdb}_replay() against NULL notifier > block pointers, and then make mlxsw pass NULL for both the atomic_nb and > blocking_nb. > > But why? How do you deal with a host-joined mdb that was auto-installed > while there was no port under the bridge? mlxsw does not currently support such entries. It's on my TODO list. When we add support for that, we will also take care of the replay. > How does anyone deal with that? What's optional about it? Why would > driver X opt out of it but Y not (apart for the case where driver X > does not offload MDBs at all, that I can understand).