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

[Jakub Kicinski]

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
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 think this fundamentally stems from the fact that running processes in
> Python is a bit unwieldy, so it makes sense to have helpers, so
> everybody uses them, so you can have helpers grow brains to do things
> like over-the-ssh configuration. In Bash, running a traffic generator is
> easier than working with arrays. So the helpers tend not to be as useful
> and we don't generally have them. At least not in any consistent way.
> 
> Eyeing the file, the requirement for the remote interface to be up and
> configured with an IP address is a bit surprising to me. I would think a
> down state is the most natural, and have the test bring it up and
> configure it in a way that it needs. I'm thinking maybe this is to allow
> testing a sole interface on like an embedded device?
> 
> Anyway, that's a fairly strong differency between how Bash tests are
> typically written and the NIC setup. I think basically all existing
> tests assume the devices are theirs to tamper with.
> 
> > The existing tests under drivers/net/hw which source forwarding/lib.sh
> > pre-date the "NIC setup" described in 
> > tools/testing/selftests/drivers/net/README.rst
> >
> > Should we ask "NIC setup" to be used for all tests which only need
> > NUM_NETIFS=2 ? These are basically simple tests where one netif is 
> > a traffic generator and the other is the DUT. And IIUC the "forwarding
> > setup" can't be used when the traffic generator is controlled over SSH?  
> 
> In principle nothing prevents lib.sh from growing brains to support
> these remote shenanigans. I think it's just that so far nobody cared
> enough to actually do it.
> 
> I think that a helper that in effect does "run this on a machine where
> $swp1 is" is mostly what is needed. That and "make sure $swp1 and $swp2
> are on the same machine". It's going to be annoying to work with though,
> because you need to annotate every single command. I bet there's a nice
> syntax to make it not activelly annoying.
> 
> If we have this, it might make sense to require tests to make use of it.
> (With an explicit opt-out for special cases.) But I do not want every
> test to have to reinvent this wheel and cargo-cult snippets from other
> tests.
> 
> BTW, my guess is that even many multi-port tests that I wrote boil down
> to just a bunch of fairly independent loopbacks whose far ends could be
> on remote machines. It's not a priori nonsense to me that one would run
> a test like this, or whatever magic we'd use:
> 
>     ./test.sh ssh://petr@10.1.2.3:eth1 swp1 veth1 ns://foo:veth2
> 
> And it just works, because only swp1 and swp2 need to be bridged, the
> rest can be remote, and the traffic generation helper knows that to pump
> traffic to ssh://10.1.2.3:eth1, obviously you need to ssh there first.
> But the library would need to have helpers for this, and the tests would
> need to use them.

Right, to be clear I primarily care about being able to run these tests
with traffic generator on a remote system. Otherwise someone who cares
about single-port systems will have to add a separate test I guess?
And we will have to maintain two tests? :S

A nice to have is for all drivers/net/hw tests to use the "NIC" env
variables (move tests which really only make sense on multi-port
devices to drivers/net/forwarding?) But I think "translating"
forwarding variables to NIC if NUMIF=2 could easily be done
automatically by the test / lib so that's lower priority.

> At least ethtool counters would cause problems obviously.