[PATCH net-next v2 0/2] selftests: drv-net: so_txtime: trivial fixes

[PATCH net-next v2 0/2] selftests: drv-net: so_txtime: trivial fixes

[Jakub Kicinski]

I noticed that so_txtime is only passing on NIPA setups which are
looped within a single host. The cross-machine cases just flat out
fail. The initial bug is obvious - the test does not deploy the binary.
But even with that I think more work would be needed to sync the
time / adjust the expectations for a dual-machine test.

Willem promised to follow up on the fundamental issues with 2-host
setups :)

v2:
 - rebase & add cfg.require_ipver(ipver) to the new case
v1: https://lore.kernel.org/20260608173305.372987-1-kuba@kernel.org

Jakub Kicinski (2):
  selftests: drv-net: so_txtime: remember to deploy the binaries
  selftests: drv-net: so_txtime: check IP versions

 tools/testing/selftests/drivers/net/so_txtime.py | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

-- 
2.54.0

[PATCH net-next v2 1/2] selftests: drv-net: so_txtime: remember to deploy the binaries

[Jakub Kicinski]

The test seems to be written with a single-host loopback
in mind. We need to deploy the binary to remote before
we run it. This is just fixing an obvious issue, but
more work will be needed to make the dual-host setup
work reliably. Most of the runs still fail with:

  FAIL: start time already passed

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/testing/selftests/drivers/net/so_txtime.py | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/drivers/net/so_txtime.py b/tools/testing/selftests/drivers/net/so_txtime.py
index b7be4cabbec2..abdd2371cc1a 100755
--- a/tools/testing/selftests/drivers/net/so_txtime.py
+++ b/tools/testing/selftests/drivers/net/so_txtime.py
@@ -18,14 +18,16 @@ from lib.py import NetDrvEpEnv, bkg, cmd, defer, tc
     """Main function. Run so_txtime as sender and receiver."""
     slow_machine = os.environ.get('KSFT_MACHINE_SLOW')
 
-    bin_path = cfg.test_dir / "so_txtime"
+    if not hasattr(cfg, "bin_remote"):
+        cfg.bin_local = cfg.test_dir / "so_txtime"
+        cfg.bin_remote = cfg.remote.deploy(cfg.bin_local)
 
     tstart = time.time_ns() + (2000_000_000 if slow_machine else 200_000_000)
 
     cmd_addr = f"-S {cfg.addr_v[ipver]} -D {cfg.remote_addr_v[ipver]}"
-    cmd_base = f"{bin_path} -{ipver} -c {clockid} -t {tstart} {cmd_addr}"
-    cmd_rx = f"{cmd_base} {args_rx} -r"
-    cmd_tx = f"{cmd_base} {args_tx}"
+    cmd_args = f"-{ipver} -c {clockid} -t {tstart} {cmd_addr}"
+    cmd_rx = f"{cfg.bin_remote} {cmd_args} {args_rx} -r"
+    cmd_tx = f"{cfg.bin_local} {cmd_args} {args_tx}"
 
     expect_fail = not expect_success
     if slow_machine:
-- 
2.54.0

[PATCH net-next v2 2/2] selftests: drv-net: so_txtime: check IP versions

[Jakub Kicinski]

This test needs more work, and it fails in non-obvious way
when IPv4 connectivity is not available:

  # Exception| CMD[remote]: /tmp/vjquwblf/gukinuzqso_txtime -4 -c mono -t 1780939014114542914 -S None -D None a,0 -r
  # Exception|   EXIT: -15

Explicitly check for IPv4 support to make the future triage
less painful.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
v2:
 - add cfg.require_ipver(ipver) in test_so_txtime_fq_tai()
v1: https://lore.kernel.org/20260608173305.372987-3-kuba@kernel.org
---
 tools/testing/selftests/drivers/net/so_txtime.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/drivers/net/so_txtime.py b/tools/testing/selftests/drivers/net/so_txtime.py
