Summary
The DPDK RX flow-creation loop in DpdkMgr::initialize() ignores whether each flow was actually programmed into the NIC. A specific flow can silently fail to be created while the send-to-kernel fallback (added in #125) succeeds — the result is that every packet is quietly delegated to the Linux kernel and the application receives nothing, with no hard error surfaced.
Detail
In src/managers/dpdk/daqiri_dpdk_mgr.cpp (the loop around 2386-2395):
for (const auto& flow : rx.flows_) {
DAQIRI_LOG_INFO("Adding RX flow {}", flow.name_);
if (flow.match_.type_ == FlowMatchType::FLEX_ITEM) {
add_flex_item_flow(intf.port_id_, flow.match_.flex_item_match_, flow.action_.id_);
has_flex_item_flows = true;
} else {
add_flow(intf.port_id_, flow);
has_standard_flows = true;
}
}Neither return value is checked:
add_flow() returns struct rte_flow* and yields nullptr on failure — the result is discarded.add_flex_item_flow() only printfs on validation/creation failure and otherwise returns the (possibly null) flow.
Because PR #125 now installs a catch-all SEND_TO_KERNEL fallback at priority 100 in the same group, a config where the specific flow failed to create but the fallback succeeded will look healthy at startup, route all traffic to the kernel, and deliver zero packets to the app.
Suggested fix
Harden the flow loop to match the new fallback path: check the return of add_flow() / add_flex_item_flow(), log a CRITICAL on failure, and either abort initialize() (return;, consistent with the EalCleanupGuard + initialized_ mechanism) or at minimum surface a hard error so the silent kernel-only state is detectable.
Context
Follow-up from the review of #125 (DPDK flow isolation ordering). Largely pre-existing, but adjacent to the path that PR hardened — worth fixing while the area is fresh.
Summary
The DPDK RX flow-creation loop in
DpdkMgr::initialize()ignores whether each flow was actually programmed into the NIC. A specific flow can silently fail to be created while the send-to-kernel fallback (added in #125) succeeds — the result is that every packet is quietly delegated to the Linux kernel and the application receives nothing, with no hard error surfaced.Detail
In
src/managers/dpdk/daqiri_dpdk_mgr.cpp(the loop around2386-2395):Neither return value is checked:
add_flow()returnsstruct rte_flow*and yieldsnullptron failure — the result is discarded.add_flex_item_flow()onlyprintfs on validation/creation failure and otherwise returns the (possibly null) flow.Because PR #125 now installs a catch-all
SEND_TO_KERNELfallback at priority 100 in the same group, a config where the specific flow failed to create but the fallback succeeded will look healthy at startup, route all traffic to the kernel, and deliver zero packets to the app.Suggested fix
Harden the flow loop to match the new fallback path: check the return of
add_flow()/add_flex_item_flow(), log a CRITICAL on failure, and either abortinitialize()(return;, consistent with theEalCleanupGuard+initialized_mechanism) or at minimum surface a hard error so the silent kernel-only state is detectable.Context
Follow-up from the review of #125 (DPDK flow isolation ordering). Largely pre-existing, but adjacent to the path that PR hardened — worth fixing while the area is fresh.