THE LINUX FOUNDATION PROJECTS

Contribute Your First DPDK Patch in Five Steps

DPDK is built by a global community of developers. Contributing code is how you make a direct impact on the project. No prior open source experience required, just follow the workflow, write code, and submit.

Get the Code →


Why Contribute Code to DPDK?

Every contribution, from a one-line fix to a major feature, makes the project better for everyone.

Solve Real Problems

DPDK runs in production at companies worldwide. Your code has immediate, measurable impact on real systems.

Learn from Experts

Your patches get reviewed by maintainers who wrote the networking stack. Every review is a learning opportunity.

Build Visibility

Your contributions are public, permanent, and credited. This is work you can point to when it matters.


Five Steps to Your First Patch

DPDK uses a git + email workflow. It’s different from GitHub pull requests, but it’s designed for code review at scale.

Step 1: Get the Source Code

Clone the DPDK repository and build it locally. Make sure the build passes before you start changing anything.

git clone git://dpdk.org/dpdk
cd dpdk
meson build && ninja -C build

Full setup instructions →

Step 2: Make Your Change

Fix a bug, add a feature, improve documentation, whatever you’re working on. Keep the change focused. One logical change per commit.

Step 3: Write a Clear Commit Message

The title should be short and specific (use a prefix like “net/ixgbe:” or “doc:”). The body explains what the problem was and how you fixed it.

git commit --signoff

Step 4: Format and Send the Patch

Use git send-email to send your patch to the mailing list. The script below will automatically CC the right maintainers.

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

Join the dev mailing list

Step 5: Respond to Feedback

Maintainers and other contributors will review your patch and may ask questions or request changes. This is normal. Reply on the mailing list and send an updated version if needed.


What Makes a Good Patch?

These are the patterns that get patches accepted quickly:

Clear Title

Good: “net/ixgbe: fix packet loss under high load”
Bad: “Fix bug” or “Update driver”

Focused Scope

Good: One logical change per commit, easier to review and easier to revert if needed.
Bad: Mixing unrelated changes in a single commit.

Detailed Commit Message

Good: Explains what was broken, why it was broken, and how this fixes it.
Bad: Just the title with no additional context.

Signed-off

Every commit must include a Signed-off-by line. This certifies you wrote it or have the right to contribute it. Use git commit --signoff to add it automatically.


Need More Details?

The full Contributor Guide covers everything: coding standards, ABI policy, testing, advanced git workflows, and more.

Read the Full Contributor Guide →


Ready to Contribute?

The best way to learn is to do it. Clone the code, make a change, and send your first patch.

Get the Code →Join the dev mailing list