Community Spotlight

TL;DR Summary

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.

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

A conversation on technical trust, vendor politics, and why the hardest bugs to fix are in governance.

The industry needed DPDK because traditional kernel networking couldn’t keep pace. At line rate, interrupt handling and context switching consumed so much CPU overhead that you were spending more time managing packet arrival than actually processing packets.

Telecommunications operators couldn’t deliver 4G services. Data centers were struggling with exponentially growing traffic. Cloud providers were building massive-scale infrastructure. The hardware existed to handle these workloads. The software bottlenecks prevented systems from using it.

“We needed it for telecommunications, without it, 5G and 6G would be very difficult to deliver. Even for 4G it was a real requirement,” Thomas Monjalon explains. “We needed it in data centers where we have to manage very high throughput for all the data.”

DPDK solved the performance problem. It let applications bypass the Linux kernel and process network packets directly in user space, achieving throughput that kernel networking simply cannot match. The architecture optimized for every CPU, used hardware features fully, and gave applications direct access to network devices. Early implementations delivered 10x performance over the kernel stack.

The technical bet paid off immediately. The governance bet nearly killed it.

Thomas Monjalon joined French networking company 6WIND in 2012 to work on Software Defined Networking and Network Functions Virtualization. DPDK was essential infrastructure for that work. He started contributing to the project, learning its architecture, becoming part of the nascent community.

Within a year, he became one of the first DPDK maintainers from outside Intel, joining other early community builders. Over the next twelve years, he would become one of the key architects of DPDK’s transformation, building trust through patient, daily work, establishing governance structures, guiding contributors, mediating technical debates between competing vendors, and ensuring every detail reinforced DPDK’s commitment to genuine openness.

What DPDK Actually Does

DPDK is a framework for building high-performance network and security applications. It provides direct access to network hardware, bypassing the kernel to achieve maximum throughput and minimum latency. The framework handles packet processing, memory management, and device drivers for CPUs and NICs from multiple vendors.

“DPDK lets us use the full power of the hardware,” Thomas says. “When you use DPDK on new hardware, you don’t need to over-provision.” Using hardware to its full potential means purchasing less of it, consuming less power, reducing waste.

The project started focused on networking but expanded as industry needs evolved. “In networking, you often need cryptography as well,” Thomas explains. DPDK now includes cryptography support and is building complete libraries for security protocols. The project has comprehensive IPsec support and is now supporting TLS, MACsec, and PDCP. WireGuard and QUIC are on the roadmap.

The Governance Problem

Intel released DPDK under an open source license, but licensing alone doesn’t create an open community. The project was called “Intel DPDK.” The roadmap reflected Intel’s priorities. Contribution mechanics were opaque. Other hardware vendors, Intel’s direct competitors, needed DPDK for their own products, but joining meant potentially subsidizing a rival’s platform.

“At the beginning when the project was internally managed, nobody wanted to join,” Thomas explains. Companies sent patches. They asked for features. They never received clear signals about whether their contributions fit the project’s direction.

The industry needed DPDK, but if it remained locked to one vendor’s interests, the ecosystem would fracture. For DPDK to succeed as infrastructure for the entire industry, it needed governance that everyone could trust. Someone had to build that trust patch by patch, decision by decision, conflict by conflict.

The Part Nobody Talks About Enough

Before the achievements: DPDK is genuinely hard to integrate, and Thomas will tell you so directly.

“It’s quite difficult to integrate DPDK because it’s mostly responsible for low-level layers,” he says. “When you build an application from scratch, you also need to write all the upper layers.”

DPDK applications bypass kernel protections and standard networking APIs. Developers must understand hardware details that kernel abstractions normally hide. The learning curve is steep. For workloads where throughput and latency are critical, DPDK makes the right tradeoffs.

Proving Openness Through Actions

Thomas became a DPDK maintainer in 2013, one of the first from outside Intel. His role evolved from writing code to building community infrastructure. The contribution process needed documentation. The governance model needed transparency. The technical board needed representation from competing vendors.

In 2014, control of releases and contributions moved to dpdk.org. But concerns remained. Other hardware providers, particularly ARM, wouldn’t participate in a project they saw as Intel-controlled. Intel faced a choice: maintain de facto control, or commit to genuinely shared governance. They chose shared governance, recognizing that genuine open source requires more investment, not less.

the Linux Foundation provided the neutral ground this transformation required, giving the project institutional independence from any single company. Companies including Intel, NXP, Marvell, Mellanox (now NVIDIA), and others committed funding and engineering resources.

“It took years to build trust through actions, not just words,” Thomas reflects.

Bridging Vendor Cultures

Hardware vendors approach problems differently. DPDK needed these vendors to collaborate on shared infrastructure while competing in the market.

“Some design decisions create winners and losers,” Thomas notes. “You have to manage those decisions carefully so everyone understands the real goal is a truly open source project.”

Over time, vendors learned they could influence DPDK more effectively through participation than through pressure. The community grew because participants saw their investments rewarded with actual influence over the project’s direction.

The Work of Building Community

Thomas’s days involve what he calls “improving every detail.” Maintainership means reviewing patches, guiding contributors, refining processes, and ensuring quality. It means paying attention to the small things that collectively determine whether a community functions well or poorly.

“The technical board is very important because that’s where we can step back and think about what the real priorities are, where we should go,” Thomas explains.

The Long View

Twelve years after Thomas and other early maintainers started working to build trust in DPDK’s governance, the work continues. The framework must support emerging security protocols. GPUs are being integrated for specialized processing workloads.

Thomas remains focused on continuous improvement. “When working on DPDK, I’m constantly improving details,” he says. The trust built through consistent, fair treatment of all contributors now enables companies and developers worldwide to build on DPDK confidently.

Getting Involved

“Start with simple modifications,” Thomas suggests. “It’s better if you begin with something small, it’s your first time training in the process. You’re learning from others.”

Code review doesn’t require being a maintainer or years of DPDK experience—just the ability to read patches carefully and provide thoughtful feedback. “When you start contributing and getting involved, try to be consistent in your investment,” Thomas emphasizes.

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

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

From Kernel Beginnings to Open Source Contributions

Ajit Khaparde’s journey into open source networking began in July 2005 at a small startup called Server Engines. Alongside six other engineers in India, he developed his first Linux kernel driver focused on TCP offload, marking his entry into the world of upstream contributions.

Submitting patches to the kernel community was initially intimidating. Ajit often questioned whether his code met expectations, if his formatting was correct, or what kind of feedback he would receive. Over time, he gained confidence, learning that as long as he adhered to community standards, the process became smoother.

