Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752079AbbFCERi (ORCPT ); Wed, 3 Jun 2015 00:17:38 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:53370 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750754AbbFCER3 (ORCPT ); Wed, 3 Jun 2015 00:17:29 -0400 Message-ID: <556E7FD4.3040200@roeck-us.net> Date: Tue, 02 Jun 2015 21:17:24 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Chris Healy CC: netdev@vger.kernel.org, Vivien Didelot , David , linux-kernel , =?UTF-8?B?SsOpcm9tZSBPdWZlbGxh?= , kernel , Florian Fainelli , Scott Feldman , Jiri Pirko , Andrew Lunn Subject: Re: [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2461 Lines: 55 On 06/02/2015 07:31 PM, 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.) > Possibly, but Vivien didn't answer my question (how the local SA address finds its way into the switch fdb). I'll check it myself. Thanks, Guenter > On Jun 3, 2015 3:24 AM, "Guenter Roeck" > wrote: > > On Tue, Jun 02, 2015 at 09:06:15PM -0400, Vivien Didelot wrote: > > Hi Guenter, > > > > On Jun 2, 2015, at 10:24 AM, Guenter Roeck linux@roeck-us.net wrote: > > On 06/01/2015 06:27 PM, Vivien Didelot wrote: > > >> This commit disables SA learning and refreshing for the CPU port. > > >> > > > > > > Hi Vivien, > > > > > > This patch also seems to be unrelated to the rest of the series. > > > > > > Can you add an explanation why it is needed ? > > > > > > With this in place, how does the CPU port SA find its way into the fdb ? > > > Do we assume that it will be configured statically ? > > > An explanation might be useful. > > > > Without this patch, I noticed the CPU port was stealing the SA of a PC > > behind a switch port. this happened when the port was a bridge member, > > as the bridge was relaying broadcast coming from one switch port to the > > other switch ports in the same vlan. > > > Makes me feel really uncomfortable. I think we may be going into the wrong > direction. The whole point of offloading bridging is to have the switch handle > forwarding, and that includes multicasts and broadcasts. Instead of doing that, > it looks like we put more and more workarounds in place. > > Maybe the software bridge code needs to understand that it isn't support to > forward broadcasts to ports of an offloaded bridge, and we should let the > switch chip handle it ? > > Thanks, > Guenter > -- 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/