Re: [PATCH net-next 5/5] selftests: drivers: hw: add tests for the ethtool standard counters
From: Ioana Ciornei
Date: Mon Mar 02 2026 - 07:12:00 EST
On Sat, Feb 28, 2026 at 10:11:26AM +0100, Petr Machata wrote:
>
> Jakub Kicinski <kuba@xxxxxxxxxx> writes:
>
> > On Fri, 27 Feb 2026 14:53:06 +0100 Petr Machata wrote:
> >> Jakub Kicinski <kuba@xxxxxxxxxx> writes:
> >> > On Wed, 25 Feb 2026 17:06:48 +0200 Ioana Ciornei wrote:
> >> >> +ALL_TESTS="
> >> >> + test_eth_ctrl_stats
> >> >> + test_eth_mac_stats
> >> >> + test_pause_stats
> >> >> +"
> >> >> +STABLE_MAC_ADDRS=yes
> >> >> +NUM_NETIFS=2
> >> >> +lib_dir=$(dirname "$0")
> >> >> +# shellcheck source=./../../../net/forwarding/lib.sh
> >> >> +source "$lib_dir"/../../../net/forwarding/lib.sh
> >> >
> >> > Argh, at some point we should probably decide whether we have
> >> > a preference on which "library" / set of env vars we use under
> >> > drivers/net/hw. Adding Petr to CC.
> >>
> >> I think the expectation is that by default, tests written in Bash are
> >> run on one machine without remotes.
> >
> > I think we need to define the guidance by properties of the test, not
> > the machine? Of course _tests_ which don't need a traffic source can
>
> Oh yeah, I'm just stating that's how it currently is and how we got here.
>
> > simply consume the NETIF evn variable, so its trivial to write them in
> > any language without much library support. But for tests which need
> > traffic input we need a different distinction than "does the author
> > care about single-interface machines", so to speak?
>
> 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
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.
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.
This means that some tests will not benefit at all from working with a
remote link partner, it will make them weaker.
Ioana