netdev - Re: [PATCH v4 net-next 14/15] net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT

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, 18 Jul 2021 19:52:38 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Ido Schimmel <idosch@...sch.org>,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <nikolay@...dia.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        bridge@...ts.linux-foundation.org,
        Grygorii Strashko <grygorii.strashko@...com>,
        Marek Behun <kabel@...ckhole.sk>,
        DENG Qingfang <dqfext@...il.com>
Subject: Re: [PATCH v4 net-next 14/15] net: dsa: mv88e6xxx: map virtual
 bridges with forwarding offload in the PVT



On 7/18/2021 2:44 PM, Vladimir Oltean wrote:
> The mv88e6xxx switches have the ability to receive FORWARD (data plane)
> frames from the CPU port and route them according to the FDB. We can use
> this to offload the forwarding process of packets sent by the software
> bridge.
> 
> Because DSA supports bridge domain isolation between user ports, just
> sending FORWARD frames is not enough, as they might leak the intended
> broadcast domain of the bridge on behalf of which the packets are sent.
> 
> It should be noted that FORWARD frames are also (and typically) used to
> forward data plane packets on DSA links in cross-chip topologies. The
> FORWARD frame header contains the source port and switch ID, and
> switches receiving this frame header forward the packet according to
> their cross-chip port-based VLAN table (PVT).
> 
> To address the bridging domain isolation in the context of offloading
> the forwarding on TX, the idea is that we can reuse the parts of the PVT
> that don't have any physical switch mapped to them, one entry for each
> software bridge. The switches will therefore think that behind their
> upstream port lie many switches, all in fact backed up by software
> bridges through tag_dsa.c, which constructs FORWARD packets with the
> right switch ID corresponding to each bridge.
> 
> The mapping we use is absolutely trivial: DSA gives us a unique bridge
> number, and we add the number of the physical switches in the DSA switch
> tree to that, to obtain a unique virtual bridge device number to use in
> the PVT.
> 
> Co-developed-by: Tobias Waldekranz <tobias@...dekranz.com>
> Signed-off-by: Tobias Waldekranz <tobias@...dekranz.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian