diff options
author | Vladimir Oltean <vladimir.oltean@nxp.com> | 2025-04-25 01:37:34 +0300 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2025-04-26 04:45:43 +0300 |
commit | bf9de1dcd0eecd16020a677c900a70ea9b0a9714 (patch) | |
tree | 8cd770e38fdfa8371bfff05714f9a162cfe5adf6 /lib/mpi/mpi-pow.c | |
parent | 5ec6d7d737a491256cd37e33910f7ac1978db591 (diff) | |
download | linux-bf9de1dcd0eecd16020a677c900a70ea9b0a9714.tar.xz |
selftests: net: bridge_vlan_aware: test untagged/8021p-tagged with and without PVID
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>
Link: https://patch.msgid.link/20250424223734.3096202-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'lib/mpi/mpi-pow.c')
0 files changed, 0 insertions, 0 deletions