kernel/tools/testing/selftests/drivers/net/mlxsw/vxlan.sh, branch linux-rolling-stable

selftests: mlxsw: vxlan: Disable IPv6 autogen on bridges

2023-06-21T21:02:52Z

In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge (this holds for all bridges used here), the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks various aspects of VXLAN offloading and the bridges do not need to participate in routing traffic. The IP addresses or the RIFs are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in this selftest, thus exempting them from mlxsw router attention. Signed-off-by: Petr Machata Reviewed-by: Danielle Ratson Signed-off-by: Jakub Kicinski

selftests: mlxsw: vxlan: Make the test more flexible for future use

2021-12-23T11:24:00Z

vxlan.sh cases are dedicated to test VxLAN with IPv4 underlay. The main changes to test IPv6 underlay are IP addresses and some flags. Add variables to define all the values which supposed to be different for IPv6 testing, set them to use the existing values by default. The next patch will define the new added variables in a separated file, so the same tests can be used for IPv6 also. Rename some functions to include "ipv4", so the next patch will add equivalent functions for IPv6. Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Signed-off-by: David S. Miller

selftests: mlxsw: vxlan: Remove IPv6 test case

2021-12-15T15:05:44Z

Currently, there is a test case to verify that VxLAN with IPv6 underlay is forbidden. Remove this test case as support for VxLAN with IPv6 underlay was added by the previous patch. Signed-off-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

selftests: mlxsw: Use busywait helper in vxlan test

2020-02-27T19:10:14Z

Vxlan test uses offload indication checks. Use a busywait helper and wait until the offload indication is set or fail if it reaches timeout. Signed-off-by: Danielle Ratson Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

selftests: mlxsw: vxlan: Add test for error path

2020-02-17T22:42:53Z

Test that when two VXLAN tunnels with conflicting configurations (i.e., different TTL) are enslaved to the same VLAN-aware bridge, then the enslavement of a port to the bridge is denied. Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller

selftests: mlxsw: vxlan: Adjust test to recent changes

2020-02-17T22:42:53Z

After recent changes, the VXLAN tunnel will be offloaded regardless if any local ports are member in the FID or not. Adjust the test to make sure the tunnel is offloaded in this case. Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller

selftests: mlxsw: Remove deprecated test

2020-02-17T22:42:53Z

The addition of a VLAN on a bridge slave prompts the driver to have the local port in question join the FID corresponding to this VLAN. Before recent changes, the operation of joining the FID would also mean that the driver would enable VXLAN tunneling if a VXLAN device was also member in the VLAN. In case the configuration of the VXLAN tunnel was not supported, an extack error would be returned. Since the operation of joining the FID no longer means that VXLAN tunneling is potentially enabled, the test is no longer relevant. Remove it. Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller

selftests: mlxsw: Adjust test to recent changes

2019-11-15T20:14:38Z

mlxsw does not support VXLAN devices with a physical device attached and vetoes such configurations upon enslavement to an offloaded bridge. Commit 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") changed the VXLAN device to be an upper of the physical device which causes mlxsw to veto the creation of the VXLAN device with "Unknown upper device type". This is OK as this configuration is not supported, but it prevents us from testing bad flows involving the enslavement of VXLAN devices with a physical device to a bridge, regardless if the physical device is an mlxsw netdev or not. Adjust the test to use a dummy device as a physical device instead of a mlxsw netdev. Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller

selftests: mlxsw: Add a test case for VLAN addition error flow

2019-01-08T21:53:54Z

Add a test case for the issue fixed by previous commit. In case the offloading of an unsupported VxLAN tunnel was triggered by adding the mapped VLAN to a local port, then error should be returned to the user. Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Signed-off-by: David S. Miller

selftests: mlxsw: Add a test case for L3 VNI

2018-12-20T23:48:54Z

Previous patch added the ability to offload a VXLAN tunnel used for L3 VNI when it is present in the VLAN-aware bridge before the corresponding VLAN interface is configured. This patch adds a test case to verify that. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller