1 .. SPDX-License-Identifier: BSD-3-Clause
2 Copyright 2018 The DPDK contributors
6 Contributing Code to DPDK
7 =========================
9 This document outlines the guidelines for submitting code to DPDK.
11 The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
12 Linux kernel guide on submitting patches:
13 `How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
14 The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
17 The DPDK Development Process
18 ----------------------------
20 The DPDK development process has the following features:
22 * The code is hosted in a public git repository.
23 * There is a mailing list where developers submit patches.
24 * There are maintainers for hierarchical components.
25 * Patches are reviewed publicly on the mailing list.
26 * Successfully reviewed patches are merged to the repository.
27 * Patches should be sent to the target repository or sub-tree, see below.
28 * All sub-repositories are merged into main repository for ``-rc1`` and ``-rc2`` versions of the release.
29 * After the ``-rc2`` release all patches should target the main repository.
31 The mailing list for DPDK development is `dev@dpdk.org <https://mails.dpdk.org/archives/dev/>`_.
32 Contributors will need to `register for the mailing list <https://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
33 It is also worth registering for the DPDK `Patchwork <https://patches.dpdk.org/project/dpdk/list/>`_
35 If you are using the GitHub service, you can link your repository to
36 the ``travis-ci.org`` build service. When you push patches to your GitHub
37 repository, the travis service will automatically build your changes.
39 The development process requires some familiarity with the ``git`` version control system.
40 Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
45 The DPDK uses the Open Source BSD-3-Clause license for the core libraries and
46 drivers. The kernel components are GPL-2.0 licensed. DPDK uses single line
47 reference to Unique License Identifiers in source files as defined by the Linux
48 Foundation's `SPDX project <http://spdx.org/>`_.
50 DPDK uses first line of the file to be SPDX tag. In case of *#!* scripts, SPDX
51 tag can be placed in 2nd line of the file.
53 For example, to label a file as subject to the BSD-3-Clause license,
54 the following text would be used:
56 ``SPDX-License-Identifier: BSD-3-Clause``
58 To label a file as dual-licensed with BSD-3-Clause and GPL-2.0 (e.g., for code
59 that is shared between the kernel and userspace), the following text would be
62 ``SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0)``
64 Refer to ``licenses/README`` for more details.
66 Maintainers and Sub-trees
67 -------------------------
69 The DPDK maintenance hierarchy is divided into a main repository ``dpdk`` and sub-repositories ``dpdk-next-*``.
71 There are maintainers for the trees and for components within the tree.
73 Trees and maintainers are listed in the ``MAINTAINERS`` file. For example::
77 M: Some Name <some.name@email.com>
78 T: git://dpdk.org/next/dpdk-next-crypto
81 M: Some One <some.one@email.com>
82 F: drivers/crypto/aesni_gcm/
83 F: doc/guides/cryptodevs/aesni_gcm.rst
87 * ``M`` is a tree or component maintainer.
88 * ``T`` is a repository tree.
89 * ``F`` is a maintained file or directory.
91 Additional details are given in the ``MAINTAINERS`` file.
93 The role of the component maintainers is to:
95 * Review patches for the component or delegate the review.
96 The review should be done, ideally, within 1 week of submission to the mailing list.
97 * Add an ``acked-by`` to patches, or patchsets, that are ready for committing to a tree.
98 * Reply to questions asked about the component.
100 Component maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file.
101 Maintainers should have demonstrated a reasonable level of contributions or reviews to the component area.
102 The maintainer should be confirmed by an ``ack`` from an established contributor.
103 There can be more than one component maintainer if desired.
105 The role of the tree maintainers is to:
107 * Maintain the overall quality of their tree.
108 This can entail additional review, compilation checks or other tests deemed necessary by the maintainer.
109 * Commit patches that have been reviewed by component maintainers and/or other contributors.
110 The tree maintainer should determine if patches have been reviewed sufficiently.
111 * Ensure that patches are reviewed in a timely manner.
112 * Prepare the tree for integration.
113 * Ensure that there is a designated back-up maintainer and coordinate a handover for periods where the
114 tree maintainer can't perform their role.
116 Tree maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file.
117 The proposer should justify the need for a new sub-tree and should have demonstrated a sufficient level of contributions in the area or to a similar area.
118 The maintainer should be confirmed by an ``ack`` from an existing tree maintainer.
119 Disagreements on trees or maintainers can be brought to the Technical Board.
121 The backup maintainer for the main tree should be selected
122 from the existing sub-tree maintainers of the project.
123 The backup maintainer for a sub-tree should be selected from among the component maintainers within that sub-tree.
126 Getting the Source Code
127 -----------------------
129 The source code can be cloned using either of the following:
133 git clone git://dpdk.org/dpdk
134 git clone https://dpdk.org/git/dpdk
136 sub-repositories (`list <https://git.dpdk.org/next>`_)::
138 git clone git://dpdk.org/next/dpdk-next-*
139 git clone https://dpdk.org/git/next/dpdk-next-*
144 Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines and requirements:
146 * Follow the :ref:`coding_style` guidelines.
148 * If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
150 * Initial submission of new PMDs should be prepared against a corresponding repo.
152 * Thus, for example, initial submission of a new network PMD should be
153 prepared against dpdk-next-net repo.
155 * Likewise, initial submission of a new crypto or compression PMD should be
156 prepared against dpdk-next-crypto repo.
158 * For other PMDs and more info, refer to the ``MAINTAINERS`` file.
160 * New external functions should be added to the local ``version.map`` file. See
161 the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
162 guides. New external functions should also be added in alphabetical order.
164 * Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
165 See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
167 * Test the compilation works with different targets, compilers and options, see :ref:`contrib_check_compilation`.
169 * Don't break compilation between commits with forward dependencies in a patchset.
170 Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
172 * Add tests to the ``app/test`` unit test framework where possible.
174 * Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
175 See the :ref:`Documentation Guidelines <doc_guidelines>`.
177 Once the changes have been made you should commit them to your local repo.
179 For small changes, that do not require specific explanations, it is better to keep things together in the
181 Larger changes that require different explanations should be separated into logical patches in a patchset.
182 A good way of thinking about whether a patch should be split is to consider whether the change could be
183 applied without dependencies as a backport.
185 It is better to keep the related documentation changes in the same patch
186 file as the code, rather than one big documentation patch at the end of a
187 patchset. This makes it easier for future maintenance and development of the
190 As a guide to how patches should be structured run ``git log`` on similar files.
193 Commit Messages: Subject Line
194 -----------------------------
196 The first, summary, line of the git commit message becomes the subject line of the patch email.
197 Here are some guidelines for the summary line:
199 * The summary line must capture the area and the impact of the change.
201 * The summary line should be around 50 characters.
203 * The summary line should be lowercase apart from acronyms.
205 * It should be prefixed with the component name (use git log to check existing components).
208 ixgbe: fix offload config option name
210 config: increase max queues per port
212 * Use the imperative of the verb (like instructions to the code base).
214 * Don't add a period/full stop to the subject line or you will end up two in the patch name: ``dpdk_description..patch``.
216 The actual email subject line should be prefixed by ``[PATCH]`` and the version, if greater than v1,
217 for example: ``PATCH v2``.
218 The is generally added by ``git send-email`` or ``git format-patch``, see below.
220 If you are submitting an RFC draft of a feature you can use ``[RFC]`` instead of ``[PATCH]``.
221 An RFC patch doesn't have to be complete.
222 It is intended as a way of getting early feedback.
225 Commit Messages: Body
226 ---------------------
228 Here are some guidelines for the body of a commit message:
230 * The body of the message should describe the issue being fixed or the feature being added.
231 It is important to provide enough information to allow a reviewer to understand the purpose of the patch.
233 * When the change is obvious the body can be blank, apart from the signoff.
235 * The commit message must end with a ``Signed-off-by:`` line which is added using::
237 git commit --signoff # or -s
239 The purpose of the signoff is explained in the
240 `Developer's Certificate of Origin <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1>`_
241 section of the Linux kernel guidelines.
245 All developers must ensure that they have read and understood the
246 Developer's Certificate of Origin section of the documentation prior
247 to applying the signoff and submitting a patch.
249 * The signoff must be a real name and not an alias or nickname.
250 More than one signoff is allowed.
252 * The text of the commit message should be wrapped at 72 characters.
254 * When fixing a regression, it is required to reference the id of the commit
255 which introduced the bug, and put the original author of that commit on CC.
256 You can generate the required lines using the following git alias, which prints
257 the commit SHA and the author of the original code::
259 git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'"
261 The output of ``git fixline <SHA>`` must then be added to the commit message::
263 doc: fix some parameter description
265 Update the docs, fixing description of some parameter.
267 Fixes: abcdefgh1234 ("doc: add some parameter")
268 Cc: author@example.com
270 Signed-off-by: Alex Smith <alex.smith@example.com>
272 * When fixing an error or warning it is useful to add the error message and instructions on how to reproduce it.
274 * Use correct capitalization, punctuation and spelling.
276 In addition to the ``Signed-off-by:`` name the commit messages can also have
277 tags for who reported, suggested, tested and reviewed the patch being
278 posted. Please refer to the `Tested, Acked and Reviewed by`_ section.
280 Patch Fix Related Issues
281 ~~~~~~~~~~~~~~~~~~~~~~~~
283 `Coverity <https://scan.coverity.com/projects/dpdk-data-plane-development-kit>`_
284 is a tool for static code analysis.
285 It is used as a cloud-based service used to scan the DPDK source code,
286 and alert developers of any potential defects in the source code.
287 When fixing an issue found by Coverity, the patch must contain a Coverity issue ID
288 in the body of the commit message. For example::
291 doc: fix some parameter description
293 Update the docs, fixing description of some parameter.
295 Coverity issue: 12345
296 Fixes: abcdefgh1234 ("doc: add some parameter")
297 Cc: author@example.com
299 Signed-off-by: Alex Smith <alex.smith@example.com>
302 `Bugzilla <https://bugs.dpdk.org>`_
303 is a bug- or issue-tracking system.
304 Bug-tracking systems allow individual or groups of developers
305 effectively to keep track of outstanding problems with their product.
306 When fixing an issue raised in Bugzilla, the patch must contain
307 a Bugzilla issue ID in the body of the commit message.
310 doc: fix some parameter description
312 Update the docs, fixing description of some parameter.
315 Fixes: abcdefgh1234 ("doc: add some parameter")
316 Cc: author@example.com
318 Signed-off-by: Alex Smith <alex.smith@example.com>
320 Patch for Stable Releases
321 ~~~~~~~~~~~~~~~~~~~~~~~~~
323 All fix patches to the main branch that are candidates for backporting
324 should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
326 In the commit message body the Cc: stable@dpdk.org should be inserted as follows::
328 doc: fix some parameter description
330 Update the docs, fixing description of some parameter.
332 Fixes: abcdefgh1234 ("doc: add some parameter")
335 Signed-off-by: Alex Smith <alex.smith@example.com>
337 For further information on stable contribution you can go to
338 :doc:`Stable Contribution Guide <stable>`.
343 Sometimes a patch or patchset can depend on another one.
344 To help the maintainers and automation tasks, please document this dependency in commit log or cover letter
345 with the following syntax:
347 ``Depends-on: series-NNNNN ("Title of the series")`` or ``Depends-on: patch-NNNNN ("Title of the patch")``
349 Where ``NNNNN`` is patchwork ID for patch or series::
351 doc: fix some parameter description
353 Update the docs, fixing description of some parameter.
355 Signed-off-by: Alex Smith <alex.smith@example.com>
357 Depends-on: series-10000 ("Title of the series")
362 It is possible to send patches directly from git but for new contributors it is recommended to generate the
363 patches with ``git format-patch`` and then when everything looks okay, and the patches have been checked, to
364 send them with ``git send-email``.
366 Here are some examples of using ``git format-patch`` to generate patches:
368 .. code-block:: console
370 # Generate a patch from the last commit.
373 # Generate a patch from the last 3 commits.
376 # Generate the patches in a directory.
377 git format-patch -3 -o ~/patch/
379 # Add a cover letter to explain a patchset.
380 git format-patch -3 -o ~/patch/ --cover-letter
382 # Add a prefix with a version number.
383 git format-patch -3 -o ~/patch/ -v 2
386 Cover letters are useful for explaining a patchset and help to generate a logical threading to the patches.
387 Smaller notes can be put inline in the patch after the ``---`` separator, for example::
389 Subject: [PATCH] fm10k/base: add FM10420 device ids
391 Add the device ID for Boulder Rapids and Atwood Channel to enable
392 drivers to support those devices.
394 Signed-off-by: Alex Smith <alex.smith@example.com>
399 drivers/net/fm10k/base/fm10k_api.c | 6 ++++++
400 drivers/net/fm10k/base/fm10k_type.h | 6 ++++++
401 2 files changed, 12 insertions(+)
404 Version 2 and later of a patchset should also include a short log of the changes so the reviewer knows what has changed.
405 This can be added to the cover letter or the annotations.
410 * Fixed issued with version.map.
413 * Added i40e support.
414 * Renamed ethdev functions from rte_eth_ieee15888_*() to rte_eth_timesync_*()
415 since 802.1AS can be supported through the same interfaces.
418 .. _contrib_checkpatch:
423 Patches should be checked for formatting and syntax issues using the ``checkpatches.sh`` script in the ``devtools``
424 directory of the DPDK repo.
425 This uses the Linux kernel development tool ``checkpatch.pl`` which can be obtained by cloning, and periodically,
426 updating the Linux kernel sources.
428 The path to the original Linux script must be set in the environment variable ``DPDK_CHECKPATCH_PATH``.
430 Spell checking of commonly misspelled words
431 can be enabled by downloading the codespell dictionary::
433 https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt
435 The path to the downloaded ``dictionary.txt`` must be set
436 in the environment variable ``DPDK_CHECKPATCH_CODESPELL``.
438 Environment variables required by the development tools,
439 are loaded from the following files, in order of preference::
442 ~/.config/dpdk/devel.config
443 /etc/dpdk/devel.config.
445 Once the environment variable is set, the script can be run as follows::
447 devtools/checkpatches.sh ~/patch/
449 The script usage is::
451 checkpatches.sh [-h] [-q] [-v] [-nX|-r range|patch1 [patch2] ...]
453 Then the git logs should be checked using the ``check-git-log.sh`` script.
455 The script usage is::
457 check-git-log.sh [-h] [-nX|-r range]
459 For both of the above scripts, the -n option is used to specify a number of commits from HEAD,
460 and the -r option allows the user specify a ``git log`` range.
462 .. _contrib_check_compilation:
470 Compilation of patches and changes should be tested using the ``test-build.sh`` script in the ``devtools``
471 directory of the DPDK repo::
473 devtools/test-build.sh x86_64-native-linux-gcc+next+shared
475 The script usage is::
477 test-build.sh [-h] [-jX] [-s] [config1 [config2] ...]]
481 * ``-h``: help, usage.
482 * ``-jX``: use X parallel jobs in "make".
483 * ``-s``: short test with only first config and without examples/doc.
484 * ``config``: default config name plus config switches delimited with a ``+`` sign.
486 Examples of configs are::
488 x86_64-native-linux-gcc
489 x86_64-native-linux-gcc+next+shared
490 x86_64-native-linux-clang+shared
492 The builds can be modified via the following environmental variables:
494 * ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2)
495 * ``DPDK_BUILD_TEST_DIR``
496 * ``DPDK_DEP_CFLAGS``
497 * ``DPDK_DEP_LDFLAGS``
498 * ``DPDK_DEP_PCAP`` (y/[n])
499 * ``DPDK_NOTIFY`` (notify-send)
501 These can be set from the command line or in the config files shown above in the :ref:`contrib_checkpatch`.
503 The recommended configurations and options to test compilation prior to submitting patches are::
505 x86_64-native-linux-gcc+shared+next
506 x86_64-native-linux-clang+shared
507 i686-native-linux-gcc
509 export DPDK_DEP_ZLIB=y
510 export DPDK_DEP_PCAP=y
511 export DPDK_DEP_SSL=y
516 Compilation of patches is to be tested with ``devtools/test-meson-builds.sh`` script.
518 The script internally checks for dependencies, then builds for several
519 combinations of compilation configuration.
520 By default, each build will be put in a subfolder of the current working directory.
521 However, if it is preferred to place the builds in a different location,
522 the environment variable ``DPDK_BUILD_TEST_DIR`` can be set to that desired location.
523 For example, setting ``DPDK_BUILD_TEST_DIR=__builds`` will put all builds
524 in a single subfolder called "__builds" created in the current directory.
525 Setting ``DPDK_BUILD_TEST_DIR`` to an absolute directory path e.g. ``/tmp`` is also supported.
528 .. _integrated_abi_check:
530 Checking ABI compatibility
531 --------------------------
533 By default, ABI compatibility checks are disabled.
535 To enable them, a reference version must be selected via the environment
536 variable ``DPDK_ABI_REF_VERSION``.
538 The ``devtools/test-build.sh`` and ``devtools/test-meson-builds.sh`` scripts
539 then build this reference version in a temporary directory and store the
540 results in a subfolder of the current working directory.
541 The environment variable ``DPDK_ABI_REF_DIR`` can be set so that the results go
542 to a different location.
548 Patches should be sent to the mailing list using ``git send-email``.
549 You can configure an external SMTP with something like the following::
552 smtpuser = name@domain.com
553 smtpserver = smtp.domain.com
557 See the `Git send-email <https://git-scm.com/docs/git-send-email>`_ documentation for more details.
559 The patches should be sent to ``dev@dpdk.org``.
560 If the patches are a change to existing files then you should send them TO the maintainer(s) and CC ``dev@dpdk.org``.
561 The appropriate maintainer can be found in the ``MAINTAINERS`` file::
563 git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch
565 Script ``get-maintainer.sh`` can be used to select maintainers automatically::
567 git send-email --to-cmd ./devtools/get-maintainer.sh --cc dev@dpdk.org 000*.patch
569 New additions can be sent without a maintainer::
571 git send-email --to dev@dpdk.org 000*.patch
573 You can test the emails by sending it to yourself or with the ``--dry-run`` option.
575 If the patch is in relation to a previous email thread you can add it to the same thread using the Message ID::
577 git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch
579 The Message ID can be found in the raw text of emails or at the top of each Patchwork patch,
580 `for example <https://patches.dpdk.org/patch/7646/>`_.
581 Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series.
583 Once submitted your patches will appear on the mailing list and in Patchwork.
585 Experienced committers may send patches directly with ``git send-email`` without the ``git format-patch`` step.
586 The options ``--annotate`` and ``confirm = always`` are recommended for checking patches before sending.
589 Backporting patches for Stable Releases
590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
592 Sometimes a maintainer or contributor wishes, or can be asked, to send a patch
593 for a stable release rather than mainline.
594 In this case the patch(es) should be sent to ``stable@dpdk.org``,
595 not to ``dev@dpdk.org``.
597 Given that there are multiple stable releases being maintained at the same time,
598 please specify exactly which branch(es) the patch is for
599 using ``git send-email --subject-prefix='PATCH 16.11' ...``
600 and also optionally in the cover letter or in the annotation.
606 Patches are reviewed by the community, relying on the experience and
607 collaboration of the members to double-check each other's work. There are a
608 number of ways to indicate that you have checked a patch on the mailing list.
611 Tested, Acked and Reviewed by
612 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
614 To indicate that you have interacted with a patch on the mailing list you
615 should respond to the patch in an email with one of the following tags:
623 The tag should be on a separate line as follows::
625 tag-here: Name Surname <email@address.com>
627 Each of these tags has a specific meaning. In general, the DPDK community
628 follows the kernel usage of the tags. A short summary of the meanings of each
629 tag is given here for reference:
631 .. _statement: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight
633 ``Reviewed-by:`` is a strong statement_ that the patch is an appropriate state
634 for merging without any remaining serious technical issues. Reviews from
635 community members who are known to understand the subject area and to perform
636 thorough reviews will increase the likelihood of the patch getting merged.
638 ``Acked-by:`` is a record that the person named was not directly involved in
639 the preparation of the patch but wishes to signify and record their acceptance
642 ``Tested-by:`` indicates that the patch has been successfully tested (in some
643 environment) by the person named.
645 ``Reported-by:`` is used to acknowledge person who found or reported the bug.
647 ``Suggested-by:`` indicates that the patch idea was suggested by the named
652 Steps to getting your patch merged
653 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
655 The more work you put into the previous steps the easier it will be to get a
656 patch accepted. The general cycle for patch review and acceptance is:
660 #. Check the automatic test reports in the coming hours.
662 #. Wait for review comments. While you are waiting review some other patches.
664 #. Fix the review comments and submit a ``v n+1`` patchset::
666 git format-patch -3 -v 2
668 #. Update Patchwork to mark your previous patches as "Superseded".
670 #. If the patch is deemed suitable for merging by the relevant maintainer(s) or other developers they will ``ack``
671 the patch with an email that includes something like::
673 Acked-by: Alex Smith <alex.smith@example.com>
675 **Note**: When acking patches please remove as much of the text of the patch email as possible.
676 It is generally best to delete everything after the ``Signed-off-by:`` line.
678 #. Having the patch ``Reviewed-by:`` and/or ``Tested-by:`` will also help the patch to be accepted.
680 #. If the patch isn't deemed suitable based on being out of scope or conflicting with existing functionality
681 it may receive a ``nack``.
682 In this case you will need to make a more convincing technical argument in favor of your patches.
684 #. In addition a patch will not be accepted if it doesn't address comments from a previous version with fixes or
687 #. It is the responsibility of a maintainer to ensure that patches are reviewed and to provide an ``ack`` or
688 ``nack`` of those patches as appropriate.
690 #. Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a further
691 two weeks. After that time, the patch should be merged into the relevant git tree for the next release.
692 Additional notes and restrictions:
694 * Patches should be acked by a maintainer at least two days before the release merge
695 deadline, in order to make that release.
696 * For patches acked with less than two weeks to go to the merge deadline, all additional
697 comments should be made no later than two days before the merge deadline.
698 * After the appropriate time for additional feedback has passed, if the patch has not yet
699 been merged to the relevant tree by the committer, it should be treated as though it had,
700 in that any additional changes needed to it must be addressed by a follow-on patch, rather
701 than rework of the original.
702 * Trivial patches may be merged sooner than described above at the tree committer's