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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 16 Dec 2018 19:36:43 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Ido Schimmel <idosch@...lanox.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "andrew@...n.ch" <andrew@...n.ch>, Jiri Pirko <jiri@...lanox.com>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
        "roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
        "bridge@...ts.linux-foundation.org" 
        <bridge@...ts.linux-foundation.org>,
        "cphealy@...il.com" <cphealy@...il.com>
Subject: Re: [PATCH net-next] Documentation: networking: Clarify switchdev devices behavior



On December 16, 2018 12:25:19 AM PST, Ido Schimmel <idosch@...lanox.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