Re: [PATCH net-next v2 4/6] selftests: drv-net: refactor devmem command builders into lib module

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The refactored `run_rx` and `run_rx_hds` helpers drop the flow steering and client port binding arguments, silently disabling flow steering for standard physical NIC devmem tests.
--

commit 0ae7610db2ce14629da2e4367ef33db95c059f70
Author: Bobby Eshleman <bobbyeshleman@meta.com>

selftests: drv-net: refactor devmem command builders into lib module

This commit refactors the devmem netkit tests to use helper builders in a
library module. It breaks out the rx/tx functions into a shared lib to be
used by both plain and netkit environments.

> diff --git a/tools/testing/selftests/drivers/net/hw/lib/py/devmem.py b/tools/testing/selftests/drivers/net/hw/lib/py/devmem.py
> new file mode 100644
> index 000000000000..6f8a3f5aae14
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/net/hw/lib/py/devmem.py

[ ... ]

> +def run_rx(cfg):
> +    require_devmem(cfg)
> +    if hasattr(cfg, 'netns'):
> +        configure_nic(cfg)
> +    port = rand_port()
> +    socat = socat_send(cfg, port)
> +    data_pipe = (f"yes $(echo -e \x01\x02\x03\x04\x05\x06) | head -c 1K"
> +                 f" | {socat}")
> +    ns = getattr(cfg, "netns", None)
> +
> +    listen_cmd = ncdevmem_rx(cfg, port)

Does this drop the flow steering and client port binding arguments for standard
physical NIC devmem tests?

In the original code, socat was invoked with bind={cfg.remote_baddr}:{port}
and ncdevmem was invoked with -c {cfg.remote_addr}. The -c flag instructs
ncdevmem to install a 5-tuple hardware flow rule via ethtool to steer
traffic strictly to the specific RX queue bound to the devmem memory provider.

Since run_rx() and run_rx_hds() call socat_send() and ncdevmem_rx() without
overriding their default arguments (bind=False and flow_steer=False), no flow
rule is installed for non-netkit environments, and packets are distributed via
standard RSS hashing.

If packets bypass the devmem-bound queue, they are processed by standard
TCP host-copy paths. Could this cause the test to silently pass while
failing to actually exercise the devmem zero-copy feature?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260504-tcp-dm-netkit-v2-0-56d52ac72fd4@meta.com?part=4