As Server Engines grew, it was acquired by Emulex, a Fibre Channel networking company. Ajit continued working on kernel drivers, developing NIC adapters under the “OneConnect” brand. His role remained the same even as Emulex was later acquired by Avago Technologies, and Avago then acquired Broadcom, adopting its name.

In 2015, Broadcom presented Ajit with a choice: continue developing FreeBSD drivers or transition into the world of user-space networking with the Data Plane Development Kit (DPDK). Intrigued by the possibilities of high-performance packet processing outside the kernel, Ajit chose DPDK—a decision that would define the next phase of his career.

Shifting from Kernel to User-Space Networking

When Ajit took on Broadcom’s DPDK development in 2015, the company had not yet upstreamed its first driver. The shift from kernel to user-space programming came with new challenges—faster development cycles, different coding standards, and a distinct approach to commit messages.

Adapting to the DPDK community took time, but maintainers like Ferruh Yigit and Thomas Monjalon helped guide Ajit through the process. Attending user-space conferences also strengthened his connection with the community, allowing him to engage beyond email exchanges and reviews.

By 2016, after multiple rounds of revisions and feedback, Ajit successfully upstreamed Broadcom’s first official DPDK Poll Mode Driver (PMD). This milestone formally integrated Broadcom’s NIC hardware into the DPDK ecosystem.

Nearly a decade later, Ajit continues to contribute, adding support for newer generations of Broadcom hardware, aligning with evolving DPDK APIs, and mentoring developers entering the community.

Leading Development and Adapting to Change

Ajit began as a one-person team, which allowed him to immerse himself in DPDK development at a deep technical level. As Broadcom expanded its DPDK support and released new hardware, the team grew to six engineers, then even more as the driver evolved.

Though Ajit does not formally manage a team, he plays a crucial leadership role—tracking trends in the DPDK community, guiding developers, and ensuring Broadcom’s drivers align with community standards. One major shift occurred in 2017–2018 with the introduction of the rte_flow API, which overhauled packet filtering in DPDK.

Initially, Broadcom’s driver lacked support for this new API. Recognizing its importance, Ajit led discussions with hardware architects and management, advocating for a redesign. The transition was significant, requiring a new implementation strategy. As a result, more engineers joined the effort, marking an inflection point in Broadcom’s engagement with DPDK.

For Ajit, this experience underscored the balance between independent research and collaborative leadership. Keeping pace with community developments while integrating Broadcom’s hardware capabilities became an ongoing effort.

Anticipating Industry Trends and Expanding DPDK Use Cases

As Broadcom continued to innovate, Ajit found himself at the intersection of new hardware releases and emerging DPDK features. Some updates were community-driven, while others stemmed from direct customer requests. Often, Ajit and his team had to decide whether to proactively adopt new capabilities or wait for customer demand.

A key example was GPU Direct with RDMA, a technology traditionally associated with NVIDIA’s Mellanox NICs. After attending a DPDK Summit session on the topic, Ajit saw an opportunity to make Broadcom NICs compatible with this ecosystem. Though no customers had explicitly requested it, he pursued an experimental implementation. It worked. By demonstrating interoperability, Broadcom opened new possibilities for customers exploring high-speed networking with GPUs.

Beyond development, Ajit has also contributed to the broader DPDK project. He previously managed the DPDK Bugzilla, tracking user-reported issues, though follow-up was sometimes challenging due to limited community engagement with the tool. He also participated in weekly DPDK community calls but later transitioned to email-based collaboration due to the calls’ late-night timing in his California timezone.

Looking forward, Ajit sees DPDK shifting from a purely developer-driven toolkit to a platform enabling diverse applications. Historically, Broadcom’s customers have used DPDK primarily for high-speed packet processing in telecommunications and networking. However, new opportunities are emerging, including video processing, GPU acceleration, and real-time data manipulation.

Ajit has already experimented with CUDA integration, envisioning scenarios where DPDK-powered NICs could offload packets directly to GPUs for real-time image processing—resizing, watermarking, or even AI-driven analysis. As he puts it, 

“Fast packet processing is great, but the real potential emerges when you use that speed to accomplish something meaningful.”

A Commitment to Open Source and High-Performance Networking

Ajit has witnessed significant changes in both the Linux kernel and DPDK communities. From upstreaming his first kernel driver at Server Engines to leading Broadcom’s contributions to DPDK, his journey reflects the adaptability required in the ever-evolving networking landscape.

He has also observed the industry’s reluctance to upgrade. Many customers still run DPDK 17.11, avoiding new versions due to cost and risk concerns. While Ajit encourages customers to adopt the latest releases, he understands the operational realities that lead some to remain on older versions. Supporting both cutting-edge adopters and legacy deployments is a constant balancing act.

At a recent DPDK Summit, Ajit was particularly fascinated by a talk on astronomy and high-performance networking—analyzing massive amounts of data in real time, storing it efficiently, and making sense of patterns over years or even decades. This ability to blend networking, hardware acceleration, and real-world problem-solving represents what Ajit finds most exciting about DPDK’s ongoing evolution.

With nearly two decades in open source development and a deep, ongoing commitment to DPDK, Ajit remains a key contributor—driving innovation, mentoring peers, and ensuring the project’s continued growth. His journey is a testament to the dedication, curiosity, and collaboration that define high-performance networking in the modern era.

Welcome to another edition of our DPDK Developer Spotlight, where we explore the careers and insights of key figures who have shaped the DPDK community. In this spotlight, we share the journey of Qian Xu, a Software Validation Manager at NVIDIA, who has been deeply involved in the DPDK from its early days.

Early Days and Introduction to Open Source  

Qian’s introduction to open source tech happened somewhat serendipitously. While working at Intel, she was assigned to the DPDK project, which Intel initiated in 2010 and released under a permissive open source license. The open source community for DPDK was established at dpdk.org in 2013 by 6WIND, and the project continued to grow until it was successfully transferred to the Linux Foundation in 2017.

In the project’s early days, Qian became fascinated by its community-driven aspects. The difference between corporate-led initiatives and the inclusive, collaborative nature of DPDK captivated her, leading her to fully engage with the community.

First Experiences in the Community

When Qian Xu first joined the DPDK community, her entry was marked by interactions that would shape her entire experience. Initially, she was primarily engaged in testing, not frequently submitting patches, which allowed her to observe the dynamics of the community from a unique vantage point. 

Her initial period with the project was guided by Thomas Monjalon, one of the original maintainers of DPDK, whose reputation was well-known among developers in Shanghai and beyond. Contrary to the daunting tales of his strictness, Qian found Thomas to be incredibly helpful and supportive, a disposition that greatly eased her integration into the community.

Thomas and the other maintainers’ approachability was crucial as Qian navigated the new environment. He was not only receptive to feedback but actively encouraged Qian to voice her concerns about continuous integration practices or any other aspects of the project that might require improvement. This open dialogue fostered a collaborative relationship, proving that the community was responsive and genuinely interested in evolving based on its members’ input.

Qian’s interactions weren’t limited to informal discussions; they extended into more structured community engagements. She actively participated in various forums, detailed email threads about release testing statuses, to the DPDK Summit APAC and other international meetings, often communicating through emails and occasionally through IRC for more immediate concerns. 

Technical Contributions

Qian Xu’s technical contributions have been vital to the growth of the DPDK community, especially in Continuous Integration (CI) processes, testing frameworks, and performance testing methodologies. Starting as a validation engineer, she played a key role in developing the DPDK Test Suite (DTS), one of her most notable achievements. The DTS has since become a cornerstone of the DPDK open source automation framework.

Development and Evolution of DTS

Under Qian’s guidance DTS marked a significant advancement in how DPDK could be tested and validated across different environments. Her leadership in this project involved designing the architecture of the test suite, ensuring it was robust and flexible enough to handle a variety of networking scenarios. This tool allowed for the automated testing of DPDK components, significantly reducing manual testing efforts and accelerating the developmental feedback loop.

Launching the First Performance Report

Qian was also instrumental in publishing the first DPDK performance report. This initiative set a precedent within the community, providing a transparent and replicable method to benchmark the performance of DPDK implementations. Her work laid the groundwork for subsequent reports, which have become crucial resources for developers seeking to understand and optimize DPDK performance.

Collaboration and Lab Development

Beyond software development, Qian played a pivotal role in establishing a physical testing lab for DPDK. This lab, set up in collaboration with the University of New Hampshire, provided a shared resource for developers around the world to conduct more sophisticated testing scenarios that could not be easily replicated locally. She facilitated remote debugging and testing procedures, which were critical during the integration and continuous delivery phases of the CI/CD pipeline.

DPDK into the Future

Qian envisions a dynamic and evolving future for DPDK, particularly as it integrates more deeply with AI, machine learning, 5G, and cloud computing. Over the past decade, DPDK has undergone transformative changes, significantly enhancing networking performance and becoming a fundamental component across various infrastructure domains. 

Integration with AI and Machine Learning 

As DPDK ventures into AI, Qian foresees the framework enhancing its capabilities to support AI operations, particularly in managing and optimizing data flow at incredible speeds. This integration aims to reduce latency in AI data processing, making real-time analytics and decision-making more efficient.

Evolving Continuous Integration (CI) Practices 

Qian also highlights the potential evolution of DPDK’s CI practices. Initially, the CI systems were less mature, but they have grown more robust over time, reducing false alarms and improving stability. With the infusion of AI into CI, Qian believes that testing processes can be further automated and refined, allowing for quicker identification and resolution of critical issues before they affect the main branches. This would involve less human intervention, making the testing process more efficient and less prone to error.

The Importance of a Diverse Community 

Qian’s experience as a woman in tech highlights the evolving diversity within the DPDK community and NVIDIA. She has witnessed a positive shift towards greater gender equality, supported by inclusive practices and the Linux Foundation’s collaborative approach. Her advice to aspiring female engineers is to engage deeply, contribute meaningfully, and leverage the supportive environment increasingly present in open source tech communities.

In essence, Qian Xu sees a positive trajectory for diversity in tech, especially in the DPDK Asia Pacific community, driven by systemic changes in the region and a community commitment to equality. Her experience underlines the importance of inclusive practices and the continuous effort needed to maintain and expand these gains within the tech industry.

Best Advice Ever Given

Qian often reflects on a piece of advice that has influenced her professional trajectory and personal growth. Throughout her career, from her early days in networking to her current role at NVIDIA, where her responsibilities are more focused on AI, Networking and DPDK integration, she has adhered to this guiding principle: focus deeply on your chosen domain. This advice, garnered from numerous interviews with industry leaders and her own mentors, encouraged her to dedicate herself fully to mastering the intricacies of her field.

The Growth of the APAC Community and Getting Involved

Qian emphasizes the importance of active participation in the DPDK community, especially in the APAC region. She encourages newcomers to engage in discussions, attend regional summits, and contribute code. The APAC region has seen increased participation, with diverse representation from countries like China, Japan, and India, contributing significantly to the global DPDK landscape.

Forging the Future at NVIDIA

Qian Xu envisions a future where DPDK (Data Plane Development Kit) continues to be a pivotal element in the evolution of networking and computational technologies, particularly as these fields intersect with AI and cloud computing. At NVIDIA, her focus on enhancing solution-level testing allows her to channel DPDK’s capabilities into broader technological advancements, even if her work no longer revolves directly around DPDK’s core components.

This is particularly relevant as NVIDIA pushes the boundaries of AI computing and network performance, areas where efficient data handling and processing are critical. 

As highlighted in NVIDIA’s recent initiatives, such as the development of AI-driven platforms and enhancements in GPU rendering, the underlying principles of high-speed data processing championed by DPDK are integral to these advancements.

By marrying DPDK’s network processing strengths with NVIDIA’s leadership in AI and GPU technology, Qian aims to cultivate a technology landscape that not only advances NVIDIA’s commercial goals but also propels the industry forward. 

Balancing Work and Life

Qian values family time and enjoys bicycling and traveling with her family to maintain a healthy work-life balance. These activities help her stay grounded and focused.

Indispensable Technology

AI and networking technologies are indispensable to Qian. She highlights AI advancements, like ChatGPT, as crucial in both her professional and personal life.

Closing Thoughts

Qian champions the contributions of female engineers in China, expressing gratitude for their increasing recognition. Her journey offers valuable lessons in cultural adaptability and proactive community engagement, inspiring both current and aspiring DPDK developers.

We hope Qian’s story motivates you to engage with the DPDK community and contribute to the future of networking and infrastructure technologies.

Get involved by joining the mailing lists here: https://www.dpdk.org/contribute/#Mailing-Lists

Jerin Jacob, a Senior Director at Marvell, is a pivotal maintainer in the DPDK community. With 20 years of experience, Jerin’s career began with Linux kernel development, laying the groundwork for his extensive contributions to high-performance networking. After joining Cavium, later acquired by Marvell, Jerin was tasked with supporting an open-source data plane framework on the OCTEON processor family, marking the beginning of his journey with DPDK.

A Natural Progression into Software Development

Jerin’s journey into software development began in his early childhood. He recalls playing card games and needing to emulate dice rolls. Using a bit of ingenuity and low-level programming, he turned a calculator into a makeshift dice emulator. This early exposure to basic programming concepts sparked his interest in computers during the early 1990s.

