From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH net-next] Documentation: networking: Clarify switchdev devices behavior Date: Sun, 16 Dec 2018 19:36:43 -0800 Message-ID: References: <20181212230943.757-1-f.fainelli@gmail.com> <20181216082517.GA31098@splinter> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "andrew@lunn.ch" , "nikolay@cumulusnetworks.com" , "netdev@vger.kernel.org" , "roopa@cumulusnetworks.com" , "bridge@lists.linux-foundation.org" , "vivien.didelot@gmail.com" , Jiri Pirko , "davem@davemloft.net" To: Ido Schimmel Return-path: In-Reply-To: <20181216082517.GA31098@splinter> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bridge-bounces@lists.linux-foundation.org Errors-To: bridge-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org On December 16, 2018 12:25:19 AM PST, Ido Schimmel = wrote: >On Wed, Dec 12, 2018 at 03:09:43PM -0800, Florian Fainelli wrote: > >mlxsw doesn't support it=2E These bridges are mainly used with VLAN >devices where the packets ingress the bridge untagged=2E When configured >over physical ports, we only allow untagged packets into such a bridge=2E There is another complication with at least some of the DSA switches, turn= ing off VLAN filtering is a global operation, so we must deny it if we have= another bridge device that spans the same switch device which is also requ= esting VLAN filtering to be on=2E Not necessarily a problem in a larger swi= tch fabric comprised of multiple switches (the D in DSA) since they could c= onceptually have multiple switches each with different VLAN filtering rules= but that complicates the matter significantly=2E The more I think about supporting toggling VLAN filtering at runtime the l= ess it seems to have a good return on investment: - the bridge layer does not remove VLAN entries created while the bridge w= as VLAN aware, thus complicating the on to off state, since we need to make= the switch port a member of all VLANs, untagged, some older switches don't= have a "join all VLAN" shorthand for that so that means programming up to = 4K VLAN entries=2E=2E=2Eslow=2E - no reasonable use case comes to mind which would not involved knowing wh= ether a bridge should be VLAN aware ahead of time=2E I am therefore convinced that adopting the mlxsw behavior wrt=2E VLAN filt= ering toggling is a good approach=2E Thanks! --=20 Florian