linux.git/tools/testing/selftests/net/Makefile, branch v5.15

selftests: add simple GSO GRE test

2021-09-02T10:33:28+00:00

Test case for commit a6e3f2985a80 ("ip6_tunnel: fix GRE6 segmentation").

Signed-off-by: Jakub Kicinski 
Signed-off-by: David S. Miller

selftests/net: allow GRO coalesce test on veth

2021-08-26T11:03:49+00:00

This change extends the existing GRO coalesce test to
allow running on top of a veth pair, so that no H/W dep
is required to run them.

By default gro.sh will use the veth backend, and will try
to use exiting H/W in loopback mode if a specific device
name is provided with the '-i' command line option.

No functional change is intended for the loopback-based
tests, just move all the relevant initialization/cleanup
code into the related script.

Introduces a new initialization helper script for the
veth backend, and plugs the correct helper script according
to the provided command line.

Additionally, enable veth-based tests by default.

v1 -> v2:
  - drop unused code in setup_veth_ns() - Willem

Signed-off-by: Paolo Abeni 
Signed-off-by: David S. Miller

selftests/net: toeplitz test

2021-08-05T12:14:09+00:00

To verify that this hash implements the Toeplitz hash function.

Additionally, provide a script toeplitz.sh to run the test in loopback mode
on a networking device of choice (see setup_loopback.sh). Since the
script modifies the NIC setup, it will not be run by selftests
automatically.

Tested:
./toeplitz.sh -i eth0 -irq_prefix  -t -6
carrier ready
rxq 0: cpu 14
rxq 1: cpu 20
rxq 2: cpu 17
rxq 3: cpu 23
cpu 14: rx_hash 0x69103ebc [saddr fda8::2 daddr fda8::1 sport 58938 dport 8000] OK rxq 0 (cpu 14)
...
cpu 20: rx_hash 0x257118b9 [saddr fda8::2 daddr fda8::1 sport 59258 dport 8000] OK rxq 1 (cpu 20)
count: pass=111 nohash=0 fail=0
Test Succeeded!

Signed-off-by: Coco Li 
Reviewed-by: Willem de Bruijn 
Signed-off-by: David S. Miller

selftests/net: GRO coalesce test

2021-08-05T12:14:09+00:00

Implement a GRO testsuite that expects Linux kernel GRO behavior.
All tests pass with the kernel software GRO stack. Run against a device
with hardware GRO to verify that it matches the software stack.

gro.c generates packets and sends them out through a packet socket. The
receiver in gro.c (run separately) receives the packets on a packet
socket, filters them by destination ports using BPF and checks the
packet geometry to see whether GRO was applied.

gro.sh provides a wrapper to run the gro.c in NIC loopback mode.
It is not included in continuous testing because it modifies network
configuration around a physical NIC: gro.sh sets the NIC in loopback
mode, creates macvlan devices on the physical device in separate
namespaces, and sends traffic generated by gro.c between the two
namespaces to observe coalescing behavior.

GRO coalescing is time sensitive.
Some tests may prove flaky on some hardware.

Note that this test suite tests for software GRO unless hardware GRO is
enabled (ethtool -K $DEV rx-gro-hw on).

To test, run ./gro.sh.
The wrapper will output success or failed test names, and generate
log.txt and stderr.

Sample log.txt result:
...
pure data packet of same size: Test succeeded

large data packets followed by a smaller one: Test succeeded

small data packets followed by a larger one: Test succeeded
...

Sample stderr result:
...
carrier ready
running test ipv4 data
Expected {200 }, Total 1 packets
Received {200 }, Total 1 packets.
...

Signed-off-by: Coco Li 
Reviewed-by: Willem de Bruijn 
Signed-off-by: David S. Miller

selftests: net: Test for the IOAM insertion with IPv6

2021-07-21T15:16:11+00:00

This test evaluates the IOAM insertion for IPv6 by checking the IOAM data
integrity on the receiver.