After completing his school years, Jerin pursued a diploma in Electronics and Communication, followed by a degree in Computer Science Engineering. During his diploma, he had access to Windows 3.1, where he started programming in BASIC and System programming. These initial experiences laid a strong foundation for his future endeavors.

In his engineering studies, Jerin transitioned to Linux kernel work, a significant shift from his earlier experiences with Windows 95. His first job involved moving Linux to embedded systems, a novel concept at the time. He worked on Multimedia SoCs focusing on  Linux architecture/SoC porting and peripherals drivers for PCI, USB and Storage. This period, encompassing about ten years of full Linux development, significantly shaped his skills and expertise.

After a decade in Linux development, Jerin moved to Cavium, a company known for its innovation in the semiconductor industry who specialized in ARM-based and MIPS-based network, video, and security, This opportunity marked a new era in his career as he delved into user-space data plane work, which required a different mindset. Optimizing for performance became paramount, and he honed new skills in system-wide knowledge, Cache architecture, Virtualization, SMMU (System Memory Management Unit), and writing optimized drivers. 

This skill set of balancing high performance with the flexibility to accommodate various vendor’s in driver subsystem development, set the stage for his future contributions to DPDK, where he would learn to create APIs that maintained performance while enabling contributions from multiple vendors to support vendor neutral APIs in DPDK.

The Technical Transition from Cavium to Marvell

Initially, when Cavium was in the data plane market, they had a SKU called OCTEON, which was primarily a proprietary SDK (Software Development Kit) based on MIPS architecture. To attract more customers and leverage open source activities, they decided to contribute to DPDK. Jerin led the Cavium/Marvell transition in this effort, adding ARM64 architecture support and specific hardware drivers.

Most of this work was done during his time at Cavium, including the initial ARM64 port. When Cavium’s acquisition by Marvell began, the focus shifted to fully integrating open-source contributions, moving away from proprietary SDKs. Marvell was instrumental in initiating this shift. In particular, Jerin’s manager at the time, Prasun Kapoor (now Assistant Vice President of Core Software, Infrastructure Processors at Marvell Technology), was pivotal in facilitating Jerin’s contributions to the DPDK community and the broader open source ecosystem.

Under Prasun’s guidance, Jerin was able to focus on integrating ARM64 support and specific hardware drivers into DPDK, transitioning from proprietary SDKs to fully open source contributions. This strategic shift has been supported by Marvell’s commitment to open-source innovation, a direction strongly advocated by Prasun at the time.

This strategic move allowed the team to build open-source accelerator drivers and contribute significantly to the DPDK community. This transition also marked the expansion of Jerin’s team, growing from a single person to around 50 contributors, significantly enhancing their collaborative efforts in high-performance networking. For instance, in Marvell’s current SKUs (Stock Keeping Units), Jerin achieved the capability of handling 105 million packets per second per core, a testament to his focus on performance optimization.

The acquisition of Cavium by Marvell, completed in July 2018,  was a strategic move to create a leading semiconductor company focused on infrastructure solutions. This merger combined Marvell’s expertise in storage controllers, networking solutions, and high-performance wireless connectivity with Cavium’s strengths in network, video, and security processors.

The Journey into DPDK

Being one of the first contributors to the DPDK project was both challenging and rewarding for Jerin Jacob. The community played a significant role in this journey, constantly providing feedback and support. When Jerin began working on adding ARM64 support, his initial task was to eliminate dependencies on x86 in the build process. This effort involved adding a new layer for ARM64 support, benefiting greatly from the input and guidance of other maintainers at that time.

The early DPDK community was small, comprising a few dedicated individuals. Jerin recalls working alongside Bruce Richardson, Thomas Monjalon, Konstantin Ananyev, Stephen Hemminger, and Anatoly Burakov. While Anatoly primarily focused on the memory subsystem, Bruce and Stephen were deeply involved in various aspects of the project. Konstantin Ananyev, an x86 maintainer, was also instrumental in helping Jerin navigate the intricacies of integrating ARM64 support, providing valuable insights on maintaining cross-architecture compatibility.

Technical Contributions

Jerin started contributing to DPDK by tackling the significant challenge of removing x86 build dependencies and introducing ARM 64-bit (ARM64) support. This groundbreaking effort involved optimizing numerous libraries for ARM-specific instructions, making DPDK versatile and robust across different hardware platforms.

One of Jerin’s major achievements includes the development of the Event Device subsystem, which abstracts work scheduling aspects of hardware. This subsystem has been widely adopted by companies like Ericsson, Intel, NXP, and Marvell, demonstrating its broad applicability and impact.

Jerin also authored the Regular Expression (RegEx) device class and ML (Machine Learning), enabling advanced pattern matching  and machine learning capabilities within DPDK. Furthermore, he developed the Graph Library, which enables graph-based packet processing, and the high-performance Trace Library, essential for performance monitoring and debugging. Both libraries have significantly enhanced DPDK’s capabilities.

In addition to his technical contributions, Jerin has been a respected maintainer in the DPDK community. He assists with maintaining various subsystems and sub-trees, collaborates with other major contributors, and represents Marvell on the technical board.

Work-Life Balance

Jerin Jacob places a high value on maintaining a balanced work-life dynamic, even while managing the demands of a high-paced career. One of his favorite ways to unwind and recharge is through travel. He typically plans solo trips once or twice a year, offering him the opportunity to explore new places and experiences. Additionally, he ensures to take at least one family trip annually, cherishing the moments spent with his loved ones and creating lasting memories.

Apart from traveling, Jerin is committed to lifelong learning. He dedicates time to expanding his knowledge in various fields, including Advanced Machine Learning (AML) and other emerging technologies. This continuous learning enhances his skill set and keeps him abreast of the latest advancements in his field.

Advice to New Developers Entering the Community

For new developers entering the community, Jerin suggests diving into the existing bug lists, starting with minor bugs or major ones depending on your comfort level. Fixing bugs, no matter the size, is an excellent way to familiarize yourself with the codebase and understand the project’s intricacies.

Another crucial area to focus on is improving the build system. This aspect is common to all contributors and offers a manageable way to get involved without feeling overwhelmed. Start with lightweight tasks that you can handle comfortably. This approach helps you gain confidence and learn the workflows and standards of the community.

Once you feel comfortable and have gained some recognition within the community, gradually move on to contributing to subsystems and higher-level aspects of the project. These areas require more time and more profound knowledge but offer significant learning opportunities and a chance to make a substantial impact.

The Importance of DPDK Summit Events and In-Person Interactions

Jerin’s experience with DPDK events has been instrumental in shaping his contributions to the community. He has attended almost all the European Summits, which serve as vital platforms for maintainers and tech leaders to communicate and collaborate. These summits provide an opportunity for in-person discussions, which are invaluable for exchanging ideas and resolving issues more effectively than through mailing lists alone. 

