On Tue, 3 Mar 2026 15:53:41 +0200 Ioana Ciornei wrote: > > > 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).
yes > - The test should not check for any upper bound for the ethtool counter > value. more or less.. you can check for crazy values (bitflips etc). Either pick a value too high to be reasonable (100Gbps * time) or hardcode some high threshold (2^31?) > - The test is expected to follow drivers/net/README.rst. yes > Does this mean that your feedback is to convert the bash variant that I > submitted into a python one which uses lib.py? It'd certainly be easier for you, but I'm not against building out the necessary support to run traffic from remote in bash. > 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. Yes, I was planning on doing the conversion once we have some real HW testing going in NIPA. If you're willing to convert them - that'd be great!
