Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755584AbbFCU4v (ORCPT ); Wed, 3 Jun 2015 16:56:51 -0400 Received: from vps0.lunn.ch ([178.209.37.122]:50822 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755202AbbFCU4o (ORCPT ); Wed, 3 Jun 2015 16:56:44 -0400 Date: Wed, 3 Jun 2015 22:51:12 +0200 From: Andrew Lunn To: Chris Healy Cc: Guenter Roeck , netdev@vger.kernel.org, Vivien Didelot , David , linux-kernel , =?iso-8859-1?Q?J=E9rome?= Oufella , kernel , Florian Fainelli , Scott Feldman , Jiri Pirko Subject: Re: [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses Message-ID: <20150603205112.GD22878@lunn.ch> References: <1433208470-25338-1-git-send-email-vivien.didelot@savoirfairelinux.com> <1433208470-25338-8-git-send-email-vivien.didelot@savoirfairelinux.com> <556DBCA4.10203@roeck-us.net> <1317462817.952931.1433293575321.JavaMail.zimbra@savoirfairelinux.com> <20150603022451.GB932@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2746 Lines: 60 On Tue, Jun 02, 2015 at 07:31:56PM -0700, Chris Healy wrote: > Guenter, > > That's a very valid concern. I have a configuration with a 6352 controlled > by a low end ARM core with a 100mbps connection on the CPU port. This > switch needs to support passing multicast streams that are more than > 100mbps on GigE links. (The ARM does not need to consume the multicast, it > just manages the switch.) Hi Chris Thinking out load here... There are two use cases: 1) Without bridging. The switch ports are seen as host interfaces. Host interfaces are expected to accept packets for there own MAC address and the broadcast address. Additional multicast addresses can be added and the ndo_set_rx_mode() method of the driver is called to get to hardware to accept these MAC addresses. DSA has an implementation of ndo_set_rx_mode(), but all it does is ask the kernel to do the filtering. We need to extend it to program the hardware to only pass frames which match the addresses on the lists. This should be just adding some static forwarding entries. Then, so long as an application on the host does not join any of the multicast groups, the frames should never be passed to the host. 2) With bridging, things are a bit different. Interfaces in a bridge are expected to be in promiscuous mode, receiving everything and passing it to the bridge. With the hardware bridging support Guenter added, we can off load unicast forwarding to the hardware. However, we currently don't have full support for off-loading of multicast. This falls into at a few different pieces: a) Get the hardware to do a dumb flood to all ports in the bridge group. However, the host is a member of the bridge, so it will still get a copy of all the packets. It has to, there could be members of the multicast groups on interfaces not accelerated by the hardware. b) Add limited IGMP snooping, so that the host bridge knows if it needs to see multicast frames for a specific MAC address from DSA interfaces or not, and program this into the hardware to reduce the load on the host. c) Add full IGMP snooping, so that the hardware no longer performs dumb flooding, but only forwards out ports where there has been an interest in the frames. Until we get at least b) implemented, i would expect all multicast packets to hit the host. In order to be correct in the general case, they have to. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/