On Mon, 2 Mar 2026 14:11:21 +0200 Ioana Ciornei wrote:

quoted

I agree that adherence to the drivers/net/README protocol is valuable to
some users and would be good to uphold if reasonable in a given tests.
If that's what you have in mind.

There are going to be tests where it's not a great fit, but I think that
of those NUM_NETIFS=2 tests that we currently have, maybe
ethtool_extended_state has a good reason to be obstinate, because it
sets up negotiations and needs an extra unplugged netdevice.  

I would add here even ethtool_rmon.sh and this new test that I

I think I already told you that ethool_rmon predates the NIC tests
and bringing it up in this discussion is irrelevant.

submitted. If you are running with a traffic generator on another board
then you can no longer check that the counter's value is as expected
(with a 1% tolerance), you can only check the lower bound.

1% tolerance is impractical for any CI with high test count.
The test will be flaky. And I really doubt that the 1% tolerance
is really necessary to catch most bugs. We're not trying to validate
silicon here.

Additionally, if you are using the same single port also for control
traffic towards the remote traffic generator, then you surely cannot
reliably check that counters that should not be incremented are indeed
not incremented.

I both told you in this conversation how to check the counters,
and written some existing tests for counters.