DPDK Summit 2026

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.

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.

Doing packet capture in a DPDK application leads to several technical issues. Packet capture needs to be fast, transparent and be easy to use. This talk will cover the different solutions and how they can be improved in the future.

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.