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 5CBD3C05027 for ; Fri, 3 Feb 2023 16:15:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233005AbjBCQPC (ORCPT ); Fri, 3 Feb 2023 11:15:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233309AbjBCQO4 (ORCPT ); Fri, 3 Feb 2023 11:14:56 -0500 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BC8092EDA; Fri, 3 Feb 2023 08:14:55 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C8DDE5C0109; Fri, 3 Feb 2023 11:14:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 03 Feb 2023 11:14:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1675440893; x=1675527293; bh=ZsTfWTfG+sKlRejLobl9gKT+7jxs vBf1Pr6YqiH/tfc=; b=fpwVXDIw98vLEX4I2DHTFp1G2HYcxx39hLDAmQtzN3ej rM4DwBU7iCWaWBA56FL5KJiPqoSa2aKno4iZTyJEtpIlVpN2EQREF6y5bK7KLds3 p+vw/kvvtH7VTMIV/EPGtNIDiRmcCW7NnRUliQcNZPIxDdEC3RNnsVH8K08hpGlT 3uy9234605kg27fNMWtfgPZmo9+3cN6Rjtg5fBvNvVpiDm9lSmtz1E9Qbo3yXRGW shHNi1kLjWQr5RgxuQHzZBtu7f1uEVGhrQ+2AmB0UCfTo2sPjxBf4jpJ1VOemO8x X1h+myMj/y9VmgCW+mczgf1jAAsFCk6nh13/y8dyZw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudegtddgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcu ufgthhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrth htvghrnhephefhtdejvdeiffefudduvdffgeetieeigeeugfduffdvffdtfeehieejtdfh jeeknecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Feedback-ID: i494840e7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 Feb 2023 11:14:51 -0500 (EST) Date: Fri, 3 Feb 2023 18:14:46 +0200 From: Ido Schimmel To: netdev@kapio-technology.com Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Vladimir Oltean , 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 , =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= , 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: [PATCH net-next 1/5] net: bridge: add dynamic flag to switchdev notifier Message-ID: References: <20230130173429.3577450-1-netdev@kapio-technology.com> <20230130173429.3577450-2-netdev@kapio-technology.com> <766efaf94fcb6362c5ceb176ad7955f1@kapio-technology.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <766efaf94fcb6362c5ceb176ad7955f1@kapio-technology.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 02, 2023 at 05:38:06PM +0100, netdev@kapio-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.