Summary
When a single RX interface is configured with both standard flows and flex-item flows, the DPDK flow setup is ambiguous: group 0 ends up with two all-Ethernet jump rules at the same (default) priority, so only one takes effect per packet and the other flow class — together with its send-to-kernel fallback — is effectively dead.
Detail
The two flow paths each install their own all-Ethernet jump out of group 0:
- Standard flows:
add_flow() creates a group 0 → group 3 jump (src/managers/dpdk/daqiri_dpdk_mgr.cpp:2773-2774, pattern = ETH spec=0/mask=0).
- Flex flows:
create_flex_flow_rule() creates a group 0 → group 1 jump (:2568-2571, same all-Ethernet pattern).
Both jump rules match every packet at the default priority (0). A packet can only jump once, so in a mixed config one jump wins and the other group is never reached — meaning that entire flow class (and the corresponding fallback added in #125) silently does nothing.
PR #125 added symmetric handling:
if (intf.rx_.flow_isolation_) {
if (has_standard_flows && \!add_send_to_kernel_fallback(intf.port_id_, 3)) { return; }
if (has_flex_item_flows && \!add_send_to_kernel_fallback(intf.port_id_, 1)) { return; }
}This makes it look like standard and flex flows are independently supported on the same interface, when in practice mixing them is ambiguous.
Suggested fix
At minimum, document the limitation (code comment near the flow loop and/or a known-limitation note in the config docs) that a single RX interface should not mix standard and flex-item flows. A more complete fix would detect a mixed config and reject it with a clear error, or restructure the group-0 jump rules so both classes are reachable deterministically (e.g. distinct priorities / match criteria).
Context
Follow-up from the review of #125 (DPDK flow isolation ordering). The PR mirrors the existing jump structure rather than introducing the ambiguity, but its symmetric has_standard_flows / has_flex_item_flows handling is what surfaced the concern.
Summary
When a single RX interface is configured with both standard flows and flex-item flows, the DPDK flow setup is ambiguous: group 0 ends up with two all-Ethernet jump rules at the same (default) priority, so only one takes effect per packet and the other flow class — together with its send-to-kernel fallback — is effectively dead.
Detail
The two flow paths each install their own all-Ethernet jump out of group 0:
add_flow()creates agroup 0 → group 3jump (src/managers/dpdk/daqiri_dpdk_mgr.cpp:2773-2774, pattern = ETH spec=0/mask=0).create_flex_flow_rule()creates agroup 0 → group 1jump (:2568-2571, same all-Ethernet pattern).Both jump rules match every packet at the default priority (0). A packet can only jump once, so in a mixed config one jump wins and the other group is never reached — meaning that entire flow class (and the corresponding fallback added in #125) silently does nothing.
PR #125 added symmetric handling:
This makes it look like standard and flex flows are independently supported on the same interface, when in practice mixing them is ambiguous.
Suggested fix
At minimum, document the limitation (code comment near the flow loop and/or a known-limitation note in the config docs) that a single RX interface should not mix standard and flex-item flows. A more complete fix would detect a mixed config and reject it with a clear error, or restructure the group-0 jump rules so both classes are reachable deterministically (e.g. distinct priorities / match criteria).
Context
Follow-up from the review of #125 (DPDK flow isolation ordering). The PR mirrors the existing jump structure rather than introducing the ambiguity, but its symmetric
has_standard_flows/has_flex_item_flowshandling is what surfaced the concern.