Subject: Re: [PATCH 00/12] netem: fixes, cleanup, and selftest

From: Stephen Hemminger <[email-masked]>
Date: Sat, 14 Mar 2026 08:51:23 -0700

On Sat, 14 Mar 2026 07:09:02 -0700
Jakub Kicinski <[email-masked]> wrote:

> On Fri, 13 Mar 2026 14:15:00 -0700 Stephen Hemminger wrote:
> > The netem packet scheduler is widely used for network emulation but
> > has not gotten enough of my attention lately.  
> 
> There's a few tests in tdcs which need adjusting:
> 
> # not ok 363 d34d - NETEM test qdisc duplication restriction in qdisc tree in netem_change root
> # Command exited with 0, expected 2
> # 
> # not ok 364 b33f - NETEM test qdisc duplication restriction in qdisc tree in netem_change non-root
> # Command exited with 0, expected 2
> # 
> # not ok 365 cafe - NETEM test qdisc duplication restriction in qdisc tree
> # Command exited with 0, expected 2
> # 
> # not ok 366 1337 - NETEM test qdisc duplication restriction in qdisc tree across branches
> # Command exited with 0, expected 2

I have a basic infrastructure question about testing.
Some of the new tests can just go in tdc they are just equivalent
functional test in different format.

But some of the traffic tests where it wants to make sure
that delay, clobber, etc are working don't really fit into tdc
which is API test.

And lastly some of the new tests are designed to ensure that
there is no regression from recursion bugs. Is it ok to have
a test which might lock up the SUT. I assume syszbot does that
all the time.

How about I move the the basic "can you run these tc commands"
into netem.json and leave the shell script for the traffic and
regression tests?