DPDK at 15: From Intel’s Internal Experiment to Open Source Foundation

A conversation with Jim St. Leger on shepherding a closed project into one of networking’s most enduring open source communities.

The Architecture That Wouldn’t Fit

In the early 2010s, software-defined networking was gaining traction. Cloud providers and telecom operators wanted to move packet processing off dedicated appliances and onto general-purpose servers. The Linux kernel network stack could handle packets. The performance was unconscionable.

“You had to run too many cores. You had to dedicate too much. It was just way too much hardware,” St. Leger says.

Every packet triggered interrupts and context switches through a stack built for general-purpose computing. For line-rate throughput, the overhead killed you.

Intel’s embedded and communications group supplied chips for dedicated networking appliances, single-purpose boxes: routers that routed, firewalls that filtered. “The challenge of that model is you have these one-off chips that only have a single function,” St. Leger explains. “You’re supplier-locked. You don’t have a lot of flexibility.”

Intel architects started running internal experiments. What if packet processing ran in user space? What if you used polling instead of interrupts? What if you stripped the stack down to pure packet movement?

“There were a lot of internal conversations, frankly internal experiments,” St. Leger recalls. “This is what our architects do.”

Venky Venkatesan and a small team developed the breakthrough approach: polling model, full speed on x86, purpose-built stack. Early implementations delivered 10x performance improvement over the kernel. Later releases pushed that to 40x.

The technical bet paid off. Then came the harder question: what to do with it.

The Tradeoffs You Accept

The polling model requires rethinking the entire computing model. You dedicate CPU cores to packet processing and nothing else. Those cores continuously poll the network interface, checking for new packets. No interrupts, no context switches, no kernel involvement.

This creates immediate problems. Dedicated cores mean you can’t use those cores for anything else. Running in user space means building your own memory management, your own buffer handling, your own driver interface, reimplementing everything the kernel provides, specifically for packet processing, without the generality the kernel needs.

Venky Venkatesan and his team made those tradeoffs deliberately. They gave up flexibility and general-purpose efficiency to get raw throughput. The architecture assumed you had packets to process and needed to process them fast. Everything else was secondary.

What DPDK Actually Does

DPDK processes packets in user space at line rate. The polling model dedicates CPU cores to continuously checking network interfaces for packets, no interrupts, no kernel involvement. Packets arrive, get processed, and move on, all in user space with direct hardware access through poll mode drivers.

The framework provides memory management, buffer handling, and queue management specifically tuned for packet processing. It’s not general-purpose. It’s not trying to be. If you need to move millions of packets per second with minimal latency, DPDK gives you the tools to do that on x86 hardware.

The tradeoff is explicit: you dedicate cores to packet processing. Those cores don’t do anything else. If your workload doesn’t justify that dedication, DPDK might not make sense. If you’re running line-rate networking, cloud infrastructure, or processing massive data streams, the performance gain justifies the core dedication.

From Internal Project to Something Else

Intel initially developed DPDK internally with help from 6WIND as a contractor. The code was always BSD-licensed, technically open, available for anyone to download and use. What it wasn’t was community-driven. Intel engineers built releases internally, validated and tested behind closed doors, then pushed completed releases out to the world.

“We weren’t initially looking to build a true open source community around it,” St. Leger says.”

As DPDK gained traction, Intel started hosting developer-centric events in San Francisco, initially in conjunction with the Intel Developer Forum, then as stand-alone events in Dublin, Shanghai, and San Jose. The community was growing, but the governance model wasn’t.

In 2014 Intel moved the development and control of releases and contributions to dpdk.org. It was the first big step towards being a truly open effort. But customers didn’t want to depend on Intel silicon exclusively. Other hardware providers, especially ARM, wouldn’t participate in a project governed solely by Intel.

“They wanted to have a larger open community,” St. Leger explains. “If you’re a customer, you’re like, ‘Hey, I don’t really want this to be a lock-in for Intel hardware. I’d like this to be a much more neutral community where I get things that work across a variety of silicon.’”

The Big Transition

Moving from internal development to a genuine open source community requires more than changing a license file. It requires changing how engineers think about their work.

“You have to move from an in-house, proprietary-life development to open source community development where you put your code out there and you open yourself up and expose yourself for all the accolades and arrows that come with your code,” St. Leger says. “You need to welcome community comments ranging from ‘Hey, that’s a wonderful idea, keep doing that’, or ‘That’s terrible, why did you do it that way? You should have done it this way.’ That’s a very different mindset.”

At one developer summit, the Linux Foundation’s Chris Wright laid out what genuine open source governance would require. Not just open code, but open decision-making, accepting contributions, and sharing control.

