Message-ID: <CAOiHx=kFhH-fB0b-nHPhEzgs1M_vBnzPZN48ZCzOs8iW7YTJzA@mail.gmail.com>
Date: Tue, 6 May 2025 16:27:32 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>, Andrew Lunn <andrew@...n.ch>, 
	"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 Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@...il.com> wrote:
>
> / unrelated to patches /
>
> On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
> > > > 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.
>
> I don't understand the logic, can you explain "you would have had the
> same issue again when using VLAN uppers"? The original issue, as you
> presented it, is with bridges with vlan_filtering=0, and does not exist
> with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
> not committed to hardware RX filters. And bridges with mixed
> vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
> So I don't see how making VID 4095 be the PVID of just standalone ports
> (leaving VLAN-unaware bridge ports with a different VID) would not be
> sufficient for the presented problem.

The issue isn't the vlan filtering, it's the (missing) FDB isolation
on the ASIC.

In general if a MAC is learned on one of the bridged ports, the ASIC
will try to forward any traffic ingressing for that MAC to the port
according to the internal FDB regardless if the source port is bridged
or not. The private VLAN masks used to isolate ports is only applied
*after* the forwarding lookup was done (this is how the hardware
works), and will then cause traffic to be dropped on standalone ports.

So for vlan_aware=0, the bridge learns on the FDB for VID 0, which is
also used for untagged traffic on stand alone ports, so the issue
happens.

For vlan_aware=1, untagged traffic is assigned to a VLAN != 0 on the
bridge, so the FDBs are different. Therefore no issue.

But once using VLAN uppers, the FDB will be the same again on the
bridged ports and tagged traffic on the standalone ports, so it
happens again. And this would be true regardless of vlan_aware or not.

Therefore using VID 4095 would only avoid the issue for vlan_aware=0
and untagged, but not the VLAN upper scenario.

Unfortunately there is no bit to disable FDB lookups for standalone
ports, only learning (at least I haven't found one).

> That being said, trapping to CPU all packets on standalone ports is not
> uncontroversial, as long as it works correctly for the hardware
> controlled by this driver. You seem concerned about losing RX filtering,
> but if you look at dsa_switch_supports_uc_filtering() and
> dsa_switch_supports_mc_filtering() you'll see b53 never had it - it
> depends, among other things, on ds->fdb_isolation == true and
> ds->vlan_filtering_is_global == false. Here you're working on improving
> the fdb_isolation requirements, but there is still no support in the
> core for devices where VLAN filtering is a global setting.

Aha, so I don't need to care about this, since fdb_isolation is not
supported and filtering is always global. Good to know.

I'm mostly concerned if using the security feature for that has any
side effects I'm not aware of (e.g. dropping of some traffic), or if
it would prevent using it for its intended use, i.e. locked ports and
MAB. I don't trust it yet, feels a bit too easy of a solution ;-).
Will need to double/triple check (and read the docs).

Also it's not supported by all b53 supported ASICs, so maybe there is
a solution that works for all (but most probably there is not).

Best regards,
Jonas

Powered by blists - more mailing lists