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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD4E0C433F5 for ; Wed, 27 Oct 2021 08:16:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C44D160C40 for ; Wed, 27 Oct 2021 08:16:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238798AbhJ0ITH (ORCPT ); Wed, 27 Oct 2021 04:19:07 -0400 Received: from new1-smtp.messagingengine.com ([66.111.4.221]:51529 "EHLO new1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231715AbhJ0ITH (ORCPT ); Wed, 27 Oct 2021 04:19:07 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 1B7C258041D; Wed, 27 Oct 2021 04:16:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 27 Oct 2021 04:16:42 -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=fm1; bh=JtuJqq Y23rcol/towiKKl+J/LdEhOnMpOw6UCqLwaj4=; b=SGhwE/k9dl8BsjwvnX/R5d 6tXEKx/2RzS0D092QpXgxY1WfahSxNs/LPD8oPLz6KIR5/yyJ7+9ZPROxS9EJcAG FtmH5ajiufMjoJdJdk00ZbQ+rjeH5EXmi0rLhsPR35sUYvWYnm6ABCiauYQv33JW bo85Jw8erhGA+K0e0g/Kpmve6fc2xbLI3QNf6uVPnlLEUM++HiC8sZ7GDhkT4e8a eE5HtbAVYGEiejWWhIKjTd2zXxHdtvmerezxa2/dcFBmS2FhHOuOsUvMjRLN8TwN X0XgkQ9VL6S3fkKIPoVinGYKALWrEHVXpEkQYF8zmoCd5DwG5HrVdAjo5xmA+zxw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegtdcutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcuufgthhhi mhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrthhtvghrnh eptdffkeekfeduffevgeeujeffjefhtefgueeugfevtdeiheduueeukefhudehleetnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepihguohhstg hhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Oct 2021 04:16:40 -0400 (EDT) Date: Wed, 27 Oct 2021 11:16:38 +0300 From: Ido Schimmel To: Vladimir Oltean , nikolay@nvidia.com Cc: netdev@vger.kernel.org, Ido Schimmel , Jakub Kicinski , "David S. Miller" , Roopa Prabhu , Nikolay Aleksandrov , Andrew Lunn , Florian Fainelli , Vivien Didelot , Vladimir Oltean , Jiri Pirko Subject: Re: [PATCH net-next 6/8] net: bridge: move br_fdb_replay inside br_switchdev.c Message-ID: References: <20211026142743.1298877-1-vladimir.oltean@nxp.com> <20211026142743.1298877-7-vladimir.oltean@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211026142743.1298877-7-vladimir.oltean@nxp.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Oct 26, 2021 at 05:27:41PM +0300, Vladimir Oltean wrote: > br_fdb_replay is only called from switchdev code paths, so it makes > sense to be disabled if switchdev is not enabled in the first place. > > As opposed to br_mdb_replay and br_vlan_replay which might be turned off > depending on bridge support for multicast and VLANs, FDB support is > always on. So moving br_mdb_replay and br_vlan_replay inside > br_switchdev.c would mean adding some #ifdef's in br_switchdev.c, so we > keep those where they are. TBH, for consistency with br_mdb_replay() and br_vlan_replay(), it would have been good to keep it where it is, but ... > > The reason for the movement is that in future changes there will be some > code reuse between br_switchdev_fdb_notify and br_fdb_replay. this seems like a good reason, so: Reviewed-by: Ido Schimmel Nik, WDYT?