Reflecting on his first summit, Jerin recalls the excitement and the significant difference it made to meet people in person after years of communication through mailing lists. The initial years, around a decade ago, did not feature many summits, or he was not in a position to travel. The shift from purely online interactions to face-to-face meetings brought a new level of understanding and collaboration. The feedback and discussions that occurred in person were far more proactive and productive, helping to build a sense of camaraderie and mutual understanding.

Meeting his peers in person allowed Jerin to understand their perspectives and work more seamlessly with them. He highlights that once you know people personally, it becomes easier to align proposals and projects to meet their expectations and avoid potential conflicts. This personal interaction helps in anticipating how someone might react to a new idea, enabling a more strategic approach to collaboration.

DPDK Maintainers as a Band of Musicians

If DPDK maintainers were a band, each member would play a unique and vital role, similar to musicians in an orchestra or a rock band. In this analogy, Jerin sees himself as the lyricist. The lyricist’s role is crucial as it involves creating the first stage of the song, defining how it needs to be structured, and setting the tone and direction for the rest of the band. This is akin to Jerin’s contributions to DPDK, where he defines high-level designs and APIs, laying the groundwork for others to build upon.

As a lyricist, Jerin focuses on the initial conceptualization and strategic planning of the project. He provides the foundational elements and guidelines that others follow to ensure the project progresses smoothly and coherently. Just as a song starts with lyrics that give it meaning and direction, Jerin’s work ensures that the project’s core components are well-defined and robust.

While Jerin primarily identifies with the role of the lyricist, he acknowledges that maintainers can take on multiple roles within the DPDK “band.” However, due to his current responsibilities, he is more focused on the planning and strategic aspects rather than individual contributions. He likens this to writing the lyrics rather than performing on stage.

Technology Jerin Could Not Live Without

For Jerin, mobile devices and computers are indispensable. These technologies are not only integral to his daily life but also form the backbone of his professional work. Mobile devices, in particular, offer the flexibility and connectivity that keep him engaged and productive, no matter where he is. They enable seamless communication, instant access to information, and the ability to manage various tasks on the go.

Computers, on the other hand, are essential for more intensive computing tasks, development work, and large-scale projects. They provide the robust capabilities needed for coding, debugging, and running complex simulations. Jerin relies heavily on these tools to execute his work efficiently and effectively.

In addition to these fundamental technologies, Jerin is continuously learning and adapting to new advancements. He is particularly interested in Artificial Intelligence and Machine Learning (AI/ML). By exploring how AI/ML can be leveraged, Jerin aims to offload mundane and repetitive tasks, allowing people to focus on more critical and creative aspects of their work. This approach not only enhances productivity but also fosters innovation.

The Future of DPDK and the Impact of AI

Jerin envisions a future where many routine and repetitive tasks in software development are offloaded to artificial intelligence (AI). This includes writing unit test cases, ensuring proper git commits, checking the sanity of code, and refactoring. AI’s role will be to handle these mundane yet essential tasks, allowing developers to focus on innovative and complex aspects of development.

He believes that once the initial ideas and high-level design are defined, AI can significantly accelerate the development process. While AI can take over tasks that follow set patterns and rules, such as generating unit test cases or identifying code regressions, the core implementation and performance-critical coding will still require human expertise. This is because the nuanced understanding of performance optimization is something that AI cannot fully replicate yet.

By automating repetitive tasks, AI can reduce the workload for maintainers. For instance, when a new patch is submitted, AI can review the code for basic sanity checks, allowing human maintainers to concentrate on more complex reviews and implementation details. This synergy between AI and human developers can lead to more efficient and faster development cycles. Jerin sees AI playing a crucial role in integrating new technologies and developing new libraries.

The Convergence of AI and Emerging Technologies in DPDK’s Future

Jerin envisions a transformative future for the Data Plane Development Kit (DPDK) project, driven by the convergence of AI, IoT, decentralized infrastructure, cloud computing, 5G, and other emerging technologies. This integration will significantly influence the direction and development of DPDK.

Expanding Beyond Drivers

Initially, DPDK focused primarily on driver development. However, the project’s scope is now expanding to include protocol aspects. For instance, Marvell has recently upstreamed support for security protocols like PDCP and TLS. The DPDK graph library is setting the stage for further protocol support, which will extend the project’s capabilities beyond simple driver APIs to include hardware-accelerated protocol development.

Workload-Driven Accelerators

In the past, general-purpose CPUs were sufficient for most tasks. However, the landscape is shifting towards workload-driven accelerators. Today’s approach involves understanding specific workloads and optimizing for them, rather than developing generic solutions. This top-down methodology means that companies, particularly hyperscalers like Google, are designing chips tailored to their specific workloads. This shift from general-purpose to workload-optimized accelerators is a key trend that DPDK is aligning with.

Offloading to Accelerators

Jerin sees a future where various tasks are offloaded to specialized accelerators. Starting from packet processing, the evolution includes offloading complete security, AI, and machine learning workloads. This shift involves using data processing units (DPUs) or other specialized processors (XPUs) to handle intensive tasks, allowing the main host CPU to focus on orchestrating these processes rather than executing them.

The Role of AI in Development

AI will play a crucial role in automating many routine tasks within DPDK development, such as writing unit test cases, ensuring proper git commits, checking code sanity, and refactoring. By offloading these repetitive tasks to AI, developers can focus on more complex and innovative aspects of development. While AI will handle the repetitive and structured tasks, human developers will continue to drive the implementation of new ideas and performance-critical code.

Future Integration and Development

As AI and blockchain technologies become more integrated, DPDK will adapt to support these advancements. The project will continue to evolve, focusing on enabling seamless integration and efficient execution of these emerging technologies within the DPDK framework. This includes optimizing accelerators for specific workloads, ensuring that the host CPU delegates rather than performs intensive tasks.

Overall, Jerin Jacob’s vision for DPDK involves a continuous evolution towards supporting more complex protocols and workloads, driven by the convergence of AI and other emerging technologies. This will enable DPDK to remain at the forefront of technological innovation and performance optimization.

Reflections on Open Source and DPDK

Jerin has been a significant contributor to both the Linux kernel and the DPDK (Data Plane Development Kit) projects. Reflecting on his journey, he shares his thoughts on the impact of open-source contributions to his career and personal growth.

Jerin finds great enjoyment in contributing to open source projects. This joy stems not only from the act of coding, but also from engaging with the community. “You can learn a lot from the community and how other people think about a given technical problem in different ways,” he explains. The collaborative nature of open source fosters an environment where diverse perspectives come together, leading to innovative solutions and continuous learning.

