Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759300AbbFBNli (ORCPT ); Tue, 2 Jun 2015 09:41:38 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:39632 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759110AbbFBNlb (ORCPT ); Tue, 2 Jun 2015 09:41:31 -0400 Message-ID: <556DB283.8080300@roeck-us.net> Date: Tue, 02 Jun 2015 06:41:23 -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: Scott Feldman CC: Vivien Didelot , Netdev , "David S. Miller" , Florian Fainelli , Andrew Lunn , Jiri Pirko , Jerome Oufella , "linux-kernel@vger.kernel.org" , kernel@savoirfairelinux.com, Chris Healy Subject: Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops References: <1433208470-25338-1-git-send-email-vivien.didelot@savoirfairelinux.com> <1433208470-25338-4-git-send-email-vivien.didelot@savoirfairelinux.com> <556D522E.90607@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: 2092 Lines: 45 On 06/02/2015 12:44 AM, Scott Feldman wrote: > On Mon, Jun 1, 2015 at 11:50 PM, Guenter Roeck wrote: > > [cut] > >> I brought this up before. No idea if my e-mail got lost or what happened. >> >> We use a fid per port, and a fid per bridge group. With VLANs, this is >> completely >> ignored, ahd there is only a single fid per vlan for the entire switch. >> >> Either per-port fids are unnecessary as well, or something is wrong here, >> or I am missing something. Can you explain why we only need a single fid >> per vlan, even if we have multiple bridge groups and the same vlan is >> configured in all of them ? > > That brings up an interesting point about having multiple bridges with > the same vlan configured. I struggled with that problem with rocker > also and I don't have an answer other than "don't do that". Or, > better put, if you have multiple bridge on the same vlan, just use one > bridge for that vlan. Otherwise, I don't know how at the device level > to partition the vlan between the bridges. Maybe that's what Vivien > is facing also? I can see how this works for software-only bridges, > because they should be isolated from each other and independent. But > when offloading to a device which sees VLAN XXX global across the > entire switch, I don't see how we can preserve the bridge boundaries. > One solution would be to use separate fids, like we do for non-vlan bridges. That makes fid management more complex, sure, but it would work. Otherwise we might have to explicitly disable support for more than one bridge group on a switch, which seems a bit artificial to me. Also, we already have cases where the switch is connected to the CPU with more than one Ethernet port. It is easy to imagine that the user of such a system might want to configure two bridge groups. 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/