[PATCH net-next v2 1/2] selftests: drv-net: devmem: fix 5-tuple flow steering

[PATCH net-next v2 1/2] selftests: drv-net: devmem: fix 5-tuple flow steering

[Mina Almasry]

When configuring traffic for the devmem tests, 5-tuple flow steering may
be required if the environment does not provide network namespaces.
Pass the correct remote address parameter and fall back to 5-tuple flow
steering if netns is not available.

Signed-off-by: Mina Almasry <almasrymina@google.com>
---
 tools/testing/selftests/drivers/net/hw/devmem_lib.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/drivers/net/hw/devmem_lib.py b/tools/testing/selftests/drivers/net/hw/devmem_lib.py
index 0921ff03eb81c..3ede6fd426929 100644
--- a/tools/testing/selftests/drivers/net/hw/devmem_lib.py
+++ b/tools/testing/selftests/drivers/net/hw/devmem_lib.py
@@ -111,7 +111,7 @@ def ncdevmem_tx(cfg, port, chunk_size=0):
     else:
         ifname = cfg.ifname
         addr = cfg.remote_addr
-        extras = []
+        extras = [f"-c {cfg.addr}"]
 
     if chunk_size:
         extras.append(f"-z {chunk_size}")
@@ -212,7 +212,7 @@ def run_rx_hds(cfg):
         port = rand_port()
 
         listen_cmd = ncdevmem_rx(cfg, port, verify=False,
-                                 fail_on_linear=True)
+                                 fail_on_linear=True, flow_steer=not hasattr(cfg, 'netns'))
         socat = socat_send(cfg, port, buf_size=size)
 
         with bkg(listen_cmd, exit_wait=True, ns=netns) as ncdevmem:

base-commit: 69963a0678a347d57c4ac8b16939dba216eb95ce
-- 
2.55.0.571.g244d577d93-goog

[PATCH net-next v2 2/2] selftests: drv-net: ncdevmem: gracefully retry bind()

[Mina Almasry]

During tests, ethnl_rings_set randomly bounces the link causing a
transient IPv6 Duplicate Address Detection "tentative" race, resulting
in spurious -EADDRNOTAVAIL aborts inside the ncdevmem server.

Add a simple 10 second retry loop around bind() to absorb the link bounce.

Signed-off-by: Mina Almasry <almasrymina@google.com>
---
v2:
- Refactored C99 mid-scope variables to strictly adhere to C89 styling.
- Dropped single-line curly brace avoidance syntax.
v1: https://patchwork.kernel.org/project/netdevbpf/patch/20260801131220.1367229-2-almasrymina@google.com/
---
 tools/testing/selftests/drivers/net/hw/ncdevmem.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/drivers/net/hw/ncdevmem.c b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
index ffe1d5c1fa4e1..67901a0123e8c 100644
--- a/tools/testing/selftests/drivers/net/hw/ncdevmem.c
+++ b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
@@ -843,6 +843,7 @@ static int do_server(struct memory_buffer *mem)
 	char iobuf[819200];
 	int ret, err = -1;
 	char buffer[256];
+	int retries = 10;
 	int socket_fd;
 	int client_fd;
 
@@ -898,7 +899,12 @@ static int do_server(struct memory_buffer *mem)
 	fprintf(stderr, "binding to address %s:%d\n", server_ip,
 		ntohs(server_sin.sin6_port));
 
