Re: [PATCH net-next] net: dsa: mv88e6xxx: Add tx fwd offload PVT on intermediate devices

On Fri, Dec 10, 2021 at 00:41, Vladimir Oltean [off-list ref] wrote:

On Thu, Dec 09, 2021 at 11:24:24PM +0100, Tobias Waldekranz wrote:

quoted

In a typical mv88e6xxx switch tree like this:

  CPU
   |    .----.
.--0--. | .--0--.
| sw0 | | | sw1 |
'-1-2-' | '-1-2-'
    '---'

If sw1p{1,2} are added to a bridge that sw0p1 is not a part of, sw0
still needs to add a crosschip PVT entry for the virtual DSA device
assigned to represent the bridge.

Fixes: ce5df6894a57 ("net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT")
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---

This makes sense. Sorry, my Turris MOX has 3 cascaded switches but I
only test it using a single bridge that spans all of the ports.
So this is why in my case the DSA and CPU ports could receive packets
using the virtual bridge device, because mv88e6xxx_port_vlan() had been
called on them through the direct mv88e6xxx_port_bridge_join(), not
through mv88e6xxx_crosschip_bridge_join().

Yeah this is by far the most common setup, that's why I missed it as
well.

I guess you have a use case
where some leaf ports are in a bridge but some upstream ports aren't,
and this is how you caught this?

I've been doing some work on running kselftest-like tests on a multichip
mv88e6xxx system. In that process, I discovered this issue along with a
whole slew of other nasty things related to isolation of standalone
ports.

I am finalizing a series to tackle that which (while not exactly
elegant) should get the job done. Stay tuned :)