On Mon, 2 Mar 2026 14:11:21 +0200 Ioana Ciornei wrote: > > 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.
