• Vladimir Oltean's avatar
    selftests: forwarding: add a test for MAC Merge layer · e6991384
    Vladimir Oltean authored
    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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
    e6991384
ethtool_mm.sh 6.15 KB