[Bridge] [PATCH net-next] Documentation: networking: Clarify switchdev devices behavior

Florian Fainelli f.fainelli at gmail.com
Mon Dec 17 03:36:43 UTC 2018



On December 16, 2018 12:25:19 AM PST, Ido Schimmel <idosch at mellanox.com> wrote:
>On Wed, Dec 12, 2018 at 03:09:43PM -0800, Florian Fainelli wrote:

>
>mlxsw doesn't support it. These bridges are mainly used with VLAN
>devices where the packets ingress the bridge untagged. When configured
>over physical ports, we only allow untagged packets into such a bridge.

There is another complication with at least some of the DSA switches, turning 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 requesting VLAN filtering to be on. Not necessarily a problem in a larger switch fabric comprised of multiple switches (the D in DSA) since they could conceptually have multiple switches each with different VLAN filtering rules but that complicates the matter significantly.

The more I think about supporting toggling VLAN filtering at runtime the less it seems to have a good return on investment:

- the bridge layer does not remove VLAN entries created while the bridge was 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...slow.

- no reasonable use case comes to mind which would not involved knowing whether a bridge should be VLAN aware ahead of time.

I am therefore convinced that adopting the mlxsw behavior wrt. VLAN filtering toggling is a good approach. Thanks!
-- 
Florian


More information about the Bridge mailing list