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

[Tobias Waldekranz <tobias@waldekranz.com>]

On Fri, Dec 10, 2021 at 00:41, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Thu, Dec 09, 2021 at 11:24:24PM +0100, Tobias Waldekranz wrote:
>> 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 :)