Describe the bug
When a Raw Ethernet (DPDK) interface is configured with rx.flow_isolation: true and RX flows are installed dynamically at runtime (via add_rx_flow_async / add_rx_flows_async) rather than as static rx.flows in the YAML, the send-to-kernel fallback rule is never programmed. As a result, once the first dynamic flow is added, all non-matching ingress on that port — including ARP and other control/management traffic — is black-holed into the isolated DPDK pipeline and never reaches the Linux kernel netdev.
The send-to-kernel fallback (a group-0 "jump-all ETH → RX flow group" rule plus a SEND_TO_KERNEL catch-all in the RX flow group) keeps unmatched traffic flowing to the kernel under flow isolation. It is installed in daqiri_init() only when static rx.flows are present (DpdkEngine init path, gated on has_standard_flows / has_flex_item_flows). The runtime dynamic-flow path programmed the steering rule without first ensuring the ETH-jump + send-to-kernel fallback existed, so a "queues-only + flow_isolation: true + dynamic flows" configuration loses kernel connectivity the moment the first dynamic flow is programmed.
This is the configuration documented as supported in docs/api-reference/configuration.md:
Queues-only configs can set flow_isolation: true and then install dynamic RX flows after daqiri_init() …
Steps/Code to reproduce bug
- Configure a DPDK raw interface with
rx.flow_isolation: true, one or more RX queues, a non-zero dynamic_flow_capacity, and no static rx.flows.
- After
daqiri_init(), install an IPv4/UDP → QUEUE match flow at runtime with add_rx_flow_async() (or the batched add_rx_flows_async()).
- Observe that the kernel netdev for that port stops receiving any traffic: ARP resolution and any control-plane protocol sharing the interface stop working (the netdev keeps its IP address but
rx_packets freezes).
examples/daqiri_example_dynamic_rx_flow.yaml exercises exactly this path (flow_isolation: true startup followed by runtime RX flow add).
Expected behavior
Programming dynamic RX flows under flow_isolation: true should preserve the send-to-kernel fallback, exactly as the static startup path does, so that unmatched control/management traffic (ARP, SSH, application control planes) continues to reach the Linux kernel. The fallback should be installed before the first dynamic flow is programmed and should not be duplicated on repeated dynamic-flow updates.
Environment overview
- Environment location: Bare-metal / Docker (NIC-agnostic; reproduces on any mlx5 NIC driven by the DPDK raw engine with flow isolation)
- Method of DAQIRI install: source
Environment details
- OS and version: Ubuntu (Linux 6.x)
- DAQIRI version:
main (branch dpdk-dynamic-rx-kernel-fallback)
- Networking: DPDK raw engine, NVIDIA/Mellanox mlx5 NIC (e.g. ConnectX-7)
- Hardware configuration: reproduces independent of GPU/host platform; originally observed on DGX Spark (GB10) with a ConnectX-7
Additional context
Surfaced in a live deployment (a GPUDirect MITM proxy for a detector image stream) where the detector picks a per-series dynamic UDP destination port, so the match rule can only be installed at runtime. With flow_isolation: true the first dynamic flow cut off the detector's control plane (and ARP) before the acquisition could be triggered. Note that, once the port is isolated without a fallback, deleting the dynamic flow does not restore kernel traffic — the process must be restarted.
Fix is coded; PR #204 to follow.
Describe the bug
When a Raw Ethernet (DPDK) interface is configured with
rx.flow_isolation: trueand RX flows are installed dynamically at runtime (viaadd_rx_flow_async/add_rx_flows_async) rather than as staticrx.flowsin the YAML, the send-to-kernel fallback rule is never programmed. As a result, once the first dynamic flow is added, all non-matching ingress on that port — including ARP and other control/management traffic — is black-holed into the isolated DPDK pipeline and never reaches the Linux kernel netdev.The send-to-kernel fallback (a group-0 "jump-all ETH → RX flow group" rule plus a
SEND_TO_KERNELcatch-all in the RX flow group) keeps unmatched traffic flowing to the kernel under flow isolation. It is installed indaqiri_init()only when staticrx.flowsare present (DpdkEngineinit path, gated onhas_standard_flows/has_flex_item_flows). The runtime dynamic-flow path programmed the steering rule without first ensuring the ETH-jump + send-to-kernel fallback existed, so a "queues-only +flow_isolation: true+ dynamic flows" configuration loses kernel connectivity the moment the first dynamic flow is programmed.This is the configuration documented as supported in
docs/api-reference/configuration.md:Steps/Code to reproduce bug
rx.flow_isolation: true, one or more RX queues, a non-zerodynamic_flow_capacity, and no staticrx.flows.daqiri_init(), install an IPv4/UDP → QUEUE match flow at runtime withadd_rx_flow_async()(or the batchedadd_rx_flows_async()).rx_packetsfreezes).examples/daqiri_example_dynamic_rx_flow.yamlexercises exactly this path (flow_isolation: truestartup followed by runtime RX flow add).Expected behavior
Programming dynamic RX flows under
flow_isolation: trueshould preserve the send-to-kernel fallback, exactly as the static startup path does, so that unmatched control/management traffic (ARP, SSH, application control planes) continues to reach the Linux kernel. The fallback should be installed before the first dynamic flow is programmed and should not be duplicated on repeated dynamic-flow updates.Environment overview
Environment details
main(branchdpdk-dynamic-rx-kernel-fallback)Additional context
Surfaced in a live deployment (a GPUDirect MITM proxy for a detector image stream) where the detector picks a per-series dynamic UDP destination port, so the match rule can only be installed at runtime. With
flow_isolation: truethe first dynamic flow cut off the detector's control plane (and ARP) before the acquisition could be triggered. Note that, once the port is isolated without a fallback, deleting the dynamic flow does not restore kernel traffic — the process must be restarted.Fix is coded; PR #204 to follow.