Thread (34 messages) 34 messages, 6 authors, 2026-03-03

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

From: Ioana Ciornei <ioana.ciornei@nxp.com>
Date: 2026-03-02 12:11:28
Also in: linux-kselftest, lkml

On Sat, Feb 28, 2026 at 10:11:26AM +0100, Petr Machata wrote:
Jakub Kicinski [off-list ref] writes:
quoted
On Fri, 27 Feb 2026 14:53:06 +0100 Petr Machata wrote:
quoted
Jakub Kicinski [off-list ref] writes:
quoted
On Wed, 25 Feb 2026 17:06:48 +0200 Ioana Ciornei wrote:  
quoted
+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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help