index abdd2371cc1a..adf6c848d6d8 100755
--- a/tools/testing/selftests/drivers/net/so_txtime.py
+++ b/tools/testing/selftests/drivers/net/so_txtime.py
@@ -64,6 +64,7 @@ from lib.py import NetDrvEpEnv, bkg, cmd, defer, tc
 @ksft_variants(_test_variants_fq())
 def test_so_txtime_fq_mono(cfg, ipver, args_tx, args_rx):
     """Run all variants of monotonic (fq) tests."""
+    cfg.require_ipver(ipver)
     _qdisc_setup(cfg.ifname, "fq")
     test_so_txtime(cfg, "mono", ipver, args_tx, args_rx, True)
 
@@ -71,6 +72,7 @@ from lib.py import NetDrvEpEnv, bkg, cmd, defer, tc
 @ksft_variants(_test_variants_fq())
 def test_so_txtime_fq_tai(cfg, ipver, args_tx, args_rx):
     """Run all variants of fq tests, but pass CLOCK_TAI to test conversion."""
+    cfg.require_ipver(ipver)
     _qdisc_setup(cfg.ifname, "fq")
     test_so_txtime(cfg, "tai", ipver, args_tx, args_rx, True)
 
@@ -93,6 +95,7 @@ from lib.py import NetDrvEpEnv, bkg, cmd, defer, tc
 @ksft_variants(_test_variants_etf())
 def test_so_txtime_etf(cfg, ipver, args_tx, args_rx, expect_fail):
     """Run all variants of etf tests."""
+    cfg.require_ipver(ipver)
     try:
         _qdisc_setup(cfg.ifname, "etf", "clockid CLOCK_TAI delta 400000")
     except Exception as e:
-- 
2.54.0

Re: [PATCH net-next v2 0/2] selftests: drv-net: so_txtime: trivial fixes

[Willem de Bruijn]

Jakub Kicinski wrote:
> I noticed that so_txtime is only passing on NIPA setups which are
> looped within a single host. The cross-machine cases just flat out
> fail. The initial bug is obvious - the test does not deploy the binary.
> But even with that I think more work would be needed to sync the
> time / adjust the expectations for a dual-machine test.
> 
> Willem promised to follow up on the fundamental issues with 2-host
> setups :)

Yep.

> v2:
>  - rebase & add cfg.require_ipver(ipver) to the new case
> v1: https://lore.kernel.org/20260608173305.372987-1-kuba@kernel.org

Thanks for the rebase. I was just doing the same.
Still has my tags, but to leave no doubt:

Reviewed-by: Willem de Bruijn <willemb@google.com>

Re: [PATCH net-next v2 0/2] selftests: drv-net: so_txtime: trivial fixes

[Willem de Bruijn]

Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > I noticed that so_txtime is only passing on NIPA setups which are
> > looped within a single host. The cross-machine cases just flat out
> > fail. The initial bug is obvious - the test does not deploy the binary.
> > But even with that I think more work would be needed to sync the
> > time / adjust the expectations for a dual-machine test.
> > 
> > Willem promised to follow up on the fundamental issues with 2-host
> > setups :)
> 
> Yep.

With these fixes the tests run fine manually on a non-dbg kernel.

The CI failures are on the netdev-X710-dbg remote only, correct?

https://netdev.bots.linux.dev/flakes.html
https://netdev.bots.linux.dev/contest.html?executor=hwksft-X710-dbg&test=so-txtime-py

Those flakes all have a delivery later than expected, e.g.,

    # # Exception|   STDERR: payload:a delay:30747 expected:0 (us)
    # # Exception|           exceeds variance (4000 us)

Does this remote have KSFT_MACHINE_SLOW set? This should only result in error

From contest/remote/lib/vm.py on nipa.git:

        slowdown = self.config.getfloat('vm', 'slowdown', fallback=0)
        if slowdown:
            self.cmd("export KSFT_MACHINE_SLOW=yes")

But I don't know where (or whether) I can review this config.