From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic Date: Thu, 09 Nov 2017 11:30:32 +0900 (KST) Message-ID: <20171109.113032.692635294382924138.davem@davemloft.net> References: <1510010818-23223-1-git-send-email-andrew@lunn.ch> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com To: andrew@lunn.ch Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:55038 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbdKICaj (ORCPT ); Wed, 8 Nov 2017 21:30:39 -0500 In-Reply-To: <1510010818-23223-1-git-send-email-andrew@lunn.ch> Sender: netdev-owner@vger.kernel.org List-ID: From: Andrew Lunn Date: Tue, 7 Nov 2017 00:26:53 +0100 > The linux bridge supports IGMP snooping. It will listen to IGMP > reports on bridge ports and keep track of which groups have been > joined on an interface. It will then forward multicast based on this > group membership. > > When the bridge adds or removed groups from an interface, it uses > switchdev to request the hardware add an mdb to a port, so the > hardware can perform the selective forwarding between ports. > > What is not covered by the current bridge code, is IGMP joins/leaves > from the host on the brX interface. These are not reported via > switchdev so that hardware knows the local host is interested in the > multicast frames. > > Luckily, the bridge does track joins/leaves on the brX interface. The > code is obfusticated, which is why i missed it with my first attempt. > So the first patch tries to remove this obfustication. Currently, > there is no notifications sent when the bridge interface joins a > group. The second patch adds them. bridge monitor then shows > joins/leaves in the same way as for other ports of the bridge. > > Then starts the work passing down to the hardware that the host has > joined/left a group. The existing switchdev mdb object cannot be used, > since the semantics are different. The existing > SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast > group should be forwarded out that port of the switch. However here we > require the exact opposite. We want multicast frames for the group > received on the port to the forwarded to the host. Hence add a new > object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to > forward to the host. This new object is then propagated through the > DSA layers. No DSA driver changes should be needed, this should just > work... Series applied, with the spurious whitespace change removed from patch #5. Thanks!