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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AF0B9C61DA4 for ; Fri, 3 Feb 2023 16:16:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qWvgJRFkHXvdlX24X2eY24W4iOUU1yyaMoF9jP06I8M=; b=ExReP6fF97Vzzk qkKeGljTysa5u5/vqgnCXcoCjZVnjrr3ZT36mlBPGnaK6sfeBmSe8p/T+M5Qi1m39ooXwNwD/BLLL 3atVHHB3MLjM5iblQskvA72xFVajXVzrBIRTk70Gth24w/K1VAkJ4fcDlPSUy99WwtxFOSU/C0jpq kC5r+/3mybxHtbj7+tbjzg45axPeXiLg2KekpwAIPBUAH073+V2Tq+DQlnSuDWDSnHM1aoU4UhZMf mAJKNI41f+J/BoMEETzbKV0s6Bg6WTA7oUjQcJt3KXpMsjXy0RR/Vn5d+oaMgrtoMdji19OR1b0lu 943M8+PkfdWN9CyUX1jg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNyiM-002syf-HW; Fri, 03 Feb 2023 16:15:02 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNyiJ-002sxl-2y; Fri, 03 Feb 2023 16:15:00 +0000 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-Disposition: inline In-Reply-To: <766efaf94fcb6362c5ceb176ad7955f1@kapio-technology.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230203_081459_400414_F8745F75 X-CRM114-Status: GOOD ( 17.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel