Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

On 9/3/26 18:51, Andrew Lunn wrote:

> Nice. Did you give the liburing tests a quick smoke test?

I had to bump liburing on my BR setup, I managed to get it to run, but
it wasn't easy :/

I've started an effort to run the kselftests on my fleet of random devices,
trying various ways of interconnecting them with one another. This will be
needed for the ethtool tests.

I'm generating my rootfs with buildroot on all my boards, so I'm slowly getting
a list of options to enable for proper kselftest runs.

Focusing only on drivers/net/hw, all the kselftests that tests the local device
have no trouble running once you get the proper list dependencies installed.

(one example, some tests will grep through include/linux/ethtool.h, so you need
kernel headers on the rootfs)

I've already found some drivers bugs here and there with that, for example mvpp2
fails the RSS kselftests (wonder who wrote that...)

But then there's the kselftests that require a peer, and here it's another story.
Some tests, when using the SSH remote type, will scp a small binary on the peer
and use that binary for testing (sending specially crafted frames, etc.)

Just in the drivers/net/hw tests, we have :

drivers/net/hw/csum.py
drivers/net/hw/devmem_lib.py
drivers/net/hw/gro_hw.py
drivers/net/hw/iou-zcrx.py
drivers/net/hw/nk_qlease.py

Thing is, what I have is a mixed bag of arm, aarch64, a few riscv, x86 and even
ppc32 in there, so as you can guess, scp'ing an arm binary on a riscv peer doesn't
work as one expects... took me a while to figure this out :(

My setup is quite extreme but even for day to day development, I suspect most devs are
directly connecting their embedded board to their x86 host for testing.

We could expand the remote_ssh logic to probe the peer, and raise a skip if it's
a different arch than the dut. Or better, have the DUT check if the peer doesn't
already have the tool in question, i.e. the kselftest "package" is also installed
there.

> 
> I get the feeling not many Embedded people run the self tests, if
> basic things like cross compilation does not work, and native 32bit
> builds spits out 1000s of warnings.

Indeed... my idea for stmmac is to grab as many random stmmac boards as I can to get
a good sample of glue drivers + PHYs, and run the kselftest on them (hopefully one
day feeding that into NIPA).

I can already tell the simple kselftests run well when cross-compiled on arm, aarch64
and riscv but the interop issue needs resolving. Then it's a matter of adding a lot more
tests. Hopefully this will give enough experience on what's to solve so that
everyone else can do it as well...

Maxime