Skip to content

One API to Rule Them All: Reworking the OVS Hardware Offload Layers#

Open vSwitch and OVN 2026 Fall Conference digest Program Adjacent pick 2–4 November 2026

Abstract

Eelco Chaudron, Red Hat, LLC.

  • Why: Offload in OVS was historically duplicated per provider (kernel TC flower vs. DPDK rte_flow via netdev-offload), making vendor integration invasive. The new dpif-offload API layer that has landed upstream unifies this — foundational plumbing for every DPU/SmartNIC story elsewhere in the program.
  • What: The dpif-offload API layer now in OVS: a unified abstraction for hardware offload sitting above provider implementations, centralizing offload handling, simplifying vendor integration, and reducing duplicated logic — plus the migration story from the old netdev-offload model and what it enables next. (from abstract only)
  • How: A single offload API above provider-specific implementations (kernel TC flower and DPDK rte_flow behind it), so new offload features land in one place instead of N.
  • Where applicable: Anyone building or consuming OVS hardware offload (TC flower, DPDK rte_flow, DOCA-style providers); landed upstream, so this is the new baseline architecture rather than a fork.