The topology is formed by 3 nodes: Alpha (sender), Beta (router in-between)
and Gamma (receiver). An IOAM domain is configured from Alpha to Gamma only,
which means not on the reverse path. When Gamma is the destination, Alpha
adds an IOAM option (Pre-allocated Trace) inside a Hop-by-hop and fills the
trace with its own IOAM data. Beta and Gamma also fill the trace. The IOAM
data integrity is checked on Gamma, by comparing with the pre-defined IOAM
configuration (see below).

    +-------------------+            +-------------------+
    |                   |            |                   |
    |    alpha netns    |            |    gamma netns    |
    |                   |            |                   |
    |  +-------------+  |            |  +-------------+  |
    |  |    veth0    |  |            |  |    veth0    |  |
    |  |  db01::2/64 |  |            |  |  db02::2/64 |  |
    |  +-------------+  |            |  +-------------+  |
    |         .         |            |         .         |
    +-------------------+            +-------------------+
              .                                .
              .                                .
              .                                .
    +----------------------------------------------------+
    |         .                                .         |
    |  +-------------+                  +-------------+  |
    |  |    veth0    |                  |    veth1    |  |
    |  |  db01::1/64 | ................ |  db02::1/64 |  |
    |  +-------------+                  +-------------+  |
    |                                                    |
    |                      beta netns                    |
    |                                                    |
    +--------------------------+-------------------------+

~~~~~~~~~~~~~~~~~~~~~~
| IOAM configuration |
~~~~~~~~~~~~~~~~~~~~~~

Alpha
+-----------------------------------------------------------+
| Type                | Value                               |
+-----------------------------------------------------------+
| Node ID             | 1                                   |
+-----------------------------------------------------------+
| Node Wide ID        | 11111111                            |
+-----------------------------------------------------------+
| Ingress ID          | 0xffff (default value)              |
+-----------------------------------------------------------+
| Ingress Wide ID     | 0xffffffff (default value)          |
+-----------------------------------------------------------+
| Egress ID           | 101                                 |
+-----------------------------------------------------------+
| Egress Wide ID      | 101101                              |
+-----------------------------------------------------------+
| Namespace Data      | 0xdeadbee0                          |
+-----------------------------------------------------------+
| Namespace Wide Data | 0xcafec0caf00dc0de                  |
+-----------------------------------------------------------+
| Schema ID           | 777                                 |
+-----------------------------------------------------------+
| Schema Data         | something that will be 4n-aligned   |
+-----------------------------------------------------------+

Note: When Gamma is the destination, Alpha adds an IOAM Pre-allocated Trace
      option inside a Hop-by-hop, where 164 bytes are pre-allocated for the
      trace, with 123 as the IOAM-Namespace and with 0xfff00200 as the trace
      type (= all available options at this time). As a result, and based on
      IOAM configurations here, only both Alpha and Beta should be capable of
      inserting their IOAM data while Gamma won't have enough space and will
      set the overflow bit.

Beta
+-----------------------------------------------------------+
| Type                | Value                               |
+-----------------------------------------------------------+
| Node ID             | 2                                   |
+-----------------------------------------------------------+
| Node Wide ID        | 22222222                            |
+-----------------------------------------------------------+
| Ingress ID          | 201                                 |
+-----------------------------------------------------------+
| Ingress Wide ID     | 201201                              |
+-----------------------------------------------------------+
| Egress ID           | 202                                 |
+-----------------------------------------------------------+
| Egress Wide ID      | 202202                              |
+-----------------------------------------------------------+
| Namespace Data      | 0xdeadbee1                          |
+-----------------------------------------------------------+
| Namespace Wide Data | 0xcafec0caf11dc0de                  |
+-----------------------------------------------------------+
| Schema ID           | 0xffffff (= None)                   |
+-----------------------------------------------------------+
| Schema Data         |                                     |
+-----------------------------------------------------------+

