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.
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. Mixing unrelated changes in a single commit makes review harder and makes it harder to revert if something goes wrong.
Step 3: Write a Clear Commit Message
The title should be short and specific — use a subsystem prefix like net/ixgbe: or doc:. The body explains what the problem was and how you fixed it. Every commit must include a Signed-off-by line — this certifies you wrote it or have the right to contribute it.
git commit --signoffGood title: net/ixgbe: fix packet loss under high load Bad title: Fix bug or Update driver
Good body: explains what was broken, why it was broken, and how this fixes it. Bad body: just the title with no additional context.
Step 4: Check Your Patch Before Sending
Run the DPDK style checker before you send anything. Style failures are the most common reason first patches get returned — catching them yourself saves a round trip.
devtools/checkpatches.shCheck for:
- Does the commit message explain why, not just what?
- Is there a
Signed-off-byline? - Is the change focused — one logical change per commit?
Step 5: Format and Send the Patch
Use git send-email to send your patch to the mailing list. The command below formats the patch and automatically CCs the right maintainers based on the files you changed.
git send-email -1 --to dev@dpdk.org --cc-cmd devtools/get-maintainer.shIf you’re sending a series of 3 or more patches, a cover letter is required:
git send-email --cover-letter --to dev@dpdk.org --cc-cmd devtools/get-maintainer.shIf you send a revised version after feedback, increment the version number and include a changelog below the --- line so reviewers can see what changed:
git send-email -1 --to dev@dpdk.org --subject-prefix="PATCH v2"→ Join the dev mailing list
Step 6: Respond to Feedback
Maintainers and other contributors will review your patch and may ask questions or request changes. This is normal and expected — even experienced contributors go through multiple rounds. Reply on the mailing list, address the feedback, and send an updated version with an incremented version number 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. Use git commit --signoff to add it automatically.
Passes checkpatches.sh Run devtools/checkpatches.sh before sending. If it fails, fix it before you submit.
New to the Code Base?
The full Contributor Guide covers everything: coding standards, ABI policy, testing, advanced git workflows, and more.
Ready to Contribute?
The best way to learn is to do it. Clone the code, make a change, and send your first patch.
