Re: [PATCH net 2/2] selftests: net: bridge_vlan_aware: test untagged/8021p-tagged with and without PVID

[Ido Schimmel <idosch@nvidia.com>]

On Fri, Apr 25, 2025 at 01:37:34AM +0300, Vladimir Oltean wrote:
> Recent discussions around commit ad1afb003939 ("vlan_dev: VLAN 0 should
> be treated as "no vlan tag" (802.1p packet)") have sparked the question
> what happens with the DSA (and possibly other switchdev) data path when
> the bridge says that ports should have no PVID VLAN, but the 8021q
> module, as the result of a NETDEV_UP event, decides it should add VID 0
> to the RX filter of those bridge ports. Do those bridge ports receive
> packets tagged with VID 0 or not, now? We don't know, there is no test.
> 
> In the veth realm, this passes trivially, because veth is not VLAN
> filtering and this, the 8021q module lacks the instinct to add VID 0 in
> the first place.
> 
> In the realm of VLAN filtering NICs with no switchdev offload, this
> should also pass, because the VLAN groups of the software bridge are
> consulted, where it can clearly be seen that a PVID is missing, even
> though the packet was initially accepted by the NIC.
> 
> The test only poses a challenge for switchdev drivers, which usually
> have to program to hardware both VLANs from RX filtering, as well as
> from switchdev. Especially when a switchdev port joins a VLAN-aware
> bridge, it is unavoidable that it gains the NETIF_F_HW_VLAN_CTAG_FILTER
> feature, i.e. any 8021q uppers that the bridge port may have must also
> be committed to the RX filtering table of the interface. When a
> VLAN-tagged packet is physically received by the port, it is initially
> indistinguishable whether it will reach the bridge data path or the
> 8021q upper data path.
> 
> That is rather the final step of the new tests that we introduce.
> We need to build context up to that stage, which means the following:
> 
> - we need to test that 802.1p (VID 0) tagged traffic is received in the
>   first place (on bridge ports with a valid PVID). This is the "8021p"
>   test.
> 
> - we need to test that the usual paths of reaching a configuration with
>   no PVID on a bridge port are all covered and they all reach the same
>   state.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>