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 1FE83C433E0 for ; Mon, 1 Mar 2021 15:35:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DD29A64DD2 for ; Mon, 1 Mar 2021 15:35:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237273AbhCAPe6 (ORCPT ); Mon, 1 Mar 2021 10:34:58 -0500 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]:33891 "EHLO wnew1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237259AbhCAPek (ORCPT ); Mon, 1 Mar 2021 10:34:40 -0500 X-Greylist: delayed 632 seconds by postgrey-1.27 at vger.kernel.org; Mon, 01 Mar 2021 10:34:39 EST Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id A6D53750; Mon, 1 Mar 2021 10:22:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 01 Mar 2021 10:22:55 -0500 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=fm2; bh=IauOCt 8zqU4njIU9F18ywK4S1TDq0EnUPF5VohKD7Ns=; b=Q8BF4wTc2fkqcRhoqTzj3K C94pycJkOzebMYsAyraSWKyL9O8NSuI5vmO8WLJUFgat2K7d2SZ5b2FlmF4rR5WK WozhY+9KwcKy2B6nkx6G4GT9ILMfQ4aa7OaqDWXyS8m2NYAw8zVUQ2XgVgdCmQzT tlDCTmorzCuwm/iRJ//cmpI9/NTL9JXrd5eSG2yLRNhAAn4NUfRxe16xtHB8N0za j5AwTpuvLZm6M4MY/wPDWU4hbBtEtrgr+Pb2fK48MMl6FS8S2vcrU+MmF4iiqh1R oyWiYQBJArgBd5qYMqTOmKFP/y6IVU5HnExcj4Gbv4/B6mVKiwYF9WmmReD37aKQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcuufgt hhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrthhtvg hrnheptdffkeekfeduffevgeeujeffjefhtefgueeugfevtdeiheduueeukefhudehleet necukfhppeekgedrvddvledrudehfedrgeegnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepihguohhstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: from localhost (igld-84-229-153-44.inter.net.il [84.229.153.44]) by mail.messagingengine.com (Postfix) with ESMTPA id BC6311080066; Mon, 1 Mar 2021 10:22:52 -0500 (EST) Date: Mon, 1 Mar 2021 17:22:48 +0200 From: Ido Schimmel To: Vladimir Oltean Cc: netdev@vger.kernel.org, Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , DENG Qingfang , Tobias Waldekranz , George McCollister , Vlad Yasevich , Roopa Prabhu , Nikolay Aleksandrov Subject: Re: [RFC PATCH v2 net-next 05/17] net: bridge: implement unicast filtering for the bridge device Message-ID: References: <20210224114350.2791260-1-olteanv@gmail.com> <20210224114350.2791260-6-olteanv@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210224114350.2791260-6-olteanv@gmail.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Feb 24, 2021 at 01:43:38PM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean > > The bridge device currently goes into promiscuous mode when it has an > upper with a different MAC address than itself. But it could do better: > it could sync the MAC addresses of its uppers to the software FDB, as > local entries pointing to the bridge itself. This is compatible with > switchdev, since drivers are now instructed to trap these MAC addresses > to the CPU. > > Note that the dev_uc_add API does not propagate VLAN ID, so this only > works for VLAN-unaware bridges. IOW, it breaks VLAN-aware bridges... I understand that you do not want to track bridge uppers, but once you look beyond L2 you will need to do it anyway. Currently, you only care about getting packets with specific DMACs to the CPU. With L3 offload you will need to send these packets to your router block instead and track other attributes of these uppers such as their MTU so that the hardware will know to generate MTU exceptions. In addition, the hardware needs to know the MAC addresses of these uppers so that it will rewrite the SMAC of forwarded packets.