selftests: drv-net: so_txtime: trivial fixes

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/[email protected]

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

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

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

index b7be4cabbec2..abdd2371cc1a 100755
@@ -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

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.

---
v2:
- add cfg.require_ipver(ipver) in test_so_txtime_fq_tai()
v1: https://lore.kernel.org/[email protected]

---
 tools/testing/selftests/drivers/net/so_txtime.py | 3 +++
 1 file changed, 3 insertions(+)

index abdd2371cc1a..adf6c848d6d8 100755
@@ -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

Yep.

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

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.

Ah, that's probably buggy. You can sort-of see the config written dynamically here
https://netdev.bots.linux.dev/logs/hwksft/X710-dbg/results/684641/deploy

I will fix the SLOW part, but I don't think that's the main problem, if you look at
https://netdev.bots.linux.dev/devices.html
the X710-dbg is actually the only setup that had enough passes to qualify as test supported. The blue cases mean that for most of the other NICs half of the test cases fail. X710 non-debug probably dies because we're waiting for a fix to a NAPI deadlock an earlier test triggers, ignore it.