-	ret = bind(socket_fd, &server_sin, sizeof(server_sin));
+	while (retries--) {
+		ret = bind(socket_fd, &server_sin, sizeof(server_sin));
+		if (!ret)
+			break;
+		sleep(1);
+	}
 	if (ret) {
 		pr_err("Failed to bind");
 		goto err_close_socket;
-- 
2.55.0.571.g244d577d93-goog

Re: [PATCH net-next v2 2/2] selftests: drv-net: ncdevmem: gracefully retry bind()

[Jakub Kicinski]

On Mon,  3 Aug 2026 18:18:26 +0000 Mina Almasry wrote:
> During tests, ethnl_rings_set randomly bounces the link causing a
> transient IPv6 Duplicate Address Detection "tentative" race, resulting
> in spurious -EADDRNOTAVAIL aborts inside the ncdevmem server.

The test env is supposed to disable DAD and addr flush on down.
If DAD is enabled multiple ksft tests would fail.

Re: [PATCH net-next v2 2/2] selftests: drv-net: ncdevmem: gracefully retry bind()

[Mina Almasry]

On Thu, Aug 6, 2026 at 12:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon,  3 Aug 2026 18:18:26 +0000 Mina Almasry wrote:
> > During tests, ethnl_rings_set randomly bounces the link causing a
> > transient IPv6 Duplicate Address Detection "tentative" race, resulting
> > in spurious -EADDRNOTAVAIL aborts inside the ncdevmem server.
>
> The test env is supposed to disable DAD and addr flush on down.
> If DAD is enabled multiple ksft tests would fail.

Ack, let me check how to do this in my test env.

-- 
Thanks,
Mina

Re: [PATCH net-next v2 1/2] selftests: drv-net: devmem: fix 5-tuple flow steering

[Jakub Kicinski]

On Mon,  3 Aug 2026 18:18:25 +0000 Mina Almasry wrote:
> When configuring traffic for the devmem tests, 5-tuple flow steering may
> be required if the environment does not provide network namespaces.
> Pass the correct remote address parameter and fall back to 5-tuple flow
> steering if netns is not available.

Could you clarify what existing upstream test / scenario needs this?

Re: [PATCH net-next v2 1/2] selftests: drv-net: devmem: fix 5-tuple flow steering

[Mina Almasry]

On Thu, Aug 6, 2026 at 12:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon,  3 Aug 2026 18:18:25 +0000 Mina Almasry wrote:
> > When configuring traffic for the devmem tests, 5-tuple flow steering may
> > be required if the environment does not provide network namespaces.
> > Pass the correct remote address parameter and fall back to 5-tuple flow
> > steering if netns is not available.
>
> Could you clarify what existing upstream test / scenario needs this?

This is needed to give the check_rx_hds test a chance to pass on
5-tuple flow steering driver, like GVE. Without this change:

    # Exception| Traceback (most recent call last):
    # Exception|   File
"/usr/src/kernel/tools/testing/selftests/drivers/net/hw/devmem_lib.py",
line 219, in run_rx_hds
    # Exception|     wait_port_listen(port, proto="tcp", ns=netns)
    ...
    # Exception| net.lib.py.utils.CmdExitFailure: Command failed
    # Exception| CMD:
/usr/src/kernel/tools/testing/selftests/drivers/net/hw/ncdevmem -l -f
eth1 -s 192.168.1.84 -p 46391 -L
    # Exception|   EXIT: 1
    # Exception|   STDERR: using ifindex=3
    # Exception|           using queues 15..16
    # Exception|           TCP header split: on
    # Exception|           Running: ethtool -X eth1 equal 15 >&2
    # Exception|           Running: ethtool -N eth1 flow-type tcp4
dst-ip 192.168.1.84   dst-port 46391 queue 15
    # Exception|           rmgr: Cannot insert RX class rule: Invalid argument
    # Exception|           Cannot insert classification rule
    # Exception|           Running: ethtool -N eth1 flow-type tcp4
dst-ip 192.168.1.84 dst-port 46391 queue 15
    # Exception|           rmgr: Cannot insert RX class rule: Invalid
argument
    # Exception|           Cannot insert classification rule
    # Exception|           ncdevmem: Failed to configure flow steering
    # Exception|           Running: ethtool -X eth1 default >&2
    # Exception|
    not ok 4 devmem.check_rx_hds

With this change:

    ok 1 devmem.check_rx
    ok 2 devmem.check_tx
    ok 3 devmem.check_tx_chunks
    # Exception| Traceback (most recent call last):
    # Exception|   File
"/usr/src/kernel/tools/testing/selftests/net/lib/py/ksft.py", line
420, in ksft_run
    # Exception|     func(*args)
    # Exception|   File
"/usr/src/kernel/tools/testing/selftests/drivers/net/hw/devmem.py",
line 30, in check_rx_hds
    # Exception|     run_rx_hds(cfg)
    # Exception|   File
"/usr/src/kernel/tools/testing/selftests/drivers/net/hw/devmem_lib.py",
line 219, in run_rx_hds
    # Exception|     wait_port_listen(port, proto="tcp", ns=netns)
    # Exception|   File
"/usr/src/kernel/tools/testing/selftests/net/lib/py/utils.py", line
356, in wait_port_listen
    # Exception|     raise Exception("Waiting for port listen timed out")
    # Exception| Exception: Waiting for port listen timed out
    # Exception|
    not ok 4 devmem.check_rx_hds

Yes the test fails, but it gets past the flow steering configuration problem.

And in the code, the change looks correct to me. If flow_steer is
False, then we don't pass the -c arg to ncdevmem. ncdevmem is written
so that if -c is not set, 5-tuple flow steering is not possible (the
client side port is random), so it falls back to 3-tuple flow
steering, which doesn't work on GVE or any other driver that supports
only 5-tuple flow steering.

run_rx (devmem.check_rx test case) doesn't have this problem because
it does `flow_steer=not hasattr(cfg, 'netns')`, but run_rx_hds has
this problem because it forgets to override flow_steer at all. This
patch fixes that.

To be honest while looking at this there were a few weird things. Like
I'm not sure why the python arg is named `flow_steer` (it likely
should be 5_tuple_flow_steer), and why flow_steer setting is tied to
hasattr(cfg, 'netns'), it should be a proprety of the driver you're
runing on (unless all in-netns drivers will support 3-tuple flow
steering).