Gamma
+-----------------------------------------------------------+
| Type                | Value                               |
+-----------------------------------------------------------+
| Node ID             | 3                                   |
+-----------------------------------------------------------+
| Node Wide ID        | 33333333                            |
+-----------------------------------------------------------+
| Ingress ID          | 301                                 |
+-----------------------------------------------------------+
| Ingress Wide ID     | 301301                              |
+-----------------------------------------------------------+
| Egress ID           | 0xffff (default value)              |
+-----------------------------------------------------------+
| Egress Wide ID      | 0xffffffff (default value)          |
+-----------------------------------------------------------+
| Namespace Data      | 0xdeadbee2                          |
+-----------------------------------------------------------+
| Namespace Wide Data | 0xcafec0caf22dc0de                  |
+-----------------------------------------------------------+
| Schema ID           | 0xffffff (= None)                   |
+-----------------------------------------------------------+
| Schema Data         |                                     |
+-----------------------------------------------------------+

Signed-off-by: Justin Iurman 
Signed-off-by: David S. Miller

tools/testing: add a selftest for SO_NETNS_COOKIE

2021-06-24T18:13:05+00:00

Make sure that SO_NETNS_COOKIE returns a non-zero value, and
that sockets from different namespaces have a distinct cookie
value.

Signed-off-by: Lorenz Bauer 
Signed-off-by: David S. Miller

selftests/net: bump timeout to 5 minutes

2021-04-23T21:08:58+00:00

We found that with the latest mainline kernel (5.12.0-051200rc8) on
some KVM instances / bare-metal systems, the following tests will take
longer than the kselftest framework default timeout (45 seconds) to
run and thus got terminated with TIMEOUT error:
* xfrm_policy.sh - took about 2m20s
* pmtu.sh - took about 3m5s
* udpgso_bench.sh - took about 60s

Bump the timeout setting to 5 minutes to allow them have a chance to
finish.

https://bugs.launchpad.net/bugs/1856010
Signed-off-by: Po-Hsu Lin 
Signed-off-by: David S. Miller

self-tests: add veth tests

2021-04-11T23:39:28+00:00

Add some basic veth tests, that verify the expected flags and
aggregation with different setups (default, xdp, etc...)

Signed-off-by: Paolo Abeni 
Signed-off-by: David S. Miller

selftests: net: add UDP GRO forwarding self-tests

2021-03-31T00:06:50+00:00

Create a bunch of virtual topologies and verify that
NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD-enabled
devices aggregate the ingress packets as expected.
Additionally check that the aggregate packets are
segmented correctly when landing on a socket

Also test SKB_GSO_FRAGLIST and SKB_GSO_UDP_L4 aggregation
on top of UDP tunnel (vxlan)

v1 -> v2:
 - hopefully clarify the commit message
 - moved the overlay network ipv6 range into the 'documentation'
   reserved range (Willem)

Signed-off-by: Paolo Abeni 
Acked-by: Willem de Bruijn 
Signed-off-by: David S. Miller

selftests: add IPv4 unicast extensions tests

2021-01-27T01:52:16+00:00

Add selftests for kernel behavior with regard to various classes of
unallocated/reserved IPv4 addresses, checking whether or not these
addresses can be assigned as unicast addresses on links and used in
routing.

Expect the current kernel behavior at the time of this patch. That is:

* 0/8 and 240/4 may be used as unicast, with the exceptions of 0.0.0.0
  and 255.255.255.255;
* the lowest address in a subnet may only be used as a broadcast address;
* 127/8 may not be used as unicast (the route_localnet option, which is
  disabled by default, still leaves it treated slightly specially);
* 224/4 may not be used as unicast.

Signed-off-by: Seth David Schoen 
Suggested-by: John Gilmore 
Acked-by: Dave Taht 
Reviewed-by: David Ahern 
Link: https://lore.kernel.org/r/20210126040834.GR24989@frotz.zork.net
Signed-off-by: Jakub Kicinski