linux-dev/tools/testing/selftests/drivers/net/mlxsw, branch master

selftests: mlxsw: Remove qos_burst test

2022-09-20T01:08:00Z

The previous patch added a test which can be used instead of qos_burst.sh. Remove this test. Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Add QOS test for maximum use of descriptors

2022-09-20T01:07:59Z

Add an equivalent test to qos_burst, the test's purpose is same, but the new test uses simpler topology and does not require forcing low speed. In addition, it can be run Spectrum-2 and not only Spectrum-3+. The idea is to use a shaper in order to limit the traffic and create congestion. qos_burst test uses small pool, sends many small packets, and verify that packets are not dropped, which means that many descriptors can be handled. This test should check the change that commit c864769add96 ("mlxsw: Configure descriptor buffers") pushed. Instead, the new test tries to use more than 85% of maximum supported descriptors. The idea is to use big pool (as much as the ASIC supports), such that the pool size does not limit the traffic, then send many small packets, which means that many descriptors are used, and check how many packets the switch can handle. The usage of shaper allows to run the test in all ASICs, regardless of the CPU abilities, as it is able to create the congestion with low rate of packets. Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Use shapers in QOS RED tests instead of forcing speed

2022-09-20T01:07:59Z

QOS tests create congestion and verify the switch behavior. To create congestion, they need to have more traffic than the port can handle, so some of them force 1Gbps speed. The tests assume that 1Gbps speed is supported, otherwise, they will fail. Spectrum-4 ASIC will not support this speed in all ports, so to be able to run the tests there, some adjustments are required. Use shapers to limit the traffic instead of forcing speed. Note that for several ports, the speed configuration is just for autoneg issues, so shaper is not needed instead. The tests already use ETS qdisc as a root and RED qdiscs as children. Add a new TBF shaper to limit the rate of traffic, and use it as a root qdisc, then save the previous hierarchy of qdiscs under the new TBF root. In some ASICs, the shapers do not limit the traffic as accurately as forcing speed. To make the tests stable, allow the backlog size to be up to +-10% of the threshold. The aim of the tests is to make sure that with backlog << threshold, there are no drops, and that packets are dropped somewhere in vicinity of the configured threshold. Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Use shapers in QOS tests instead of forcing speed

2022-09-20T01:07:59Z

selftests: mlxsw: Add egress VID classification test

2022-08-19T03:50:41Z

After routing, the device always consults a table that determines the packet's egress VID based on {egress RIF, egress local port}. In the unified bridge model, it is up to software to maintain this table via REIV register. The table needs to be updated in the following flows: 1. When a RIF is set on a FID, for each FID's {Port, VID} mapping, a new {RIF, Port}->VID mapping should be created. 2. When a {Port, VID} is mapped to a FID and the FID already has a RIF, a new {RIF, Port}->VID mapping should be created. Add a test to verify that packets get the correct VID after routing, regardless of the order of the configuration. # ./egress_vid_classification.sh TEST: Add RIF for existing {port, VID}->FID mapping [ OK ] TEST: Add {port, VID}->FID mapping for FID with a RIF [ OK ] Signed-off-by: Amit Cohen Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Add ingress RIF configuration test for VXLAN

2022-08-19T03:50:40Z

Before layer 2 forwarding, the device classifies an incoming packet to a FID. After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block. For VXLAN decapsulation, the FID classification is done according to the VNI. When a RIF is added on top of a FID, the existing VNI->FID mapping should be updated by the software with the new RIF. In addition, when a new mapping is added for FID which already has a RIF, the correct RIF should be used for it. Add a test to verify that packets can be routed after decapsulation which is done after VNI->FID classification, regardless of the order of the configuration. # ./ingress_rif_conf_vxlan.sh TEST: Add RIF for existing VNI->FID mapping [ OK ] TEST: Add VNI->FID mapping for FID with a RIF [ OK ] Signed-off-by: Amit Cohen Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Add ingress RIF configuration test for 802.1Q bridge

2022-08-19T03:50:40Z

Before layer 2 forwarding, the device classifies an incoming packet to a FID. After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block. For VLAN-aware bridges (802.1Q), the FID classification is done according to VID. When a RIF is added on top of a FID, the existing VID->FID mapping should be updated by the software with the new RIF. We never map multiple VLANs to the same FID using VID->FID, so we cannot create VID->FID for FID which already has a RIF using 802.1Q. Anyway, verify that packets can be routed via port which is added after the FID already has a RIF. Add a test to verify that packets can be routed after VID->FID classification, regardless of the order of the configuration. # ./ingress_rif_conf_1q.sh TEST: Add RIF for existing VID->FID mapping [ OK ] TEST: Add port to VID->FID mapping for FID with a RIF [ OK ] Signed-off-by: Amit Cohen Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Add ingress RIF configuration test for 802.1D bridge

2022-08-19T03:50:39Z

Before layer 2 forwarding, the device classifies an incoming packet to a FID. After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block. For VLAN-unaware bridges (802.1D), the FID classification is done according to {Port, VID}. When a RIF is added on top of a FID, all the existing {Port, VID}->FID mappings should be updated by the software with the new RIF. In addition, when a new mapping is added for FID which already has a RIF, the correct RIF should be used for it. Add a test to verify that packets can be routed after {Port, VID}->FID classification, regardless of the order of the configuration. # ./ingress_rif_conf_1d.sh TEST: Add RIF for existing {port, VID}->FID mapping [ OK ] TEST: Add {port, VID}->FID mapping for FID with a RIF [ OK ] Signed-off-by: Amit Cohen Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

selftests: mlxsw: Check line card info on activated line card

2022-07-26T20:56:44Z

Once line card is activated, check the FW version and PSID are exposed. Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski

selftests: mlxsw: Check line card info on provisioned line card

2022-07-26T20:56:44Z

Once line card is provisioned, check if HW revision and INI version are exposed on associated nested auxiliary device. Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski