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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF1FDC38147 for ; Wed, 18 Jan 2023 22:35:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230070AbjARWfO (ORCPT ); Wed, 18 Jan 2023 17:35:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229564AbjARWfN (ORCPT ); Wed, 18 Jan 2023 17:35:13 -0500 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D11D15CFC8; Wed, 18 Jan 2023 14:35:10 -0800 (PST) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 3957518839F7; Wed, 18 Jan 2023 22:35:09 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id D5A7B25003AB; Wed, 18 Jan 2023 22:35:08 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id BD31391201E4; Wed, 18 Jan 2023 22:35:08 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Wed, 18 Jan 2023 23:35:08 +0100 From: netdev@kapio-technology.com To: Vladimir Oltean Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , "maintainer:MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER" , Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , Claudiu Manoil , Alexandre Belloni , =?UTF-8?Q?Cl=C3=A9ment_L=C3=A9ger?= , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Russell King , Christian Marangi , open list , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" , "open list:RENESAS RZ/N1 A5PSW SWITCH DRIVER" , "moderated list:ETHERNET BRIDGE" Subject: Re: [RFC PATCH net-next 2/5] net: dsa: propagate flags down towards drivers In-Reply-To: <20230117231750.r5jr4hwvpadgopmf@skbuf> References: <20230117185714.3058453-1-netdev@kapio-technology.com> <20230117185714.3058453-3-netdev@kapio-technology.com> <20230117231750.r5jr4hwvpadgopmf@skbuf> User-Agent: Gigahost Webmail Message-ID: X-Sender: netdev@kapio-technology.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2023-01-18 00:17, Vladimir Oltean wrote: > On Tue, Jan 17, 2023 at 07:57:11PM +0100, Hans J. Schultz wrote: >> Dynamic FDB flag needs to be propagated through the DSA layer to be >> added to drivers. >> Use a u16 for fdb flags for future use, so that other flags can also >> be >> sent the same way without having to change function interfaces. >> >> Signed-off-by: Hans J. Schultz >> --- >> @@ -3364,6 +3368,7 @@ static int dsa_slave_fdb_event(struct net_device >> *dev, >> struct dsa_port *dp = dsa_slave_to_port(dev); >> bool host_addr = fdb_info->is_local; >> struct dsa_switch *ds = dp->ds; >> + u16 fdb_flags = 0; >> >> if (ctx && ctx != dp) >> return 0; >> @@ -3410,6 +3415,9 @@ static int dsa_slave_fdb_event(struct net_device >> *dev, >> orig_dev->name, fdb_info->addr, fdb_info->vid, >> host_addr ? " as host address" : ""); >> >> + if (fdb_info->is_dyn) >> + fdb_flags |= DSA_FDB_FLAG_DYNAMIC; >> + > > Hmm, I don't think this is going to work with the > assisted_learning_on_cpu_port > feature ("if (switchdev_fdb_is_dynamically_learned(fdb_info))"). The > reason being > that a "dynamically learned" FDB entry (defined as this): > > static inline bool > switchdev_fdb_is_dynamically_learned(const struct > switchdev_notifier_fdb_info *fdb_info) > { > return !fdb_info->added_by_user && !fdb_info->is_local; > } > > is also dynamic in the DSA_FDB_FLAG_DYNAMIC sense. But we install a > static FDB entry for it on the CPU port. > > And in your follow-up patch 3/5, you make all drivers except mv88e6xxx > ignore all DSA_FDB_FLAG_DYNAMIC entries (including the ones snooped > from > address learning on software interfaces). So this breaks those drivers > which don't implement DSA_FDB_FLAG_DYNAMIC but do set > ds->assisted_learning_on_cpu_port > to true. I am not sure I understand you entirely. From my standpoint I see it as so: that until now any fdb entry coming to port_fdb_add() (or port_fdb_del()) are seen as static entries. And this changes nothing with respect to those static entries as how drivers handle them. When the new dynamic flag is true, all drivers will ignore it in patch #3, so basically nothing will change by that. Then in patch #5 the dynamic flag is handled by the mv88e6xxx driver. I don't know the assisted_learning_on_cpu_port feature you mention, but there has still not been anything but static entries going towards port_fdb_add() yet... > > I think you also want to look at the added_by_user flag to disambiguate > between a dynamic FDB entry added from learning (which it's ok to > offload as static, because software ageing will remove it) and one > added > by the user. > >> INIT_WORK(&switchdev_work->work, dsa_slave_switchdev_event_work); >> switchdev_work->event = event; >> switchdev_work->dev = dev; >> @@ -3418,6 +3426,7 @@ static int dsa_slave_fdb_event(struct net_device >> *dev, >> ether_addr_copy(switchdev_work->addr, fdb_info->addr); >> switchdev_work->vid = fdb_info->vid; >> switchdev_work->host_addr = host_addr; >> + switchdev_work->fdb_flags = fdb_flags; >> >> dsa_schedule_work(&switchdev_work->work); >>