linux-stable.git/tools/testing/selftests/drivers/net, branch v5.18.2

selftests: ocelot: tc_flower_chains: specify conform-exceed action for policer

2022-05-05T02:40:19+00:00

As discussed here with Ido Schimmel:
https://patchwork.kernel.org/project/netdevbpf/patch/20220224102908.5255-2-jianbol@nvidia.com/

the default conform-exceed action is "reclassify", for a reason we don't
really understand.

The point is that hardware can't offload that police action, so not
specifying "conform-exceed" was always wrong, even though the command
used to work in hardware (but not in software) until the kernel started
adding validation for it.

Fix the command used by the selftest by making the policer drop on
exceed, and pass the packet to the next action (goto) on conform.

Fixes: 8cd6b020b644 ("selftests: ocelot: add some example VCAP IS1, IS2 and ES0 tc offloads")
Signed-off-by: Vladimir Oltean 
Reviewed-by: Ido Schimmel 
Link: https://lore.kernel.org/r/20220503121428.842906-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski

selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets

2022-04-20T14:04:27+00:00

The test verifies that packets are correctly flooded by the bridge and
the VXLAN device by matching on the encapsulated packets at the other
end. However, if packets other than those generated by the test also
ingress the bridge (e.g., MLD packets), they will be flooded as well and
interfere with the expected count.

Make the test more robust by making sure that only the packets generated
by the test can ingress the bridge. Drop all the rest using tc filters
on the egress of 'br0' and 'h1'.

In the software data path, the problem can be solved by matching on the
inner destination MAC or dropping unwanted packets at the egress of the
VXLAN device, but this is not currently supported by mlxsw.

Fixes: d01724dd2a66 ("selftests: mlxsw: spectrum-2: Add a test for VxLAN flooding with IPv6")
Signed-off-by: Ido Schimmel 
Reviewed-by: Amit Cohen 
Signed-off-by: David S. Miller

selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets

2022-04-20T14:04:27+00:00

The test verifies that packets are correctly flooded by the bridge and
the VXLAN device by matching on the encapsulated packets at the other
end. However, if packets other than those generated by the test also
ingress the bridge (e.g., MLD packets), they will be flooded as well and
interfere with the expected count.

Make the test more robust by making sure that only the packets generated
by the test can ingress the bridge. Drop all the rest using tc filters
on the egress of 'br0' and 'h1'.

In the software data path, the problem can be solved by matching on the
inner destination MAC or dropping unwanted packets at the egress of the
VXLAN device, but this is not currently supported by mlxsw.

Fixes: 94d302deae25 ("selftests: mlxsw: Add a test for VxLAN flooding")
Signed-off-by: Ido Schimmel 
Reviewed-by: Amit Cohen 
Signed-off-by: David S. Miller

selftests: mlxsw: hw_stats_l3: Add a new test

2022-03-15T13:00:51+00:00

Add a test that verifies that UAPI notifications are emitted, as mlxsw
installs and deinstalls HW counters for the L3 offload xstats.

Signed-off-by: Petr Machata 
Signed-off-by: Paolo Abeni

selftests: netdevsim: hw_stats_l3: Add a new test

2022-03-15T13:00:51+00:00

Add a test that verifies basic UAPI contracts, netdevsim operation,
rollbacks after partial enablement in core, and UAPI notifications.

Signed-off-by: Petr Machata 
Signed-off-by: Paolo Abeni

selftests: mlxsw: resource_scale: Fix return value

2022-03-03T16:14:01+00:00

The test runs several test cases and is supposed to return an error in
case at least one of them failed.

Currently, the check of the return value of each test case is in the
wrong place, which can result in the wrong return value. For example:

 # TESTS='tc_police' ./resource_scale.sh
 TEST: 'tc_police' [default] 968                                     [FAIL]
         tc police offload count failed
 Error: mlxsw_spectrum: Failed to allocate policer index.
 We have an error talking to the kernel
 Command failed /tmp/tmp.i7Oc5HwmXY:969
 TEST: 'tc_police' [default] overflow 969                            [ OK ]
 ...
 TEST: 'tc_police' [ipv4_max] overflow 969                           [ OK ]

 $ echo $?
 0

Fix this by moving the check to be done after each test case.

Fixes: 059b18e21c63 ("selftests: mlxsw: Return correct error code in resource scale test")
Signed-off-by: Amit Cohen 
Reviewed-by: Petr Machata 
Signed-off-by: Ido Schimmel 
Signed-off-by: Jakub Kicinski

selftests: mlxsw: tc_police_scale: Make test more robust

2022-03-03T16:14:01+00:00

The test adds tc filters and checks how many of them were offloaded by
grepping for 'in_hw'.

iproute2 commit f4cd4f127047 ("tc: add skip_hw and skip_sw to control
action offload") added offload indication to tc actions, producing the
following output:

 $ tc filter show dev swp2 ingress
 ...
 filter protocol ipv6 pref 1000 flower chain 0 handle 0x7c0
   eth_type ipv6
   dst_ip 2001:db8:1::7bf
   skip_sw
   in_hw in_hw_count 1
         action order 1:  police 0x7c0 rate 10Mbit burst 100Kb mtu 2Kb action drop overhead 0b
         ref 1 bind 1
         not_in_hw
         used_hw_stats immediate

The current grep expression matches on both 'in_hw' and 'not_in_hw',
resulting in incorrect results.

Fix that by using JSON output instead.

Fixes: 5061e773264b ("selftests: mlxsw: Add scale test for tc-police")
Signed-off-by: Amit Cohen 
Reviewed-by: Petr Machata 
Signed-off-by: Ido Schimmel 
Signed-off-by: Jakub Kicinski

selftests: mlxsw: devlink_trap_tunnel_vxlan: Fix 'decap_error' case

2021-12-23T11:24:01+00:00

Change the case that sends packets with "too short inner packet" to
include part of ethernet header, to make the trap to be triggered due to
the correct reason.

According to ASIC arch, the trap is triggered if overlay packet length is
less than 18B, and the minimum inner packet should include source MAC and
destination MAC.

Till now the case passed because one of the reserved bits in VxLAN
header was used. This issue was found while adding an equivalent test
for IPv6.

Signed-off-by: Amit Cohen 
Reviewed-by: Petr Machata 
Signed-off-by: David S. Miller

selftests: mlxsw: Add test for VxLAN related traps for IPv6

2021-12-23T11:24:01+00:00

The test configures VxLAN with IPv6 underlay and verifies that the
expected traps are triggered under the right conditions.

The test is similar to the existing IPv4 test.

Signed-off-by: Amit Cohen 
Reviewed-by: Petr Machata 
Signed-off-by: David S. Miller

selftests: mlxsw: spectrum-2: Add a test for VxLAN flooding with IPv6

2021-12-23T11:24:01+00:00

The device stores flood records in a singly linked list where each
record stores up to X IP addresses of remote VTEPs.

The number of records is changed according to ASIC type and address
family.

Add a test which is similar to the existing IPv4 test to check IPv6.
The test is dedicated for Spectrum-2 and above, which support up to four
IPv6 addresses in one record.

The test verifies that packets are correctly flooded in various cases such
as deletion of a record in the middle of the list.

Signed-off-by: Amit Cohen 
Reviewed-by: Petr Machata 
Signed-off-by: David S. Miller