TL;DR Summary
Rashid Khan reflects on 15 years of DPDK, discussing how a “boring” and reliable architecture, 100% member retention, and a philosophy of leading by influence have made the project critical infrastructure for 5G, CERN, and beyond.
Most open source projects don’t make it to fifteen years. The ones that do are often in maintenance mode, watching contributor counts decline. DPDK turned fifteen this year, and member retention stands at 100%. Companies aren’t just staying, they’re maintaining their sponsorship levels year after year.
Rashid Khan led Red Hat’s DPDK efforts and served as Chair of the Governing Board during a critical growth phase. When he reflects on what fifteen years of sustained community investment actually looks like, he doesn’t reach for the big numbers first. He reaches for a word most engineers would consider a compliment.
“In the Linux environment ‘boring’ is good,” Khan notes. “DPDK strives to become boring. Meaning it is easy to deploy, and it just works out of the box. DPDK has hit the sweet spot; it works reliably and is part of high-visibility mission critical projects like particle accelerators, extraterrestrial missions, and critical communication infrastructure. That’s when you know you’ve built something that lasts.”
“DPDK is mature now. It’s in a very healthy state, and it has a long runway ahead.”
Maturity Isn’t Bloat
At conferences, engineers occasionally raise the inevitable question: newer projects exist with cleaner codebases. Why stick with DPDK? Khan’s response addresses the reality of infrastructure software.
“It’s always easier to say this is shiny and new when it works with brand new pieces of hardware,” he explains. “DPDK did start at that point with the latest hardware of that time. However, it takes a lot of effort to develop a mature and stable project that enables new hardware, and new features without destabilizing existing functionality.”
Backwards compatibility isn’t technical debt, it’s a requirement. Companies depend on DPDK working reliably on hardware deployed five to ten years ago.
“DPDK has to provide longer-term support for older hardware and at the same time work with new hardware,” Khan says. “Newer releases of DPDK should not be breaking mature hardware out in the field. Backwards compatibility is extremely important. DPDK has done a good job maintaining that.”
Learning to Lead Sideways
Khan spent years in Red Hat’s networking team before taking on DPDK governance. His background was board support packages, kernel networking, upstream contributions, engineering where technical merit determines what gets merged. Leading DPDK’s Governing Board meant applying that same philosophy to governance.
“Leading in open source is mostly leading by influence,” Khan explains. “Most of the people who contribute in the upstream communities do not report to the person leading the upstream project. It’s like leading a team that does not report to you, and the only way to influence them is through the merits of the solution, the merits of the patches proposed, features introduced, and how they will serve the customers and the partners.”
This creates tension for anyone coming from corporate engineering. Product teams need features by specific dates. Upstream communities review patches when reviewers have time.
“The upstream community doesn’t necessarily adhere to the timelines which are needed for commercial products,” Khan notes. “A lot of times they just want to create the best open source solution and not worry about time or release pressures.”
Khan had to convince engineers and decision makers from Intel, Nvidia, NXP, Marvell, and cloud providers that technical directions made sense for everyone, not just Red Hat. His tenure as Chair saw 100% member retention with companies maintaining their financial commitments unchanged. That doesn’t happen unless leadership creates value that members recognize.
Reflecting on the Journey
When Rashid reflects on his time leading DPDK’s governance, specific achievements stand out, not abstract improvements, but concrete changes that made the project stronger.
“We brought in automated testing with the UNH IOL labs,” he says. “We made that in the critical path for the patches and releases. I’m very proud of that effort.”
The University of New Hampshire’s InterOperability Laboratory provided something no single company could: a trustworthy, vendor-neutral testing environment with hardware diversity spanning multiple silicon vendors. Making automated testing mandatory through UNH-IOL meant patches got validated fairly across competing vendors before merging. It also reduced the burden on Thomas Monjalon, one of DPDK’s core maintainers, who had been doing much of that validation work manually.
Financial stability mattered too. “We were able to repeatedly bring back all of the members and their sponsorships. We were also able to keep the financial side of the project extremely healthy.” That financial health enabled investments in documentation and marketing—not glamorous line items, but clear documentation lowers barriers for new users, and marketing efforts help people discover that DPDK solves their problems.
“All in all, we were able to move the needle on many different fronts—on the testing, marketing, documentation, and financial stability,” Khan reflects.
The Moments That Mattered
“A lot of 5G networks started using DPDK in their critical path,” Khan says. “That was a proud moment for us.”
When telecom operators deploy 5G base stations running DPDK, that validates fifteen years of engineering. It means the architecture decisions made in the early 2010s—user space packet processing, polling mode drivers, dedicated CPU cores—solved real problems at scale.
“When we saw more and more DPDK going into production environments and becoming critical infrastructure, that is quite a proud moment.” When you make a phone call, stream a video, or check your bank balance, DPDK is moving those packets somewhere in the chain. Financial trading platforms executing microsecond-critical transactions run DPDK between their servers and network fabric. At CERN’s Large Hadron Collider, particle accelerators use it to move colossal data volumes from collision detectors.
Hands on Keyboards
“Red Hat has been supporting the project on multiple fronts,” Khan explains. “Membership and leadership support, but more importantly, the engineers. We provided people who take care of the maintenance branches, people who run the testing labs, hands on the keyboard doing the actual work.”
Engineers like Kevin Traynor, David Marchand, and Maxime Coquelin became core contributors. DPDK was their focus, not a side project. The commitment makes business sense: “We use DPDK for fast and predictable processing of the packets for virtual environments. It is in the critical path of Red Hat products.”
“Red Hat’s commitment to DPDK is not ending,” Khan emphasizes. “For the foreseeable future, we want to continue supporting financially and with technical expertise.”
The Breadth Nobody Sees
“The DPDK project is not a one or two-company project,” Khan says. “There are so many people who contributed from academia, and many organizations of different sizes. We need to remember the wide breadth of contributions from all.”
University researchers contributed algorithms. Small networking companies submitted drivers. Individual contributors fixed bugs and improved documentation. Cloud providers optimized for deployment patterns critical to their infrastructure. That diversity strengthened the project: no single company could dictate its direction, and technical merit determined what got accepted.
“We worked very hard in improving the governance of the project, and the fundamental thing that we brought in was transparency,” Khan explains. Meetings became predictable. Agendas arrived before meetings, giving people time to think. “We tried to change the meetings from discussions to decisions.”
“Earlier the meetings were a little bit ad hoc. Sometimes meetings were called at the last minute, sometimes the agendas or the slide decks were not sent beforehand. We worked hard to reduce the chaos, and bring governance and maturity to the project.” The 100% retention rate validates that governance predictability and clarity matters.
The Next Fifteen Years
“DPDK works very well with virtual machines and provides critical fast packet forwarding,” Khan says. “We have to evaluate the pros and cons of DPDK working with containers in the kernel context.”
Power efficiency creates new design challenges. “Customers want ultra-low latency, but they also do not want systems to be using 100% power all the time. If there is a way to have some creative thinking where we can provide low latency but not use the full CPU at full tilt, that will be fantastic!”
This becomes critical as AI workloads dominate data center power budgets. “The electricity and cooling demands on data centers are just going to continue increasing because of AI workloads.”
Many-core CPUs require rethinking scaling assumptions. “How many of those cores need to be dedicated to DPDK, and does DPDK scale linearly as you put more and more cores towards network processing?” There is a lot of good work going on to address this.
“As more AI workloads move to the edge, as the ecosystem diversifies, DPDK can play a crucial role,” Khan says. “The framework’s multi-vendor support and ultra-low latency data movement become increasingly valuable as organizations evaluate different architectures and protocols for their specific use cases.”
Welcome to Year Sixteen
The project needs help across multiple areas. Testing and validation remain priorities—if you’re deploying DPDK in production, contribute test cases for your hardware configuration. LTS maintenance needs ongoing attention: long-term support branches need backports, bug fixes, and security patches. Documentation improvements lower barriers for new users.
DPDK needs new reviewers because every patch benefits from fresh eyes. You don’t need commit access or prior experience, just the ability to read code and ask honest questions.
Get involved: Review your first patch
About the DPDK Project
The Data Plane Development Kit (DPDK) consists of libraries to accelerate packet processing workloads running on a wide variety of CPU architectures. By moving packet processing to the user space, DPDK allows for higher performance than is typically possible using the kernel’s network stack.
About the Linux Foundation
The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects, including Linux, Kubernetes, Model Context Protocol (MCP), OpenChain, OpenSearch, OpenSSF, OpenStack, PyTorch, Ray, RISC-V, SPDX and Zephyr, provide the foundation for global infrastructure. The Linux Foundation is focused on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.
Last Updated: 03/19/2026
