On Thu, Aug 6, 2026 at 12:16 PM Jakub Kicinski <[email protected]> wrote:
>
> On Mon, 3 Aug 2026 18:18:25 +0000 Mina Almasry wrote:
> > When configuring traffic for the devmem tests, 5-tuple flow steering may
> > be required if the environment does not provide network namespaces.
> > Pass the correct remote address parameter and fall back to 5-tuple flow
> > steering if netns is not available.
>
> Could you clarify what existing upstream test / scenario needs this?
This is needed to give the check_rx_hds test a chance to pass on
5-tuple flow steering driver, like GVE. Without this change:
# Exception| Traceback (most recent call last):
# Exception| File
"/usr/src/kernel/tools/testing/selftests/drivers/net/hw/devmem_lib.py",
line 219, in run_rx_hds
# Exception| wait_port_listen(port, proto="tcp", ns=netns)
...
# Exception| net.lib.py.utils.CmdExitFailure: Command failed
# Exception| CMD:
/usr/src/kernel/tools/testing/selftests/drivers/net/hw/ncdevmem -l -f
eth1 -s 192.168.1.84 -p 46391 -L
# Exception| EXIT: 1
# Exception| STDERR: using ifindex=3
# Exception| using queues 15..16
# Exception| TCP header split: on
# Exception| Running: ethtool -X eth1 equal 15 >&2
# Exception| Running: ethtool -N eth1 flow-type tcp4
dst-ip 192.168.1.84 dst-port 46391 queue 15
# Exception| rmgr: Cannot insert RX class rule: Invalid argument
# Exception| Cannot insert classification rule
# Exception| Running: ethtool -N eth1 flow-type tcp4
dst-ip 192.168.1.84 dst-port 46391 queue 15
# Exception| rmgr: Cannot insert RX class rule: Invalid
argument
# Exception| Cannot insert classification rule
# Exception| ncdevmem: Failed to configure flow steering
# Exception| Running: ethtool -X eth1 default >&2
# Exception|
not ok 4 devmem.check_rx_hds
With this change:
ok 1 devmem.check_rx
ok 2 devmem.check_tx
ok 3 devmem.check_tx_chunks
# Exception| Traceback (most recent call last):
# Exception| File
"/usr/src/kernel/tools/testing/selftests/net/lib/py/ksft.py", line
420, in ksft_run
# Exception| func(*args)
# Exception| File
"/usr/src/kernel/tools/testing/selftests/drivers/net/hw/devmem.py",
line 30, in check_rx_hds
# Exception| run_rx_hds(cfg)
# Exception| File
"/usr/src/kernel/tools/testing/selftests/drivers/net/hw/devmem_lib.py",
line 219, in run_rx_hds
# Exception| wait_port_listen(port, proto="tcp", ns=netns)
# Exception| File
"/usr/src/kernel/tools/testing/selftests/net/lib/py/utils.py", line
356, in wait_port_listen
# Exception| raise Exception("Waiting for port listen timed out")
# Exception| Exception: Waiting for port listen timed out
# Exception|
not ok 4 devmem.check_rx_hds
Yes the test fails, but it gets past the flow steering configuration problem.
And in the code, the change looks correct to me. If flow_steer is
False, then we don't pass the -c arg to ncdevmem. ncdevmem is written
so that if -c is not set, 5-tuple flow steering is not possible (the
client side port is random), so it falls back to 3-tuple flow
steering, which doesn't work on GVE or any other driver that supports
only 5-tuple flow steering.
run_rx (devmem.check_rx test case) doesn't have this problem because
it does `flow_steer=not hasattr(cfg, 'netns')`, but run_rx_hds has
this problem because it forgets to override flow_steer at all. This
patch fixes that.
To be honest while looking at this there were a few weird things. Like
I'm not sure why the python arg is named `flow_steer` (it likely
should be 5_tuple_flow_steer), and why flow_steer setting is tied to
hasattr(cfg, 'netns'), it should be a proprety of the driver you're
runing on (unless all in-netns drivers will support 3-tuple flow
steering).
I am planning to debug the remaining failure running check_rx_hds on
GVE and following up with another patch for that.
--
Thanks,
Mina
