Open vSwitch (OVS) performance case study - From software to hardware offloading, from kernel to userspace#

Speakers: Salem Sol, Gaetan Rivet, NVIDIA

Why: The most substantive engineering talk on connection-tracking offload — the feature OVS-DPDK lacks relative to the kernel datapath, and the reason many DPDK-shops still can't fully move off kernel OVS.

What: The implementation history of CT offloads in userspace OVS. A first attempt via rte_flow reused the flow-offload infrastructure but exposed real problems: thousands of offload updates against millions of connections, asynchronous TCP deletion creating a Last-ACK race (a segment acking a FIN could be fully hardware-processed if the offload isn't deleted immediately on FIN), and very short connections actually being slowed by offloading. The rework uses DOCA with a synchronous design: template-based API, pre-allocated pools of match/action/offload resources, static cooperative threads with minimal locking, a mempool of pre-allocated CT offloads with user-configured size, batched offloading, and a dedicated minimal CT table type.

How: Evaluated with CyPerf-generated HTTP traffic comparing OVS-DPDK vs OVS-DOCA: long-connection CPS (30K rate, 850 KB sessions — the favorable case) and short-connection CPS (40K/30K rates, 2 KB sessions — the worst case with ~3 offloaded packets per connection). Claimed outcomes: negligible overhead for short connections, significant improvement for long ones, better scaling/stability under concurrency. (The result charts are images; no specific figures are quotable from the extracted slides.)

Where applicable: NVIDIA hardware via the DOCA framework — vendor-specific. But the design lessons (offload has real per-connection cost; elephant/mice traffic distribution determines whether offloading pays; state synchronization between HW and SW is the hard part) generalize to any CT-offload strategy.