Message-ID: <20250428092712.7owj62ct2dj5t2r4@skbuf>
Date: Mon, 28 Apr 2025 12:27:12 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Jonas Gorski <jonas.gorski@...il.com>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
	Florian Fainelli <f.fainelli@...il.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>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: dsa: fix VLAN 0 filter imbalance when toggling
 filtering

On Sat, Apr 26, 2025 at 05:44:33PM +0200, Jonas Gorski wrote:
> On Fri, Apr 25, 2025 at 1:42 PM Vladimir Oltean <vladimir.oltean@....com> wrote:
> > We have insufficient coverage in dsa_user_prechangeupper_sanity_check()
> > and dsa_port_can_apply_vlan_filtering(), but we should add another
> > restriction for this: 8021q uppers with the same VID should not be
> > installed to ports spanning the same VLAN-aware bridge. And there should
> > be a new test for it in tools/testing/selftests/net/forwarding/no_forwarding.sh.
> >
> > The restriction can be selectively lifted if there ever appear drivers
> > which can make the distinction you are talking about, but I don't think
> > that any of them can, at the moment.
> 
> AFAICT, we probably then also need to deny any vlan uppers on ports
> bridged via vlan unaware bridges for now, as we currently don't
> actually configure them at all.

So it seems.

> switchdev.rst says "Frames ingressing the device with a VID that is
> not programmed into the bridge/switch's VLAN table must be forwarded
> and may be processed using a VLAN device (see below)" (I thought with
> a vlan unaware bridge we do not program the VLAN table? anway ...)

I think the sentence just intended to clarify what it means for the port
to be non-filtering, but in the process introduced the ambiguity of
whether VLANs should be committed to hardware tables or not.

To be clear, from the bridge perspective, VLAN filtering = VLAN awareness
(there doesn't exist any option to, say, have per-VLAN learning but not
filtering). I suppose that if the hardware supports mechanisms of being
VLAN-aware but not filtering, and still do VLAN-unaware learning, those
mechanisms can be used as long as the bridging layer expectations are met.

> "- with VLAN filtering turned off, the bridge will process all ingress traffic
>   for the port, except for the traffic tagged with a VLAN ID destined for a
>   VLAN upper."
> 
> This is currently not happening when creating a vlan upper, at least I
> don't see any port_vlan_add() (?) calls for that. And even then, it
> would be indistinguishable from the port_vlan_add() calls that happen
> if you add a vlan to the bridge's vlan table, which you can, and DSA
> passes on, but should not be acted upon by the switch until vlan
> filtering is turned on.
> 
> Also in general vlan unaware bridges feel like they have a lot of
> complicated and probably unsupportable setups.
> 
> Like for example:
> 
> br0 { sw1p1, sw1p2, sw1p3, sw1p4 }
> br1 { sw1p1.10, sw1p4.10 }
> 
> would AFAIU mean:
> 
> - forward all traffic except vlan 10 tagged between all 4 ports
> - vlan 10 tagged traffic from sw1p1 can only go to sw1p4
> - vlan 10 tagged traffic from sw1p4 can only go to sw1p1
> - vlan 10 tagged traffic from sw1p2 and sw1p3 can go to all other ports
> 
> I'm not confident that I could program that correctly on a Broadcom
> XGS switch, and these support a *lot* of VLAN shenanigans.

You can add restrictions for these cases for 'net', as I don't think any
current DSA driver handles this correctly. Then, if you want to take a
stab at offloading these configurations, feel free to do so in net-next.

> This probably leaves:
> 
> "    * Treat bridge ports with VLAN upper interfaces as standalone, and let
>       forwarding be handled in the software data path."
> 
> as the only viable option here

Keep in mind that we haven't experimented with dynamically unoffloading
a bridge port before (calling switchdev_bridge_port_unoffload() at
runtime). That will be necessary when toggling the bridge vlan_filtering
option. It should work, but I can't guarantee that it does. In general,
software bridging was retrofitted onto DSA drivers which also support
bridge offload, and not all of them may work correctly (they may still
have address learning enabled, things like that). I'd only consider that
path as suitable for net-next.

> (I have to admit I don't really understand what the first option is
> suggesting to do).

The first option suggests that you can implement a VLAN-unaware bridge
by mapping the entire 4K VLAN space to a single VLAN within the hardware
switch. It has to be configured specially at the driver level, to always
preserve the VLAN tag (and ID) when egressing the packet. Then exempt
certain VLAN IDs (of 8021q uppers) from this treatment, and include only
the user port and CPU port in their forwarding mask.

The above can also be reinterpreted in the key that packets with a VLAN
ID that isn't in the VLAN database aren't "filtered" but forwarded as-is,
and learned all together. It seems to be similar with your own
suggestion above.

It's just an idea, and requires hardware support to achieve that. This
circles back to the idea that the port can be configured as VLAN "aware"
as long as it's not "filtering" from the bridge perspective, and there
is no address space segregation per VLAN in the FDB. The bridge doesn't
need to be aware of this custom mode of operation, the driver may decide
to transition to it only in the presence of 8021q uppers on top of
VLAN-unaware bridge ports.

Powered by blists - more mailing lists