From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH RFC] net: dsa: Make switches VLAN aware when enslaved into a bridge Date: Fri, 26 Oct 2018 16:16:06 -0700 Message-ID: <27f6afc1-403d-9f11-554e-8ad5b998d0fb@gmail.com> References: <20181024193657.24012-1-f.fainelli@gmail.com> <20181026151019.GA15354@splinter.mtl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "netdev@vger.kernel.org" , Jiri Pirko , Petr Machata , "privat@egil-hjelmeland.no" , "Woojung.Huh@microchip.com" , "tristram.ha@microchip.com" , Andrew Lunn , Vivien Didelot , "David S. Miller" , open list To: Ido Schimmel Return-path: In-Reply-To: <20181026151019.GA15354@splinter.mtl.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 10/26/18 8:10 AM, Ido Schimmel wrote: > On Wed, Oct 24, 2018 at 12:36:57PM -0700, Florian Fainelli wrote: >> Commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is >> disabled") changed the behavior of DSA switches when the switch ports >> are enslaved into the bridge and only pushed the VLAN configuration down >> to the switch if the bridge is configured with VLAN filtering enabled. > > This is what mlxsw is doing. > >> This is unfortunately wrong, because what vlan_filtering configures is a >> policy on the acceptance of VLAN tagged frames with an unknown VID. >> >> vlan_filtering=0 means a frame with a VLAN tag that is not part of the >> VLAN table should be allowed to ingress the switch, and vlan_fltering=1 >> would reject that frame. > > While you correctly describe the logic, this is not how VLAN-unaware > bridges are actually used. The expectation is that packets will be > untagged when entering the bridge. Either because they are truly > untagged or because they were untagged by a VLAN netdev. > > For a long time we rejected the enslavement of physical ports to > VLAN-unaware bridges and only allowed VLAN netdevs to be enslaved. In > order to support the logic you described, we would need to map all 4K > VLANs on each port to 4K different FIDs. In addition, each FDB entry > would need to be programmed 4K times, each time with a different FID. > This is because FDB lookup is performed using {MAC, FID} and not only > MAC. I can go into more details about why we cannot map different VLANs > on a port to the same FID, but I do not think it is pertinent to our > discussion. > > Eventually, users started complaining about this constraint and we > relaxed it in commit 65b53bfd497b ("mlxsw: spectrum_switchdev: Allow > port enslavement to a VLAN-unaware bridge"). Thanks for providing more context, I suppose we will keep the current logic then, if nothing else it aligns us with mlxsw. -- Florian