From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756146AbbFCOoe (ORCPT ); Wed, 3 Jun 2015 10:44:34 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:40680 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755384AbbFCOoM (ORCPT ); Wed, 3 Jun 2015 10:44:12 -0400 Message-ID: <556F12B3.7050206@roeck-us.net> Date: Wed, 03 Jun 2015 07:44:03 -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 , nolan CC: Vivien Didelot , Netdev , "David S. Miller" , Florian Fainelli , Andrew Lunn , Jiri Pirko , Jerome Oufella , "linux-kernel@vger.kernel.org" , kernel , 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> <556E2EC2.3020104@cumulusnetworks.com> 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 On 06/02/2015 11:53 PM, Scott Feldman wrote: > On Tue, Jun 2, 2015 at 3:31 PM, nolan wrote: >> On 06/02/2015 12:44 AM, Scott Feldman wrote: >>> >>> 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. >> >> >> Scott, >> >> I'm confused by this. I think you're saying this config is problematic: >> >> br0: eth0.100, eth1.100 >> br1: eth2.100, eth3.100 >> >> >> But this works fine today. > > Ya, this is going to work because br0 and br1 are bridging untagged > traffic, but br0 and br1 have different internal VLAN ids for untagged > traffic, so there is no crosstalk between bridges. > > (I'm assuming since you used the ethX.100 format, you've vconfig > created a vlan interface on ethX and added the vlan interface to brY). > The vlan interface eats the vlan tag and the bridge sees untagged > traffic. > >> Could you clarify the issue you're referring to? > > I'm talking about bridging tagged traffic. E.g.: > > ip link add name br0 type bridge > ip link add name br1 type bridge > > ip link set dev sw1p1 master br0 > ip link set dev sw1p2 master br0 > ip link set dev sw1p3 master br1 > ip link set dev sw1p4 master br1 > > bridge vlan add vid 100 dev sw1p1 > bridge vlan add vid 100 dev sw1p2 > bridge vlan add vid 100 dev sw1p3 > bridge vlan add vid 100 dev sw1p4 > > Now the ports are trunking vlan 100 and the bridge/device see tagged > traffic. If the device used floods vlan 100 pkt to all ports in vlan > 100, it'll flood to a port outside the bridge. Oops! For the device > I'm using (rocker w/ OF-DPA) the bridging table matches on vlan ID and > mac_dst. There is no prevision to isolate vlans per bridge. > > How do you solve the above case with your hardware? > We could use separate FIDs per vlan/bridge group, ie don't assume that fid == vid. A simple solution might be to just set the fid to the fid used by the bridge. That would not support 802.1s, though. Guenter