Contributing to DPDK has played a crucial role in Jerin’s personal and career development. He acknowledges the platform as a stepping stone in his corporate journey. “It’s helped me in a lot of personal growth as well,” Jerin states, emphasizing how open source contributions have bolstered his professional advancement. By proving his skills and consistently contributing to high-impact projects, Jerin has been able to climb the corporate ladder effectively.

Jerin likens his experience with DPDK to building a staircase. Each contribution is a stone laid down, providing a foundation for the next. “You prove something, and it’s like one stepping stone. With that, we put another stone, and you can just build on that,” he says. This iterative process of contributing, learning, and growing has been a rewarding and empowering journey for Jerin.

In summary, Jerin’s reflections highlight the impact that contributing to open source projects like DPDK can have on an individual’s career and personal development. It is a testament to the value of open-source communities in fostering growth, collaboration, and innovation.

Learn more about how you can contribute here: https://www.dpdk.org/contribute/

Welcome to the latest installment of our DPDK Developer Spotlight series, where we share the unique journeys and insights of those who contribute to the DPDK community. This edition highlights Ciara Power, a former Technical Lead and Network Software Engineer at Intel. We explore her path into open source development from a math enthusiast at school to a software developer shaping the future of DPDK.

Early Life and Education

A Mathematical Foundation

Ciara’s pathway into the world of computer science and programming was not straightforward. Initially grounded in mathematics, her educational journey began in an environment where technical subjects were rarely emphasized, particularly at an all-girls school in Ireland, that did not prioritize technological advancements. Despite this, Ciara’s inherent love for math led her to pursue it at the university level. 

Discovering Programming

While pursuing her studies at the University of Limerick, Ciara encountered a pivotal moment—a chance to explore programming through an introductory taster course subject. This opportunity resonated with a piece of advice she had received from her mother since childhood: she was destined to be a programmer. 

Transitioning to Computer Science 

A Turning Point

This insight from her mother proved to be more than mere encouragement; it was a recognition of Ciara’s innate abilities and potential for finding joy and fulfillment in a realm she had yet to explore. Indeed, this was a powerful testament to the foresight and intuition that mothers often have about their children’s hidden talents like they say, ‘Mother knows best’’.

After finishing the programming subject course, Ciara reached a turning point. The practical aspects of problem solving appealed to her more than theoretical mathematics. Driven by this preference, and after several challenging weeks, she decided to exit the mathematics course. That September, she took a notable step by starting a computer science course at the Waterford Institute of Technology.

The first year of her computer science studies confirmed her decision; she thrived in this environment, where she could apply logical thinking to tangible problems. The satisfaction of crafting solutions and the joy of creative exploration grounded her. 

Balancing Hobbies and Career

A Blend of Technical and Artistic Talents

Ciara’s enthusiasm for her studies crossed over into other areas of her life, enriching her creative pursuits. From painting and drawing to woodworking and knitting, she embraced a wide array of hobbies, each providing a different outlet for her creative expression. This blend of technical skill and artistic talent became a defining feature of her approach to both work and leisure. 

Ciara’s engagement with her various hobbies provides a crucial balance and unique perspective that enhances her programming work: the ability to visualize the broader picture before delving into details. Just as a painter steps back to view the whole canvas, Ciara applies a similar approach in her coding practices. This allows her to assess a project from various angles. 

Her method of drawing diagrams on a whiteboard is emblematic of her systematic approach to problem-solving, juxtaposed with her ability to incubate ideas and contemplate them from different perspectives. 

This blend of logic and creativity marks her programming style, making her adept at tackling complex problems with innovative solutions. Her ability to think outside the box and not get overly absorbed in minutiae gives her an edge, making her work both methodical and inspired.

Moreover, these pursuits offer Ciara a form of catharsis, a way to decompress and process information subconsciously, which in turn feeds into her professional work. 

Her dual approach—systematic yet open to creative leaps—illustrates how her hobbies not only complement but actively enhance her capabilities as a programmer. This synergy between her personal interests and professional skills exemplifies how diverse experiences can contribute to professional excellence in technology and programming.

Professional Development at Intel

Internship and Real-World Experience

Ciara’s transition from academia to the practical, fast-paced world of software development provided her with an invaluable perspective that she would carry throughout her career. Her internship with the DPDK team at Intel in Shannon, Ireland, was not just about gaining professional experience; it was a deep dive into the collaborative and iterative processes of real-world technology development.

Challenges and Adaption

During her eight-month placement, Ciara engaged directly with complex projects that were far more advanced than her college assignments. This experience was crucial for her; it wasn’t just about coding but also about understanding how large-scale software development projects function, how teams interact, and how products evolve from a concept to a market-ready entity.

One significant challenge was her initial foray into the open source community through DPDK. Coming from an academic background where open source wasn’t a focus, the learning curve was steep. 

She had to quickly adapt to the open source ethos of sharing, collaborative open development, and the transparent critique of code. Learning to navigate and contribute to discussions on mailing lists, where she interacted with developers of varying seniority from around the world, was initially daunting.

As a newcomer, she was initially anxious about how she might be received, given the prevalent challenges women often face in tech environments. However, her experience was overwhelmingly positive. From the onset, she was treated with the same respect and consideration as any seasoned developer. This egalitarian approach was not only affirming but also empowering.

To ingratiate herself within the DPDK community, Ciara adopted a humble approach to learning and contributing. She began by actively listening and understanding the community dynamics before making her contributions. 

Reviewing others’ code and providing constructive feedback became a routine that not only helped her understand the nuances of professional coding but also built her reputation as a thoughtful and capable developer. This proactive engagement helped her transition from an intern at Intel to a respected member of the community.

Projects and Technical Accomplishments

Ciara’s technical journey with DPDK deepened significantly, largely due to the interactions and guidance from OG maintainers Bruce Richardson (Network Software Engineer at Intel Corporation) and Akhil Goyal (Principal Engineer at Marvell Semiconductor). 

Her first major project was contributing to the development of the Telemetry Library V1 a library for retrieving information and statistics about various other DPDK libraries through socket client connections. This not only honed her technical skills but also gave her a solid understanding of handling community feedback for large patchsets, with plenty of discussion around how to implement the library.

In terms of her main contributions, Ciara refactored the unit test framework, adding support for nested testsuites. This included reworking the cryptodev autotests to make use of nested testsuites and ensure all testcases are counted individually in test summaries. This, in turn, improved the testing experience for the user, making it easier to see which testcases are passing/failing [0].

She was also Involved in various improvements for Intel IPsec-mb SW PMDs, including combining PMDs to use common shared code [1], adding multiprocess support [2], and adding Scatter-Gather List support [3] [3.1]. 

