Message-ID: <CAOiHx=n_f9CXZf_x1Rd36Fm5ELFd03a9vbLe+wUqWajfaSY5jg@mail.gmail.com>
Date: Wed, 30 Apr 2025 10:43:40 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Russell King <linux@...linux.org.uk>, Kurt Kanzenbach <kurt@...utronix.de>, 
	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

On Wed, Apr 30, 2025 at 10:07 AM Florian Fainelli
<florian.fainelli@...adcom.com> wrote:
>
>
>
> On 4/29/2025 10:16 PM, Jonas Gorski wrote:
> > This patchset aims at fixing most issues observed while running the
> > vlan_unaware_bridge, vlan_aware_bridge and local_termination selftests.
> >
> > Most tests succeed with these patches on BCM53115, connected to a
> > BCM6368.
> >
> > It took me a while to figure out that a lot of tests will fail if all
> > ports have the same MAC address, as the switches drop any frames with
> > DA == SA. Luckily BCM63XX boards often have enough MACs allocated for
> > all ports, so I just needed to assign them.
> >
> > The still failing tests are:
> >
> > FDB learning, both vlan aware aware and unaware:
> >
> > This is expected, as b53 currently does not implement changing the
> > ageing time, and both the bridge code and DSA ignore that, so the
> > learned entries don't age out as expected.
> >
> > ping and ping6 in vlan unaware:
> >
> > These fail because of the now fixed learning, the switch trying to
> > forward packet ingressing on one of the standalone ports to the learned
> > port of the mac address when the packets ingressed on the bridged port.
>
> Sorry not quite getting that part, can you expand a bit more?

The ping test uses four network ports, where two pairs are linked via
a network cable. So the setup is

sw1p1 <- cable -> sw1p2 <- bridge -> sw1p3 <- cable ->sw1p4

And it tries to ping from sw1p1 to sw1p4.

In the vlan_aware test, the bridge uses VLAN 1 pvid untagged, so it
learns in VLAN 1, while the standalone ports use VLAN 0. Different
FIDs, so no issue.

In the vlan_unaware test, untagged traffic uses VLAN 0 everywhere, so
the following happens:

- switch learns swp1p's MAC at sw1p2
- switch learns sw1p4's MAC at sw1p3

when sw1p1 sends a unicast to sw1p4' mac it egresses on swp1p3 and
then ingresses on sw1p4 again. The switch see's sw1p2's MAC as DA and
then ARL lookup says "sw1p3", but the port VLAN mask disallows sending
from sw1p4 to sw1p3, so it gets dropped.

Without learning, all packets are flooded, so connectivity works, as
the standalone ports are always part of the flood masks.

> > The port VLAN masks only prevent forwarding to other ports, but the ARL
> > lookup will still happen, and the packet gets dropped because the port
> > isn't allowed to forward there.
>
> OK.
>
> >
> > I have a fix/workaround for that, but as it is a bit more controversial
> > and makes use of an unrelated feature, I decided to hold off from that
> > and post it later.
>
> Can you expand on the fix/workaround you have?

It's setting EAP mode to simplified on standalone ports, where it
redirects all frames to the CPU port where there is no matching ARL
entry for that SA and port. That should work on everything semi recent
(including BCM63XX), and should work regardless of VLAN. It might
cause more traffic than expected to be sent to the switch, as I'm not
sure if multicast filtering would still work (not that I'm sure that
it currently works lol).

At first I moved standalone ports to VID 4095 for untagged traffic,
but that only fixed the issue for untagged traffic, and you would have
had the same issue again when using VLAN uppers. And VLAN uppers have
the same issue on vlan aware bridges, so the above would be a more
complete workaround.

> > This wasn't noticed so far, because learning was never working in VLAN
> > unaware mode, so the traffic was always broadcast (which sidesteps the
> > issue).
> >
> > Finally some of the multicast tests from local_termination fail, where
> > the reception worked except it shouldn't. This doesn't seem to me as a
> > super serious issue, so I didn't attempt to debug/fix these yet.
> >
> > I'm not super confident I didn't break sf2 along the way, but I did
> > compile test and tried to find ways it cause issues (I failed to find
> > any). I hope Florian will tell me.
>
> I am currently out of the office but intend to test your patch series at
> some point in the next few days. Let's gather some review feedback in
> the meantime, thanks for submitting those fixes!

If you are awake at this hour I guess your are back "home" ;-)

Sure thing, take your time! All I wanted to implement is MST support,
but then I noticed some things not working as expected, and then I
became aware of the selftests, and then I suddenly had accumulated a
lot of fixes trying to make everything say "Okay" (and sometimes
wondering why other stuff broke when I fixed things, like the learning
in unaware mode).

Best regards,
Jonas

Powered by blists - more mailing lists