Re: [PATCH net-next v2] selftests: drv-net: so_txtime: only send test traffic to sch_etf

On Mon, Aug 10, 2026 at 9:31 PM Jakub Kicinski <[email protected]> wrote:
>
> On Sat,  8 Aug 2026 12:00:44 -0400 Willem de Bruijn wrote:
> >      orig = tc(f"qdisc show dev {ifname} root", json=True)[0].get("kind", None)
> >      defer(tc, f"qdisc replace dev {ifname} root {orig}")
> > -    tc(f"qdisc replace dev {ifname} root {qdisc} {optargs}")
> > +    tc(f"qdisc replace dev {ifname} root handle 1: {qdisc} {optargs}")
>
> Ugh, sorry, I should have checked before applying.
> Looks like this regresses the test on all setup in NIPA.
>
> Random example:
> https://netdev.bots.linux.dev/logview.html?f=/logs/hwksft/X710/results/772526/test-outputs/11-so-txtime-py/stdout

Ugh apologies. This did not trigger for me on my debian trixie vm (nor
netdevsim). Where the mq root qdisc handle at boot is not 1:

And I was entirely unfamiliar with the subtle difference in tc qdisc
replace behavior when f"handle {handle}" is added.

Apparently

1. no handle -> can replace with a qdisc of a different kind
2. handle && !match -> same
3. handle && match -> expect modify in place, so kind must be same.

which makes sense.

I can reproduce after

tc qdisc replace dev eth0 root handle pfifo_fast
tc qdisc replace dev eth0 root handle 1: pfifo_fast

It is not possible to replace tc qdisc replace with a del + add pair,
due to "Error: Cannot delete qdisc with handle of zero." on systems
with the default 0: qdisc, like my debian trixie.

The simplest change, then, is to replace the qdisc twice, first for
the kind, then for the handle.

@@ -45,17 +45,18 @@ def _qdisc_setup(ifname, qdisc, optargs=""):
     """
     orig = tc(f"qdisc show dev {ifname} root", json=True)[0].get("kind", None)
     defer(tc, f"qdisc replace dev {ifname} root {orig}")
+    tc(f"qdisc replace dev {ifname} root {qdisc} {optargs}")
     tc(f"qdisc replace dev {ifname} root handle 1: {qdisc} {optargs}")

It's an extra replace, so a bit ugly. But avoiding that requires
parsing the json for existing handle, branching on that.

I'm testing the above some more, will send that if no concerns.