Ciara also worked on removing Make build system from DPDK. Meson had been introduced a few releases prior, so it was time to completely remove the old build system, with help from many others. A huge task, it touched on nearly every document, library and driver. This involved significant collaboration in the community, with plenty of reviews and testing taking place by other developers and maintainers. [3].

She Added an API and commandline argument to set the max SIMD bitwidth for EAL. Previously, a number of components in DPDK had optional AVX-512 or other vector paths which can be selected at runtime by each component using its own decision mechanism. This work added a single setting to control what code paths are used. This can be used to enable some non-default code paths e.g. ones using AVX-512, but also to limit the code paths to certain vector widths, or

to scalar code only, which is useful for testing. [4]

Additionally Ciara Improved the cryptodev library Asymmetric session usage, by hiding the structure in an internal header, and using a single mempool rather than using pointers to private data elsewhere [4]. She also Enabled numerous QAT devices and algorithms, including most recently, new GEN3 and GEN5 devices [5].

Bug Fixing

Ciara’s proactive engagement led her to work on fixing various bugs. By utilizing bug detection tools like Address Sanitiser and Coverity, she debugged and resolved a wide range of bugs. This process was not just about resolving immediate issues; it also helped her build a deeper understanding of better programming practices that could be applied in future feature development.  

By contributing significant patches and actively participating in community discussions, Ciara received encouragement instead of the skepticism or condescension often found in other communities. This supportive atmosphere helped her quickly find her footing and gain confidence in her abilities. Her contributions were evaluated solely on their merit, reflecting the DPDK community’s commitment to contributor diversity.

Community Engagement and Recognition

Active participation and support 

Throughout her journey, the open source community, particularly her interactions on the DPDK forums and mailing lists, played a crucial role. Under the guidance of Bruce Richardson, Pablo de Lara Guarch and Akhil Goyal, Ciara not only contributed significantly but also gained insights that helped shape her technical and strategic acumen. 

This exposure allowed her to understand diverse perspectives and collaborative methods essential for open development and open governance across technical communities.

Major Accomplishments

Reflecting on her significant milestones with DPDK, Ciara highlights two major accomplishments. During her internship at Intel, she contributed to the development of the Telemetry Library V1, a library for retrieving information and statistics about various other DPDK libraries through socket client connections. 

Upon returning as a graduate, she was entrusted with the complete rewrite of this library, leading to the development of Telemetry V2. This task demonstrated her progression as a developer, showcasing her ability to significantly improve and build upon her earlier work within a relatively short span of time. 

Her involvement in developing this library was a significant learning journey, filled with complex challenges and intensive problem-solving that required her to engage deeply with the technology and the DPDK community. 

The Telemetry library project stood out not only for its technical demands but also for the collaborative effort it required. Ciara navigated through numerous technical discussions, debates, and feedback loops, integrating community insights to implement and enhance the robustness of the code. 

Another notable highlight was her handling of large patch sets. These weren’t monumental in features but were substantial in scope and impact, involving critical enhancements and fixes that improved DPDK’s functionality and reliability.

Valued advice and the Importance of Code Reviews

One of the most impactful pieces of advice Ciara received from the DPDK community centered on the importance of code reviews. Embracing this practice not only honed her technical skills but also cultivated a mindset geared towards continuous improvement and collaboration. 

This advice underscored the necessity of meticulously reviewing her own code as well as that of others, which facilitated a deeper understanding of various coding approaches and strategies.

Ciara learned that taking a step back to scrutinize every detail of her work from a broader design perspective was crucial. This approach allowed her to explore alternative solutions and methodologies that might not be immediately apparent. 

Engaging in thorough reviews helped her identify potential issues before they escalated, enhancing the overall quality and reliability of her contributions.

Personal Achievement and Awards

Ciara has been recognized multiple times for her contributions at Intel, underscoring her influence and impact within the tech giant. One of her notable accolades includes the Intel Women’s Achievement Award 2021, a testament to her substantial and measurable impact on Intel’s business, profitability, and reputation. 

This award is particularly significant as it celebrates individuals who not only excel in their roles but also drive meaningful change across the organization.

In addition to this, Ciara has received multiple Intel Recognition Awards. These commendations highlight her exceptional development work and her proactive approach to risk management, which has helped prevent bottlenecks in community projects. 

Her efforts around major patch sets during this period were instrumental in her winning these awards. They were not just routine contributions but were pivotal in enhancing Intel’s technological frameworks. 

DPDK Events and the Importance of In-Person Collaboration

Ciara’s experiences at DPDK events provide an illustration of her integration and active participation in the community. After completing her internship at Intel, Ciara attended the DPDK Summit as a participant, not as a speaker. 

This event was particularly significant as it occurred shortly after she returned to college in September, marking her first engagement with the community outside of a professional capacity.

During the summit, Ciara experienced the surreal yet affirming moment of connecting faces to the names of those she had interacted only via the mailing list —individuals who had reviewed her work and those whose code she had studied. 

The recognition she received from other community members, often unexpectedly knowing who she was, played a crucial role in her sense of belonging and validation within the technical community. This recognition, while surprising to her, underscored the impact of her contributions and her growing reputation within the community.

Life Beyond Work 

Balancing life with Nature and Adventure

Ciara’s life outside her technical career is focused on enhancing her well-being and providing a counterbalance to her intensive work in tech. 

A dedicated hiker, she has participated in significant events like a charity hike for Cystic Fibrosis Ireland with colleague Pable De Lara Guarch, where a group of hikers scaled Mt. Kilimanjaro, in Tanzania, (5,895 meters) to watch Siobhan Brady set a new world record performing her Celtic harp at the summit! 

This particular hike, dubbed the “highest harp concert,” is one of life’s highlights she fondly recalls. You can watch the incredible performance here. 

Ciara finds a unique kind of solace close to nature, living just minutes from the coast in the south of Ireland. Her daily walks on the beach, and in the summer, swimming in the ocean are more than just routine; they are a fundamental aspect of her life, crucial for her mental and physical well-being. 

These moments by the sea allow her to unwind, reflect, and regain balance, proving essential for maintaining her productivity and creativity in her professional life.

As she prepares to transition from Intel, with plans to move to Sydney, Australia, Ciara looks forward to exploring new professional landscapes and personal adventures. This move not only signifies a change in her career but also underscores her willingness to embrace new experiences and challenges, whether in tech or in her personal pursuits. 

The future holds unknowns, but Ciara approaches it with enthusiasm and excitement about the possibilities that lie ahead in both her professional and personal life.

To learn more about the benefits of contributing to DPDK read on here. 

Let me first explain why I decided to submit a patch…