I am planning to debug the remaining failure running check_rx_hds on
GVE and following up with another patch for that.

-- 
Thanks,
Mina

Re: [PATCH net-next v2 1/2] selftests: drv-net: devmem: fix 5-tuple flow steering

[Jakub Kicinski]

On Thu, 6 Aug 2026 13:05:49 -0700 Mina Almasry wrote:
> Yes the test fails, but it gets past the flow steering configuration problem.
> 
> And in the code, the change looks correct to me. If flow_steer is
> False, then we don't pass the -c arg to ncdevmem. ncdevmem is written
> so that if -c is not set, 5-tuple flow steering is not possible (the
> client side port is random), so it falls back to 3-tuple flow
> steering, which doesn't work on GVE or any other driver that supports
> only 5-tuple flow steering.
> 
> run_rx (devmem.check_rx test case) doesn't have this problem because
> it does `flow_steer=not hasattr(cfg, 'netns')`, but run_rx_hds has
> this problem because it forgets to override flow_steer at all. This
> patch fixes that.
> 
> To be honest while looking at this there were a few weird things. Like
> I'm not sure why the python arg is named `flow_steer` (it likely
> should be 5_tuple_flow_steer), and why flow_steer setting is tied to
> hasattr(cfg, 'netns'), it should be a proprety of the driver you're
> runing on (unless all in-netns drivers will support 3-tuple flow
> steering).

Could we clean this up and add explicit test cases for inserting
specific rule types? We want the one-sided-tuple format at Meta,
falling back silently would be a loss of signal.

Re: [PATCH net-next v2 1/2] selftests: drv-net: devmem: fix 5-tuple flow steering

[Mina Almasry]

On Thu, Aug 6, 2026 at 1:34 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 6 Aug 2026 13:05:49 -0700 Mina Almasry wrote:
> > Yes the test fails, but it gets past the flow steering configuration problem.
> >
> > And in the code, the change looks correct to me. If flow_steer is
> > False, then we don't pass the -c arg to ncdevmem. ncdevmem is written
> > so that if -c is not set, 5-tuple flow steering is not possible (the
> > client side port is random), so it falls back to 3-tuple flow
> > steering, which doesn't work on GVE or any other driver that supports
> > only 5-tuple flow steering.
> >
> > run_rx (devmem.check_rx test case) doesn't have this problem because
> > it does `flow_steer=not hasattr(cfg, 'netns')`, but run_rx_hds has
> > this problem because it forgets to override flow_steer at all. This
> > patch fixes that.
> >
> > To be honest while looking at this there were a few weird things. Like
> > I'm not sure why the python arg is named `flow_steer` (it likely
> > should be 5_tuple_flow_steer), and why flow_steer setting is tied to
> > hasattr(cfg, 'netns'), it should be a proprety of the driver you're
> > runing on (unless all in-netns drivers will support 3-tuple flow
> > steering).
>
> Could we clean this up and add explicit test cases for inserting
> specific rule types? We want the one-sided-tuple format at Meta,
> falling back silently would be a loss of signal.

Do you mean forking all the test cases so that we have
check_rx_3_tuple and check_rx_5_tuple, etc? Won't that be annoying in
the future if every test case needs to be duplicated twice? And
potentially again if there is another deviation in driver config
support specifics?

The current approach is that yes we have 1 set of test cases, and
they're supposed to auto-detect if 3-tuple or 5-tuple is supported and
fallback silently to what the driver supports. check_rx and check_tx
currently work this way. I occasionally find breakages on 5-tuple
setups because they're less common and fix them, like this one[1].

To be clear this change is not intended to break 3-tuple. It's just
porting the bit that makes check_rx work for check_rx_hds. Whoever
added run_rx_hds probably did not have access to a 5-tuple-only driver
and missed this needed change.

[1] https://lore.kernel.org/netdev/aDXbNuCPNKRYYVRk@mini-arch/

-- 
Thanks,
Mina