Re: [PATCH net-next 5/5] selftests: drivers: hw: add tests for the ethtool standard counters

[Jakub Kicinski <kuba@kernel.org>]

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!