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.

Hierarchical QoS (HQoS) in DPDK enables fine-grained shaping across tens of thousands of flows, but scaling beyond a single core remains challenging. While rte_sched offers flexible software HQoS, synchronization and cache overheads constrain multi-core performance. Modern NICs such as the Intel E810 offer line-rate hardware HQoS, but only at coarse granularity, lacking per-flow control. Partial offload combines both data planes, preserving fine-grained control in software and aggregate shaping in hardware. However, for current partial offloads, the split is uncoordinated. Software selects packets assuming TX capacity is available, but under overload, the NIC may accept only part of the burst, dropping some packets. Because these drops occur after the scheduler, high-priority traffic may discarded, breaking QoS guarantees and increases latency. We introduce Priority-Aware Backpressure (PAB), an extension to DPDK that treats NIC TX failures as congestion signals and dynamically adjusts dequeue budgets per priority. PAB keeps drops within scheduler control, preventing high-priority loss and maintaining stable latency under sustained overload across eight schedulers and 32000 flows.

DPDK offers multiple virtual devices for kernel packet exchange: tap, af_packet, af_xdp, pcap, and virtio-user. This talk benchmarks all five approaches and provides guidance on selecting the right one for your use case.

When DPDK applications need kernel connectivity—control plane traffic, management interfaces, or integration with kernel services—developers must choose among several virtual devices. Direct comparisons are scarce.

grout, an official dpdk.org project, is modular DPDK-based software utilizing the DPDK graph library. This is the third project update, following presentations in September 2024 and May 2025.

The talk will start with a brief recap of grout's design principles: strict separation between control and data planes, OSI layer-based module organization, and runtime configuration via a socket API.

Since May 2025, major updates include an OpenMetrics exporter for production monitoring, a DHCP client for dynamic addresses, improved control plane interfaces for FRR integration, continued multi-VRF work, and Layer 2 bridging with MAC learning. We will discuss the technical challenges and solutions.

We will discuss concrete deployment scenarios: integrating grout with OpenStack Neutron as a third-party L3 provider, and using grout as a PE router in Kubernetes environments. Each use case highlights different grout capabilities.

Finally, you will discover our roadmap for the coming year. Bring your use cases, features and ideas so we can integrate them in the roadmap: what should be added to grout so you can use it?

DPDK-based routing stacks often integrate with Linux by using the kernel as the primary routing and control point, with routing state mirrored into a userspace dataplane. While effective, this model couples the dataplane closely to kernel routing semantics.

This talk explores an alternative architectural approach: treating the DPDK dataplane itself as the routing data plane. Grout is designed to integrate directly with FRRouting (FRR), with routes programmed from FRR straight into Grout, without requiring a kernel FIB.

Using FRR’s dataplane (dplane) API, we developed a Zebra dataplane plugin that intercepts routing operations before kernel installation and translates routes, nexthops, addresses, and VRF information into Grout API calls. This avoids kernel-to-userspace route synchronization and simplifies control/data-plane interactions.

TAP and TUN interfaces provide Linux connectivity for FRR protocol daemons (BGP, OSPF, IS-IS), while packet forwarding remains in DPDK. We also discuss VRF integration, including mapping Linux VRF identifiers to Grout VRF IDs, and present a reusable design pattern for integrating FRR with DPDK-based routing data planes.

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.

In this session, we will explore a use case where PCI endpoint card is utilized to offload cryptographic operations from the host machine. The buffers for these operations are transferred to the PCI card via the virtio/ethernet interface between the host and the endpoint over PCI. We will discuss two distinct approaches to manage crypto operations.

Approach 1: Standard Virtio-Crypto Interface - DPDK/kernel virtio-crypto device is used to establish crypto sessions and transmit data across the PCI endpoint. The endpoint performs cryptographic operations and returns processed data to the virtio-crypto device. The application running on the endpoint translates the virtio-crypto sessions and processes the data using the DPDK crypto device on the endpoint, subsequently sending the processed data back to the host.
Approach 2: LiquidCrypto - Due to limited virtio-crypto offload capabilities, second approach is proposed. This method utilizes the DPDK ethernet SDP interface between the host and endpoint for fast path transport and the kernel SDP interface for slow path and management of the PCI card. The sample applications and the interface library are open-source and available on GitHub.

As network speeds increase, relying on hardware offloading via rte_flow becomes essential. However, the implementation of these APIs varies significantly across vendors. This talk shares findings from an ongoing exploration of NIC performance (NVIDIA, Intel or DYNANIC), with a primary focus on the capabilities and limitations of hardware-offloaded packet filtering using the DPDK rte_flow API. While standard throughput metrics are important, this session moves beyond basic performance to explore the behavior of NICs under stress and in ambiguous scenarios that are often overlooked in standard datasheets.

eBPF support was added to DPDK in 2018, enabling users to execute custom byte-code to extend application functionality without rebuilding or restarting. Our Data-Plane team aims to make eBPF a first-class citizen in HC data-plane appliances. However, safe usage requires ensuring custom programs won't crash the application. The current DPDK eBPF verifier lacks essential features and isn't as robust as the Linux kernel version. This presentation covers two aspects:
- eBPF Usage in Data-Plane Appliances: Current and planned uses, missing DPDK eBPF functionality, and requirements for wider community adoption.
- Verifying the Verifier: We applied bounded model checking and deductive verification to verify the BPF validator's correctness. We uncovered multiple previously unknown bugs across distinct classes. For each bug, we produced counterexamples, verified fixes, and machine-checked proofs. Using an AI assistant, we formally verified the validator in days. We'll share practical lessons for applying AI-assisted formal verification to DPDK subsystems.

As a long-time DPDK developer, I am more used to working on code WITHIN DPDK rather than writing apps USING DPDK. On the odd occasion, when I do need to create an end-user app using DPDK, there are a number of the additional little libraries and tools in DPDK that I reach for to improve the DPDK app development and debug process. These include the cmdline library (including using the new script for cmdline generation), configfile library, telemetry support, and others. While most of these are not likely to be new to many developers, the content here may prove helpful to anyone starting out with green-field DPDK development, or putting together quick apps for packet processing using DPDK.

Over the past year, the Tech Board has been reviewing how to integrate LLMs into the CI workflow to enact an assisted review cycle for patches. This work has looked at various aspects of adding an AI review assistant to the process that can help maintainers and developers spot difficult to reach issues. The results of the trial-and-error testing have lead to a new AI assistant that helps to review patches and series.
In this talk, we'll cover the various roads we took for analysis, AI review infrastructure that lives in the tree, the policy around getting an LLM review of patches, and future work.

Currently, the standard development workflow for DPDK goes something like this: A developer wants to add a new feature or resolve a bug in DPDK, so they write a patch, run the DPDK unit tests against it, and then if those are passing, send it off to the mailing list, where it will get picked up by CI labs that run end to end testing on real hardware using the DPDK Test Suite. Although this solution works fairly well, DPDK developers may also gain some valuable speed and confidence by directly integrating the DPDK Test Suite into their local development workflow. So, I will “demo” the following sequence. First apply a patch to DPDK which either resolves or breaks some DPDK functionality. Then, pass this new DPDK source into the DPDK Test Suite, executing a testcase/testcases on a minimal DTS setup. Then, overview the results produced by DTS, and highlight how the patch applied in step 1 resolved/broke functionality tracked by the testcase/testcases being run. Specifically, I will demonstrate this workflow through the new Flow Offload Testsuite that is arriving to DPDK in DPDK version 26.03.