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=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 5385FC0650E for ; Sun, 7 Jul 2019 10:28:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 157442083B for ; Sun, 7 Jul 2019 10:28:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="JJ1AE9s7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727372AbfGGK2u (ORCPT ); Sun, 7 Jul 2019 06:28:50 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:46999 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727125AbfGGK2t (ORCPT ); Sun, 7 Jul 2019 06:28:49 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 627762134B; Sun, 7 Jul 2019 06:28:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 07 Jul 2019 06:28:48 -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=fm3; bh=aaMt57 yZYfyil/RreBDqceJPqRXy35bdrymaxqJSnG0=; b=JJ1AE9s7DWlohY0kD+lIAU N0ROSJOzMtfx+PJcACFCxvV30Rvz9uawSSTRdxVRED1GHj0MLU+GK5tRyuaZnMOV uRapzg48IzwAzjY3RzMspym7FI6qzUaU8WGjWsBFAvIHK6LxiU3zfTu//ti0p/ON f0u0o6OXK1WvKkHpaMbkcTrWBQgC/H8CC8zy6Xeo/5UWfBT/TKKPoiqqLaJ2venY 7xteTbB1/lRDu6MtRvcGhZtfo6v+cqqLhUF7sinU63JCpboDlqIHInHSWft29vcQ 3PmKjV1xxc4hoQNuuOwjJU7ZxHVM+ccVekZOQpRuUt0xD6/qfiRBInvRn27WdhkA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrfeekgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucfkphepudelfe drgeejrdduieehrddvhedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhes ihguohhstghhrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (unknown [193.47.165.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 83D6B8005A; Sun, 7 Jul 2019 06:28:46 -0400 (EDT) Date: Sun, 7 Jul 2019 13:28:44 +0300 From: Ido Schimmel To: Vivien Didelot Cc: Ido Schimmel , Florian Fainelli , "netdev@vger.kernel.org" , Jiri Pirko , "linux@armlinux.org.uk" , "andrew@lunn.ch" , "davem@davemloft.net" Subject: Re: [RFC net-next] net: dsa: add support for MC_DISABLED attribute Message-ID: <20190707102844.GA8487@splinter> References: <20190620235639.24102-1-vivien.didelot@gmail.com> <5d653a4d-3270-8e53-a5e0-88ea5e7a4d3f@gmail.com> <20190621172952.GB9284@t480s.localdomain> <20190623070949.GB13466@splinter> <20190705120149.GB17996@t480s.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190705120149.GB17996@t480s.localdomain> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jul 05, 2019 at 12:01:49PM -0400, Vivien Didelot wrote: > Hi Ido, > > On Sun, 23 Jun 2019 07:09:52 +0000, Ido Schimmel wrote: > > > Russell, Ido, Florian, so far I understand that a multicast-unaware > > > bridge must flood unknown traffic everywhere (CPU included); > > > and a multicast-aware bridge must only flood its ports if their > > > mcast_flood is on, and known traffic targeting the bridge must be > > > offloaded accordingly. Do you guys agree with this? > > > > When multicast snooping is enabled unregistered multicast traffic should > > only be flooded to mrouter ports. > > I've figured out that this is what I need to prevent the flooding of undesired > multicast traffic to the CPU port of the switch. The bridge itself has a > multicast_router attribute which can be disabled, that is when I should drop > unknown multicast traffic. > > However with SWITCHDEV_ATTR_ID_BRIDGE_MROUTER implemented, this > attribute is always called with .mrouter=0, regardless the value of > /sys/class/net/br0/bridge/multicast_router. Do I miss something here? Hi Vivien, I just checked this and it seems to work as expected: # echo 2 > /sys/class/net/br0/bridge/multicast_router We get a notification with mrouter=1 to mlxsw # echo 0 > /sys/class/net/br0/bridge/multicast_router We get a notification with mrouter=0 to mlxsw