Jakub Kicinski <[email protected]> writes:
> On Fri, 27 Feb 2026 14:53:06 +0100 Petr Machata wrote: >> Jakub Kicinski <[email protected]> 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. >> >> > 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://[email protected]: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. The reason for my diatribe above was like, if forwarding/lib.sh is clever enough to handle these things transparently, then the NIC case might be supported through a wrapper that just does the right thing, and the test can be overtly just a run of the mill forwarding test. The requirement for the remote netdevice to be up and preconfigured throws a wrench in this idea though, so dunno. One way or another, _some_ brains need to reside somewhere in a library. I'm not sure forwarding.sh is the place. But I don't want to end up in the same situation as like lib/half_the_tests.sh that reinvent logging from first principles again and again.
