DPDK Summit 2026

DPDK transformed wired networking by giving host software direct control over packet processing. This talk makes the case that the same approach should be applied to 802.11 wireless.

Wi-Fi’s real behavior—contention, TXOP scheduling, A-MPDU aggregation, rate adaptation, and retries—is hidden below the 802.3 interface inside firmware and hardware state machines. This prevents per-packet observability and programmable control.

We propose a Wi-Fi Poll Mode Driver model that operates natively on 802.11 frames, exposing aggregation and retry behavior as first-class metadata and accepting explicit transmission parameters (MCS/NSS/BW, TXOP limits, retry policy). With this interface, a DPDK application can coordinate microsecond-scale MAC scheduling with millisecond-scale ECN/AQM control.

We outline the required PMD interface, metadata surface, and driver hooks needed to bring software-defined control to wireless networking.

Slides: https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html 
Acronyms: https://www.umbernetworks.com/dpdk_talk_acronyms.html

In this presentation, we will explore the application of header-data split in zero-copy mechanisms within a disaggregated userspace protocol stack to improve performance and multi-tenant memory safety. We focus on two key points:
1. Performance Optimization
a. Zero-Copy: Achieve zero-copy between the application and the NIC, reducing latency and saving CPU resources.
b. Cache Efficiency: By applying HDS, the userspace stack only loads the protocol headers, reducing cache pollution and making protocol parsing faster.
c. Cross-Socket Access: Headers and payloads can reside on different sockets, eliminating the need for remote data access by applications.
2. Memory Permission Isolation
a. Memory Sharing and Safety: Each application creates memory pool and shares it with the userspace stack. Only read permission is retained in userspace stack after registration on device.
b. Fault Containment and Protection: In the event of memory exceptions in either the application or the userspace stack, their operational stability remain unaffected.
Through detailed design, we have enhanced the performance and safety. Attendees will get an in-depth look at the practical application.

Overview of GFNI based Toeplitz hash implementation

Physical AI systems demand ultra‑low‑latency transport of rich sensor data from the edge to centralized AI compute. This talk showcases a DPDK‑based sensor bridge using NXP i.MX processors as NVIDIA Holoscan Sensor Bridge endpoints, delivering deterministic, zero‑copy perception pipelines. It highlights how DPDK unlocks a new class of real‑time workloads for robotics, industrial vision, and Physical AI.
 

At CERN, the European Organization for Nuclear Research, DPDK has evolved from a performance enabler to a common technology for data acquisition and readout systems across multiple practical use-cases. It is deployed in production in multiple experiments like NA62 and in the prototype detectors at CERN’s Neutrino Platform, and forms part of the architectural foundation for large-scale experiments like DUNE.
For NA62, DPDK replaced a commercial, licensed networking solution, enabling a fully open-source readout stack with improved maintainability and long-term sustainability.
In the DUNE experiment’s prototypes, the challenge was not only transitioning from custom protocols to standard Ethernet, but scaling to multi-100Gbps UDP inputs per computing node. This required NUMA-aware architecture, RX queue partitioning, multi-process separation of control and data planes, memory pool tuning, burst optimization, and careful interrupt and polling strategies to sustain deterministic throughput.
The talk presents concrete architectural patterns, tuning strategies, and operational lessons from large-scale, long-running deployments for physics experiments at CERN.

Grout is a DPDK-based software router that supports IPv4/IPv6
forwarding, VRFs, NAT, and FRR integration. Deploying it, as any DPDK application, inside a Kubernetes pod presents a fundamental challenge: DPDK expects direct hardware access, hugepages, and dedicated CPU cores, while Kubernetes abstracts all of these away by design.

This talk walks through deploying Grout on Red Hat OpenShift, leveraging the platform's operator ecosystem to bridge the gap between DPDK's hardware requirements and Kubernetes' abstraction model. It covers the full stack: configuring the SR-IOV Network Operator to expose virtual functions, using the Node Tuning Operator and PerformanceProfiles to guarantee isolated CPUs, Hugepages, and NUMA-aligned scheduling, and packaging Grout as a container that can consume these resources.

Data-path accelerator (DPA) is an NVIDIA BlueField-3 subsystem that consists of a large number of RISC-V cores integrated with the NIC fabric. DPA cannot comprehensively host DPDK, because DPA is running an RTOS without any conventional services except scheduling. Besides, DPDK core abstractions are suboptimal for DPA or have limited use there. On the other hand, it is desired to run advanced and well-tested DPDK algorithms on DPA. Doing so means running DPDK control plane and data plane code on separate HW and in very different environments. We describe the needed adjustments to DPDK libraries to do so and measure the performance of DPDK code running on DPA. We also outline and discuss the gaps that DPDK could overcome to allow its use in such heterogeneous environments.