Check how the DPNI behind your DPDK port was created. From the Linux shell on the board:
restool dprc show dprc.1 --resources # find the dpni.X your DPDK port uses
restool dpni info dpni.X # look at the "options" line and "num_queues"
If options shows DPNI_OPT_NO_FS , or does not show DPNI_OPT_HAS_KEY_MASKING , that's your problem.
Recreate the DPNI with the right options. Either edit dynamic_dpl.sh (or the environment it reads — on NXP LSDK it is typically the DPNI_OPTIONS variable) so the create call looks like this :
restool dpni create \
--options=DPNI_OPT_HAS_KEY_MASKING \
--num-queues=2 \
--num-tcs=1 \
--container=dprc.2
Key points:
- Do not include DPNI_OPT_NO_FS .
- Do include DPNI_OPT_HAS_KEY_MASKING .
- Set --num-queues to at least the number of queues your RSS action references (you asked for queues 0 and 1, so ≥ 2).
Then attach that DPNI to the DPDK container ( restool dprc assign … ) and rerun testpmd.
If you use a static DPL file , add the same to the dpni@X node :
dpni@1 {
options = "DPNI_OPT_HAS_KEY_MASKING";
num_queues = <2>;
...
};
and reflash the DPL via fsl_mc apply dpl … in U‑Boot.
Sanity‑check with a simpler rule first. Before RSS, confirm plain steering works:
testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.0.0.1 / end \
actions queue index 1 / end
If this passes but the RSS variant still fails, the remaining issue is queue count / distribution config, not the DPNI options.