Recently, I was working on a research project that utilized the DPDK framework. During the process, I realized that the framework’s driver did not implement all the functionalities specified by the network card. Since one particular functionality, the “launch time feature”, was essential for my work, I spent some time modifying the driver for my project to use this feature.

After that, I decided to invest some time integrating this patch into the DPDK framework, basically for two main reasons. First, I believe this feature is essential for real-time community to use DPDK, and I have seen several discussions online about it, suggesting that its implementation could benefit many others. Secondly, I had never contributed to a large open-source project before and saw this as an opportunity to learn the basic process of submitting patches.

1. Preparation

Before submitting the patch, it’s crucial to understand the project’s development process. DPDK is an open-source project currently managed by Linux Foundation. The development of DPDK happens on the mailing list (like Linux kernel) instead of on GitHub. This means we can’t simply use git commit to submit patches, then followed by a pull request. Instead, patches are submitted via email to maintainers. Therefore, some extra preparatory steps are needed before submission, including:

• Registering and subscribing to the DPDK mailing list
• Configuring email to use git-send-email
• Identifying the maintainers and the subtree of the module you are modifying

Mailing List: The process of registering and subscribing to the mailing list is relatively straightforward and can be done by following the steps in the DPDK official documentation. I won’t repeat that here. I also recommend registering for Patchwork to easily track the code review process. From my experience, it’s best to disable receiving all the emails from the mailing list or set the digest mode to only receive one summary per day, otherwise the daily generated patches will mix with the regular email and overflow the mailbox…

Email Configuration: Setting up the email is also quite simple. I used a Google email, and configured it following this article to link git send-email. I didn’t encounter any issues during the process.

Finding Maintainers: DPDK is a large, modular open-source project, designed for collaborative work. Each module has a designated maintainer, and some even have specific maintenance branches. Therefore, it’s necessary to find the maintainer and the branch of the module you want to modify, and submit the patch to them for integration into the mainline repository. An important point to note is to use the script devtools/get-maintainer.sh in the repository to automatically find the maintainers to Cc, just like this:

git send-email –to dev@dpdk.org –cc-cmd devtools/get-maintainer.sh

The first time, I attempted to find maintainer information in the list provided in the documentation and manually added it to the CC field. However, I later discovered that this information was outdated, which led me to inadvertently send the patch to a previous maintainer…

As for understanding the project’s coding style, I suggest not spending too much time studying the official style guide. This is because you can ensure the consistency of the coding style with the automated review scripts mentioned later.

2. Writing the Patch

The process of writing the patch is essentially modifying the original code to fix bug or add new functionalities, and after formatting it with diff, these modifications become the patch. An important suggestion here is to disable the auto-formatting feature of your IDE. Many projects have unique code formatting styles, and auto-formatting might mess up the format with Tab/Space changes everywhere.

2.1 Testing

Testing is divided into three main parts:

• Compilation and functional testing
• Code style check
• ABI Policy

Compilation and Functional Testing: Since my modifications were minor, I only compiled it on my local machine. The specific process is largely similar to installing DPDK, except the first step involves using meson setup –wipe build to clear the previous build directory. For functional testing, I recommend testing all DPDK built-in apps that might be affected, such as dpdk-testpmd.

Code Style Check: This part can be done following the Section 5.7 Checking the Patches in the DPDK official tutorial. It’s important to note that you need to download checkpatch.pl yourself (You can get the source code by Google searching, just a simple script). After generating codespell-dpdk.txt as instructed, run devtools/checkpatches.sh patch_name.patch in the same directory. The output log shows the results, where both errors and warnings need to be corrected, but some checks may not need changes if they are unreasonable.

ABI Policy: ABI Policy refers to the requirements for variable and function naming. It is recommended to self-check against the official ABI Guideline. But personally, I feel if no new file is created, there shouldn’t be many issues, just compare with the surrounding code to get a sense of the appropriate naming conventions.

2.2 Submitting the Patch

After testing, it is good to generate the patch. Before doing so, it’s recommended to double-check your git username and email, using git config –global user.name & git config –global user.email.

My method of generating patches might not be the best practice. I initially used git add & git commit for a simple commit, then git commit –amend to modify the commit message. Finally, I generated the patch with git format-patch -1 -o ~/patch/. Here -1 indicates the patch-set includes the last few commits, but I only needed to generate one patch.

Before submission, check if the patch contains the Signed-off-by: xxxxx <xxxxxx@xxx> line. Mine wasn’t generated automatically, so I added it manually.

Finally, the patch can be submitted via git send-email, typically –to the mailing list dev@dpdk.org, and –cc to maintainers.

git send-email \

–to dev@dpdk.org \

–cc-cmd devtools/get-maintainer.sh \

./patch_name.patch

Before sending, it is best to first send it to yourself to check if the email format is correct with git send-email –to=[your email] patch_name.patch.

If you have registered for Patchwork, you’ll receive the patch submission notification after a few hours.

3. Code Review

Compared to smaller open-source projects, code review in DPDK is quite stringent, involving both automated reviews from the system and manual reviews from maintainers.

The results of the automated review are received via email within a few hours of submission. Fortunately, despite this being my first patch submission, no errors were detected with beginner luck.

In the subsequent manual review phase, maintainers pose questions about the content of the patch, which feels similar to the rebuttal phase of a research paper submission process. The main issues raised in my case focused on:

• Explaining the functionality of different lines of code
• Justifying the chosen solution
• Providing test results

Responding directly to these questions is usually sufficient. A few minor details to note:

1. When replying, use the –in-reply-to parameter to specify which email you are responding to.

git send-email \

–in-reply-to=xxxxxxxx.namprd11.prod.outlook.com \

–to=xxxx@xxx.com \

–cc=xxxx@xxx.com \

–subject=”RE: [PATCH] net/e1000: support launchtime feature” \

./reply.txt

2. Pay attention to formatting. Indicate references to previous emails by adding >.
3. In the subject, add RE: before the title of the patch. Remember, no matter how many times you reply, there should only be one RE:, not a chain like RE: RE: RE:. 

4. Lessons

Although the process seemed somewhat complicated to me initially, the friendly atmosphere made it smoother. From submission to the final review, it took me over ten days, which included three replies and one code update. Along the way, I encountered some technical issues and uncertainties. However, these were resolved with the help of the maintainers and other developers, who provided guidance and support throughout the process.

The biggest takeaway for me from this experience is that contributing to a large open-source project is not as daunting as it might seem. It’s often the intricate rules and the stereotypes about open-source communities that dissuade people from getting involved. However, I found that the community was welcoming, and the process, while detailed, was manageable when you are willing to spend some time on it.

Although contributing to the open-source community is not my focus, attempting to submit a patch was definitely a valuable experience.

You can follow Chuanyu on Medium here

And get started with DPDK here