“Chris just put it on the table,” St. Leger recalls. “He’s like, ‘Hey, the community needs to decide how you want to do this going forward.’”

6WIND transferred the dpdk.org domain to the community. Intel committed resources to support the transition. “Initially you might actually need more resources because of the transition costs and overhead in having to include community conversations versus one person making all the decisions.”

the Linux Foundation provided neutral hosting and governance. Companies including Intel, NXP, Marvell, Mellanox (now NVIDIA), and others committed funding and engineering resources. When it came to elected positions, the community looked at who was doing the majority of the contributions. Intel engineers like Bruce Richardson earned leadership roles through technical contributions, not corporate mandate. Thomas Monjalon, from 6WIND, became central to community building through the same merit-based process.

“That shows the community’s confidence in doing not only the right thing, but the fair thing.”

Beyond Networking

CERN uses DPDK at the Large Hadron Collider. Particle physics experiments generate colossal amounts of data that need rapid movement and filtering. When St. Leger toured CERN after the Higgs boson discovery, he met with the data center team. DPDK solved their data movement problem. “For them, it’s a straightforward solution, get the code from the repository, use what you need, check that problem off the list, and move forward.”

Radio telescopes process incoming signals with DPDK. Medical imaging systems use it for high-bandwidth data movement. AI inference pipelines leverage it for rapid data plane processing.

“I’d love to know if there’s a use of DPDK in the world of AI and LLMs,” St. Leger says. “Either training or inference, are they using DPDK in any function as part of their model implementation? I’d love to know the answer to that one.”

These applications share a common pattern: massive data movement with minimal latency requirements. The architecture works for any high-throughput data plane processing.

The Community That Formed

At the first DPDK Summit developer events, Siobhan Butler made cakes. They would be themed to celebrate whatever major release we had just completed. Oh, and did I mention they were delicious?! She’d bring them in for the closing gathering, celebrations of another release, another year, another set of contributions merged.

“We’d gather as a community in celebration,” St. Leger says. “That was just a terrific experience that I hope continues.”

The willingness to have hard conversations defines the community’s health. “The fact that the community can have hard conversations with each other about things and be very open and transparent is what makes the strength of the community what it is.” Not all open source projects manage that balance. Some become toxic. Some fracture along company lines. DPDK maintained the ability to disagree technically while collaborating on solutions.

“Some of the highlights of my career are those kinds of community collaborations with people who, when we switch back to our business roles, are still competitors of my employer.”

What Venky Built

Venky Venkatesan died too young. St. Leger still stays in touch with his wife and one of his daughters. “She’s just a joy to talk to and to see her carrying on the legacy of her dad.”

At DPDK developer summits, Venky was the Pied Piper. After his talks, developers swarmed him with questions, following him into hallways, delaying the next speaker. “I was like, ‘I hope the schedule includes a break now, because people are going to keep asking Venky questions,” St. Leger remembers.

Venky could answer any question about DPDK’s architecture because he made the original decisions. He also worked six to eighteen months ahead of current releases. “His talks usually included things he was working on that were maybe a third done, but he was working on them.” Some experiments would pan out. Others wouldn’t. Venky showed both.

“Bruce Richardson was one of those guys who often worked under Venky’s tutelage,” St. Leger notes. “Venky would give him an assignment: go off and play with this concept, try to implement it, see what you come up with.” That mentorship created the next generation of DPDK technical leaders.

“I think he would have kept working on it right at the end of his life.” The project carries his DNA forward to this day.

Fifteen Years Forward

Most open source projects would be in the sunset phase at fifteen years. DPDK keeps expanding into new domains. The architecture Venky Venkatesan and his team designed in the early 2010s remains relevant because they made the right fundamental tradeoffs: user space, polling, dedicated cores, purpose-built for throughput.

“One of the things I love about all the work I’ve done is when you go into an open source community, you take your company hat off,” St. Leger says. “You sit there with people that are your competitors and you go build something that’s better for all.”

The next fifteen years will bring use cases nobody’s imagined yet. The architecture is flexible enough to adapt. The community is strong enough to evolve it.

For St. Leger, looking back on fifteen years means recognizing the community he helped build.

“I have some DPDK DNA, maybe some of my DNA in the community itself.”

Contributing to DPDK

The project needs contributions across multiple areas. Code review is always valuable, the codebase is substantial, and thorough review catches issues before they hit releases. Testing on specific hardware platforms helps ensure DPDK works across the silicon diversity it’s meant to support. Documentation improvements lower barriers for new users.

Start small. Fix a bug. Improve documentation. Add test coverage. Work your way up to larger contributions. The community welcomes contributors who show up with working code and willingness to collaborate.

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/26/2026