Thomas Monjalon opened the Birds of a Feather session with the operating rule (there isn’t one) and asked the room to propose topics. The suggestions came in quickly: graph library evolution, memory management, static code analysis, memory safety, community tooling, Rust. A quick vote consolidated the interest into three tracks, and the room split.
What follows is a summary of what came out of each, none of these produced decisions, they are threads to pull on the mailing list.
Memory management: rethinking allocation in the data plane
Morten Brørup reported back on stage. The starting problem: DPDK applications use mempools for data plane allocation, and mempools require pre-allocating the maximum number of objects the application might ever need. For workloads with variable-size or variable-count objects, that leaves a lot of memory sitting idle. The existing DPDK heap is not a fast path option today, and there is contention between control threads and EAL threads on the same spinlocks.
Mattias Rönnblom has a prototype in this direction, which set the starting point for the conversation.
Morten Brørup has since posted a summary to the dev list, and it is worth reading in full. The group converged on a specific feature set for a new heap: variable-size allocation and free usable in the fast path, possibly bulk operations resembling the mempool API, built on memzones, NUMA aware, using slabs at 2^N block sizes on the Linux kernel model, and per-lcore caches to reduce contention. Independence from the current DPDK heap is listed as a stretch requirement, so the new one could cleanly replace it later.
A few of the finer points from the room. Freeing heap memory back to memzones does not appear to be a requirement. Header-less objects are possible, though headers may pay off when they are small relative to the object. The existing mempool has optimisations for spreading across memory channels and cache alignment that a new heap will need to consider. There is a floor on object size, likely no smaller than a pointer. Returning an object larger than requested is acceptable, for example 16 bytes for a 12-byte request. False sharing between CPU caches may not need to be prevented in every case, but it has to be considered.
The replacement question came up explicitly. Optimally the new heap would replace the existing one, but the timer wheel proposal showed how difficult replacing a core library actually is. The path of less resistance is a parallel library with its own API, chosen at the application level, with the option to become the default later.
The mbuf thread from Morten’s feature creep is preserved as a stretch goal in the summary. Two possible routes: replace the mempool library with a wrapper over the heap, or add a new mempool driver that uses the heap alongside the existing ring and stack drivers. Either way, the pre-initialised fields that mbufs carry in their mempools need somewhere to live. The group did not converge on a solution, only on the fact that mbuf allocation should be considered in the design.
Memory safety and Rust
The session facilitator framed the topic in two halves: memory safety for applications built on DPDK, and memory safety inside DPDK itself, which is written in C. Rust came up as a candidate for both.
For applications, the current path is bindgen. Auto-generated Rust bindings for DPDK’s C libraries let developers write application logic in Rust on top of the existing C API. One participant has been doing exactly this. The trade-off is that a straight bindgen gives access to the C structs and functions without giving idiomatic Rust semantics around ownership, borrowing, or allocation. Whether the community should document a basic bindgen initialisation pattern for new Rust-based DPDK applications came up as a takeaway. Even without an official set of bindings, having a reference for how to get started would let application code capture memory safety where it can.
On the DPDK side, Bruce Richardson pointed to an RFC he has out on the mailing list. Today, initialising EAL from Rust means constructing an array of C strings, which is painful from Rust and equally painful from Python. The RFC proposes an alternate initialisation path that does not rely on C string arrays. Comments on the RFC are open.
The last thread was the build system. If a Rust component sits midstream in DPDK, say a new library or a rewrite of an existing one, with C code above and below it, the build has to work. Nobody in the room had a full answer. Once that build story exists, the door opens to putting Rust anywhere in the tree.
Community tooling and workflow
Thomas reported back on this one. Several threads came up.
The email-based workflow, again. The group discussed why DPDK is on email and what the community loses in new contributors who never make it past the entry barrier. Nobody proposed removing the mailing list. The direction was hybrid: a more approachable platform for people who want one, and tooling to bridge between it and the list. Newer contributors in 2026 are more platform-native than they were five years ago, and this is worth working on now.
Static analysis came up briefly. There is no good local runner today. The GCC static analyzer is what most people rely on. Open topic.
Bugzilla needs work. Bugs need closing when they are done, and maintainers need to be more present on triage. AI could help with routing and reminders. Konstantin Ananyev asked whether bugs could be auto-assigned. The answer today is partial. Assignment is possible but still requires a manual click. Thomas signalled that monthly reports and reminder cadences to maintainers are on the table. A new search UI is already live. Type BPF and open and closed bugs on that subsystem come back in a single view.
AI for code review is already running on every patch. The discussion covered how it works and what needs tuning. When a patch currently under review lands, contributors will be able to run the same review process against their own patches locally, using the rules the community has agreed on.
Thomas also demoed issues.dpdk.org, a new dashboard, and pointed to a new dpdk-issues repository that aggregates the smaller tools coming out of this workflow effort. Both are early. Contributions welcome.
Where to follow up
Morten Brørup’s memory management summary is on the dev list from 18 May, with replies from Konstantin Ananyev and Mattias Rönnblom already in the thread. Bruce’s EAL initialisation RFC is also on the list and open for comment. issues.dpdk.org is live but a work in progress. The dpdk-issues repository is the aggregation point for smaller workflow tools. Anyone with a view on workflow, contribution barriers, or tooling is invited to bring it to the list.
Your First DPDK Review Starts Here
DPDK powers the networking layer for high-throughput packet processing used across telecom, cloud, and research infrastructure. No commit access needed. No prior experience required. Open a patch, read it, and share what you notice.
