Pluggable DPIF - Unlocking accelerated OVS full potential#

Speakers: Roi Dayan, Roni Bar Yanai, Eli Britstein, NVIDIA

Why: This is the architectural argument for where OVS hardware acceleration is heading — a runtime-pluggable datapath interface — and it comes with the most honest enumeration of why today's "acceleration below the datapath" model is broken.

What: A proposal to make DPIF a loadable, vendor-implemented API (shared object loaded at runtime), so each vendor ships a datapath that co-designs fast path, slow path, and offload — instead of squeezing hardware through TC flower or rte_flow, both of which are too low-level and constrained (no dp_hash, no CT offload in DPDK, vendor match/action mismatches).

How: The slides walk through concrete failure modes of the current model: a ct() action placed mid-pipeline after packet modifications means a HW miss lands in SW with broken context; dp_hash uses Jenkins in SW while HW hashes differ, causing consistency failures and TCP disconnects; meter state split between HW and SW; megaflow aging relying on per-HW-type counters; EMC/SMC cache context invisible to the offload layer. In the proposed model, packets can be bounced back to hardware (with next recirc-id and metadata) to complete the pipeline, and vendors handle their own DPIF maintenance — formalizing what customers already do by forking dpif-netdev.

Where applicable: OVS community architecture decision with ecosystem-wide implications. The reference implementation is NVIDIA's DOCA DPIF, but the proposal is explicitly multi-vendor (P4 vs DOCA Flow cited as different integration styles). Watch this if you have any SmartNIC/DPU strategy.