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

[Florian Fainelli <f.fainelli@gmail.com>]

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@waldekranz.com>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

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