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

[PATCH net-next v1 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:
-- 
2.55.0.571.g244d577d93-goog

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

[Mina Almasry]

In testing environments, binding to the port can transiently fail
following a driver reset caused by the preceding queue configuration.
The failing bind() is typically caused by DHCP/IPv6 DAD needing some
time to resolve and assign the IP address back to the interface after
the reset. Retry bind() multiple times before fully failing the test
to improve robustness.

Signed-off-by: Mina Almasry <almasrymina@google.com>
---
 tools/testing/selftests/drivers/net/hw/ncdevmem.c | 7 ++++++-
 1 file changed, 6 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..6724f81e389fa 100644
--- a/tools/testing/selftests/drivers/net/hw/ncdevmem.c
+++ b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
@@ -898,7 +898,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));
+	int retries = 10;
+	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 v1 2/2] selftests: drv-net: ncdevmem: gracefully retry bind()

[T.J. Mercier]

On Sat, Aug 1, 2026 at 6:12 AM Mina Almasry <almasrymina@google.com> wrote:
>
Hi

> In testing environments, binding to the port can transiently fail
> following a driver reset caused by the preceding queue configuration.
> The failing bind() is typically caused by DHCP/IPv6 DAD needing some
> time to resolve and assign the IP address back to the interface after
> the reset.

With EADDRNOTAVAIL? Maybe loop only for that errno?

> Retry bind() multiple times before fully failing the test
> to improve robustness.
>
> Signed-off-by: Mina Almasry <almasrymina@google.com>
> ---
>  tools/testing/selftests/drivers/net/hw/ncdevmem.c | 7 ++++++-
>  1 file changed, 6 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..6724f81e389fa 100644
> --- a/tools/testing/selftests/drivers/net/hw/ncdevmem.c
> +++ b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
> @@ -898,7 +898,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));
> +       int retries = 10;
> +       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 v1 2/2] selftests: drv-net: ncdevmem: gracefully retry bind()

[Mina Almasry]

On Tue, Aug 4, 2026 at 12:21 PM T.J. Mercier <tjmercier@google.com> wrote:
> > In testing environments, binding to the port can transiently fail
> > following a driver reset caused by the preceding queue configuration.
> > The failing bind() is typically caused by DHCP/IPv6 DAD needing some
> > time to resolve and assign the IP address back to the interface after
> > the reset.
>
> With EADDRNOTAVAIL? Maybe loop only for that errno?
>

I did not check the actual error code returned. I could.

But is it worth maintaining an exact list of error codes to retry on
for this test code? It will be annoying for the next guy to discover
another error code that legitimately requires waiting, and then we'd
have to maintain a list of error codes to retry on. It would be worth
going through the trouble for actual kernel code, but it feels like
more trouble than it's worth for a test?

-- 
Thanks,
Mina

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

[T.J. Mercier]

On Wed, Aug 5, 2026 at 10:36 AM Mina Almasry <almasrymina@google.com> wrote:
>
> On Tue, Aug 4, 2026 at 12:21 PM T.J. Mercier <tjmercier@google.com> wrote:
> > > In testing environments, binding to the port can transiently fail
> > > following a driver reset caused by the preceding queue configuration.
> > > The failing bind() is typically caused by DHCP/IPv6 DAD needing some
> > > time to resolve and assign the IP address back to the interface after
> > > the reset.
> >
> > With EADDRNOTAVAIL? Maybe loop only for that errno?
> >
>
> I did not check the actual error code returned. I could.
>
> But is it worth maintaining an exact list of error codes to retry on
> for this test code? It will be annoying for the next guy to discover
> another error code that legitimately requires waiting, and then we'd
> have to maintain a list of error codes to retry on. It would be worth
> going through the trouble for actual kernel code, but it feels like
> more trouble than it's worth for a test?

My thinking is it's also annoying to have to wait 10s for an error
condition that cannot be recovered from. I don't feel strongly.