On Sat, 14 Mar 2026 08:51:23 -0700 Stephen Hemminger wrote:

quoted

On Fri, 13 Mar 2026 14:15:00 -0700 Stephen Hemminger wrote:  

quoted

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.

I'm not the right To: for these questions.
You should really put TC maintainers in the CC list next time.

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.

Might lock up when there's a bug or might lock up just because?
Former - yes of course, latter dunno.

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?

If you mean adding scripts that have to be run manually - I don't
think that's a great solution. _Some_ upstream CI has to run them.