OSDN Git Service

selftests: forwarding: add a test for MAC Merge layer
authorVladimir Oltean <vladimir.oltean@nxp.com>
Tue, 18 Apr 2023 11:14:59 +0000 (14:14 +0300)
committerJakub Kicinski <kuba@kernel.org>
Fri, 21 Apr 2023 03:03:21 +0000 (20:03 -0700)
commite6991384ace5c9cbbe453ad1d8998b0cdaf222f5
tree70034f71232d99372a574dd4b64c3c3987613269
parentb5bf7126a6a0e706ef0e6c6cd22b2ebc23bf54a2
selftests: forwarding: add a test for MAC Merge layer

The MAC Merge layer (IEEE 802.3-2018 clause 99) does all the heavy
lifting for Frame Preemption (IEEE 802.1Q-2018 clause 6.7.2), a TSN
feature for minimizing latency.

Preemptible traffic is different on the wire from normal traffic in
incompatible ways. If we send a preemptible packet and the link partner
doesn't support preemption, it will drop it as an error frame and we
will never know. The MAC Merge layer has a control plane of its own,
which can be manipulated (using ethtool) in order to negotiate this
capability with the link partner (through LLDP).

Actually the TLV format for LLDP solves this problem only partly,
because both partners only advertise:
- if they support preemption (RX and TX)
- if they have enabled preemption (TX)
so we cannot tell the link partner what to do - we cannot force it to
enable reception of our preemptible packets.

That is fully solved by the verification feature, where the local device
generates some small probe frames which look like preemptible frames
with no useful content, and the link partner is obliged to respond to
them if it supports the standard. If the verification times out, we know
that preemption isn't active in our TX direction on the link.

Having clarified the definition, this selftest exercises the manual
(ethtool) configuration path of 2 link partners (with and without
verification), and the LLDP code path, using the openlldp project.

The test also verifies the TX activity of the MAC Merge layer by
sending traffic through a traffic class configured as preemptible
(using mqprio). There isn't a good way to make this really portable
(user space cannot find out how many traffic classes there are for
a device), but I chose num_tc 4 here, that should work reasonably well.
I also know that some devices (stmmac) only permit TXQ0 to be
preemptible, so this is why PREEMPTIBLE_PRIO was strategically chosen
as 0. Even if other hardware is more configurable, this test should
cover the baseline.

This is not really a "forwarding" selftest, but I put it near the other
"ethtool" selftests.

$ ./ethtool_mm.sh eno0 swp0
TEST: Manual configuration with verification: eno0 to swp0          [ OK ]
TEST: Manual configuration with verification: swp0 to eno0          [ OK ]
TEST: Manual configuration without verification: eno0 to swp0       [ OK ]
TEST: Manual configuration without verification: swp0 to eno0       [ OK ]
TEST: Manual configuration with failed verification: eno0 to swp0   [ OK ]
TEST: Manual configuration with failed verification: swp0 to eno0   [ OK ]
TEST: LLDP                                                          [ OK ]

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tools/testing/selftests/net/forwarding/Makefile
tools/testing/selftests/net/forwarding/ethtool_mm.sh [new file with mode: 0755]
tools/testing/selftests/net/forwarding/lib.sh