On Mon, Mar 02, 2026 at 04:07:43PM -0800, Jakub Kicinski wrote: > 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.
Judging by your response it's clear to me that you wanted to transmit something that didn't actually get to me. I am afraid that it's not clear to me what exactly is your feedback and what do you expect as a next step. What I did get: - The new test should work with a single netdevice (and a remote endpoint for traffic generation). - The test should not check for any upper bound for the ethtool counter value. - The test is expected to follow drivers/net/README.rst. Does this mean that your feedback is to convert the bash variant that I submitted into a python one which uses lib.py? If this is your intention, what is the plan for the rmon statistics (or any drivers/net/hw/ bash tests that pre-date the README)? Do you see those eventually getting converted to lib.py? I am merely asking so that I know if I should convert them or they are to be left as is. If I got this all wrong, I'm sorry.
