5. Contributing Code to DPDK

This document outlines the guidelines for submitting code to DPDK.

The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the Linux kernel guide on submitting patches: How to Get Your Change Into the Linux Kernel. The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.

5.1. The DPDK Development Process

The DPDK development process has the following features:

The code is hosted in a public git repository.
There is a mailing list where developers submit patches.
There are maintainers for hierarchical components.
Patches are reviewed publicly on the mailing list.
Successfully reviewed patches are merged to the repository.
Patches should be sent to the target repository or sub-tree, see below.
All sub-repositories are merged into main repository for -rc1 and -rc2 versions of the release.
After the -rc2 release all patches should target the main repository.

The mailing list for DPDK development is dev@dpdk.org. Contributors will need to register for the mailing list in order to submit patches. It is also worth registering for the DPDK Patchwork

The development process requires some familiarity with the git version control system. Refer to the Pro Git Book for further information.

5.2. Source License

The DPDK uses the Open Source BSD-3-Clause license for the core libraries and drivers. The kernel components are GPL-2.0 licensed. DPDK uses single line reference to Unique License Identifiers in source files as defined by the Linux Foundation’s SPDX project.

DPDK uses first line of the file to be SPDX tag. In case of #! scripts, SPDX tag can be placed in 2nd line of the file.

For example, to label a file as subject to the BSD-3-Clause license, the following text would be used:

SPDX-License-Identifier: BSD-3-Clause

To label a file as dual-licensed with BSD-3-Clause and GPL-2.0 (e.g., for code that is shared between the kernel and userspace), the following text would be used:

SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0)

Refer to licenses/README for more details.

5.3. Maintainers and Sub-trees

The DPDK maintenance hierarchy is divided into a main repository dpdk and sub-repositories dpdk-next-*.

There are maintainers for the trees and for components within the tree.

Trees and maintainers are listed in the MAINTAINERS file. For example:

Crypto Drivers
--------------
M: Some Name <some.name@email.com>
B: Another Name <another.name@email.com>
T: git://dpdk.org/next/dpdk-next-crypto

Intel AES-NI GCM PMD
M: Some One <some.one@email.com>
F: drivers/crypto/aesni_gcm/
F: doc/guides/cryptodevs/aesni_gcm.rst

Where:

M is a tree or component maintainer.
B is a tree backup maintainer.
T is a repository tree.
F is a maintained file or directory.

Additional details are given in the MAINTAINERS file.

The role of the component maintainers is to:

Review patches for the component or delegate the review. The review should be done, ideally, within 1 week of submission to the mailing list.
Add an acked-by to patches, or patchsets, that are ready for committing to a tree.
Reply to questions asked about the component.

Component maintainers can be added or removed by submitting a patch to the MAINTAINERS file. Maintainers should have demonstrated a reasonable level of contributions or reviews to the component area. The maintainer should be confirmed by an ack from an established contributor. There can be more than one component maintainer if desired.

The role of the tree maintainers is to:

Maintain the overall quality of their tree. This can entail additional review, compilation checks or other tests deemed necessary by the maintainer.
Commit patches that have been reviewed by component maintainers and/or other contributors. The tree maintainer should determine if patches have been reviewed sufficiently.
Ensure that patches are reviewed in a timely manner.
Prepare the tree for integration.
Ensure that there is a designated back-up maintainer and coordinate a handover for periods where the tree maintainer can’t perform their role.

Tree maintainers can be added or removed by submitting a patch to the MAINTAINERS file. 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. The maintainer should be confirmed by an ack from an existing tree maintainer. Disagreements on trees or maintainers can be brought to the Technical Board.

The backup maintainer for the master tree should be selected from the existing sub-tree maintainers from the project. The backup maintainer for a sub-tree should be selected from among the component maintainers within that sub-tree.

5.4. Getting the Source Code

The source code can be cloned using either of the following:

main repository:

git clone git://dpdk.org/dpdk
git clone http://dpdk.org/git/dpdk

sub-repositories (list):

git clone git://dpdk.org/next/dpdk-next-*
git clone http://dpdk.org/git/next/dpdk-next-*

5.5. Make your Changes

Make your planned changes in the cloned dpdk repo. Here are some guidelines and requirements:

Follow the DPDK Coding Style guidelines.
If you add new files or directories you should add your name to the MAINTAINERS file.
New external functions should be added to the local version.map file. See the Guidelines for ABI policy and versioning. New external functions should also be added in alphabetical order.
Important changes will require an addition to the release notes in doc/guides/rel_notes/. See the Release Notes section of the Documentation Guidelines for details.
Test the compilation works with different targets, compilers and options, see Checking Compilation.
Don’t break compilation between commits with forward dependencies in a patchset. Each commit should compile on its own to allow for git bisect and continuous integration testing.
Add tests to the app/test unit test framework where possible.
Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format. See the Documentation Guidelines.

Once the changes have been made you should commit them to your local repo.

For small changes, that do not require specific explanations, it is better to keep things together in the same patch. Larger changes that require different explanations should be separated into logical patches in a patchset. A good way of thinking about whether a patch should be split is to consider whether the change could be applied without dependencies as a backport.

As a guide to how patches should be structured run git log on similar files.

5.6. Commit Messages: Subject Line

The first, summary, line of the git commit message becomes the subject line of the patch email. Here are some guidelines for the summary line:

The summary line must capture the area and the impact of the change.
The summary line should be around 50 characters.
The summary line should be lowercase apart from acronyms.
It should be prefixed with the component name (use git log to check existing components). For example:
```
ixgbe: fix offload config option name

config: increase max queues per port
```
Use the imperative of the verb (like instructions to the code base).
Don’t add a period/full stop to the subject line or you will end up two in the patch name: dpdk_description..patch.

The actual email subject line should be prefixed by [PATCH] and the version, if greater than v1, for example: PATCH v2. The is generally added by git send-email or git format-patch, see below.

If you are submitting an RFC draft of a feature you can use [RFC] instead of [PATCH]. An RFC patch doesn’t have to be complete. It is intended as a way of getting early feedback.

5.7. Commit Messages: Body

Here are some guidelines for the body of a commit message:

The body of the message should describe the issue being fixed or the feature being added. It is important to provide enough information to allow a reviewer to understand the purpose of the patch.
When the change is obvious the body can be blank, apart from the signoff.
The commit message must end with a Signed-off-by: line which is added using:
```
git commit --signoff # or -s
```
The purpose of the signoff is explained in the Developer’s Certificate of Origin section of the Linux kernel guidelines.

Note

All developers must ensure that they have read and understood the Developer’s Certificate of Origin section of the documentation prior to applying the signoff and submitting a patch.
The signoff must be a real name and not an alias or nickname. More than one signoff is allowed.
The text of the commit message should be wrapped at 72 characters.
When fixing a regression, it is required to reference the id of the commit which introduced the bug, and put the original author of that commit on CC. You can generate the required lines using the following git alias, which prints the commit SHA and the author of the original code:
```
git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'"
```
The output of git fixline <SHA> must then be added to the commit message:
```
doc: fix some parameter description

Update the docs, fixing description of some parameter.

Fixes: abcdefgh1234 ("doc: add some parameter")
Cc: author@example.com

Signed-off-by: Alex Smith <alex.smith@example.com>
```
When fixing an error or warning it is useful to add the error message and instructions on how to reproduce it.
Use correct capitalization, punctuation and spelling.

In addition to the Signed-off-by: name the commit messages can also have tags for who reported, suggested, tested and reviewed the patch being posted. Please refer to the Tested, Acked and Reviewed by section.

5.8. Creating Patches

It is possible to send patches directly from git but for new contributors it is recommended to generate the patches with git format-patch and then when everything looks okay, and the patches have been checked, to send them with git send-email.

Here are some examples of using git format-patch to generate patches:

# Generate a patch from the last commit.
git format-patch -1

# Generate a patch from the last 3 commits.
git format-patch -3

# Generate the patches in a directory.
git format-patch -3 -o ~/patch/

# Add a cover letter to explain a patchset.
git format-patch -3 -o ~/patch/ --cover-letter

# Add a prefix with a version number.
git format-patch -3 -o ~/patch/ -v 2

Cover letters are useful for explaining a patchset and help to generate a logical threading to the patches. Smaller notes can be put inline in the patch after the --- separator, for example:

Subject: [PATCH] fm10k/base: add FM10420 device ids

Add the device ID for Boulder Rapids and Atwood Channel to enable
drivers to support those devices.

Signed-off-by: Alex Smith <alex.smith@example.com>
---

ADD NOTES HERE.

 drivers/net/fm10k/base/fm10k_api.c  | 6 ++++++
 drivers/net/fm10k/base/fm10k_type.h | 6 ++++++
 2 files changed, 12 insertions(+)
...

Version 2 and later of a patchset should also include a short log of the changes so the reviewer knows what has changed. This can be added to the cover letter or the annotations. For example:

---
v3:
* Fixed issued with version.map.

v2:
* Added i40e support.
* Renamed ethdev functions from rte_eth_ieee15888_*() to rte_eth_timesync_*()
  since 802.1AS can be supported through the same interfaces.

5.9. Checking the Patches

Patches should be checked for formatting and syntax issues using the checkpatches.sh script in the devtools directory of the DPDK repo. This uses the Linux kernel development tool checkpatch.pl which can be obtained by cloning, and periodically, updating the Linux kernel sources.

The path to the original Linux script must be set in the environment variable DPDK_CHECKPATCH_PATH. This, and any other configuration variables required by the development tools, are loaded from the following files, in order of preference:

.develconfig
~/.config/dpdk/devel.config
/etc/dpdk/devel.config.

Once the environment variable the script can be run as follows:

devtools/checkpatches.sh ~/patch/

The script usage is:

checkpatches.sh [-h] [-q] [-v] [patch1 [patch2] ...]]"

Where:

-h: help, usage.
-q: quiet. Don’t output anything for files without issues.
-v: verbose.
patchX: path to one or more patches.

Then the git logs should be checked using the check-git-log.sh script.

The script usage is:

check-git-log.sh [range]

Where the range is a git log option.

5.10. Checking Compilation

Compilation of patches and changes should be tested using the test-build.sh script in the devtools directory of the DPDK repo:

devtools/test-build.sh x86_64-native-linuxapp-gcc+next+shared

The script usage is:

test-build.sh [-h] [-jX] [-s] [config1 [config2] ...]]

Where:

-h: help, usage.
-jX: use X parallel jobs in “make”.
-s: short test with only first config and without examples/doc.
config: default config name plus config switches delimited with a + sign.

Examples of configs are:

x86_64-native-linuxapp-gcc
x86_64-native-linuxapp-gcc+next+shared
x86_64-native-linuxapp-clang+shared

The builds can be modified via the following environmental variables:

DPDK_BUILD_TEST_CONFIGS (target1+option1+option2 target2)
DPDK_DEP_CFLAGS
DPDK_DEP_LDFLAGS
DPDK_DEP_PCAP (y/[n])
DPDK_NOTIFY (notify-send)

These can be set from the command line or in the config files shown above in the Checking the Patches.

The recommended configurations and options to test compilation prior to submitting patches are:

x86_64-native-linuxapp-gcc+shared+next
x86_64-native-linuxapp-clang+shared
i686-native-linuxapp-gcc

export DPDK_DEP_ZLIB=y
export DPDK_DEP_PCAP=y
export DPDK_DEP_SSL=y

5.11. Sending Patches

Patches should be sent to the mailing list using git send-email. You can configure an external SMTP with something like the following:

[sendemail]
    smtpuser = name@domain.com
    smtpserver = smtp.domain.com
    smtpserverport = 465
    smtpencryption = ssl

See the Git send-email documentation for more details.

The patches should be sent to dev@dpdk.org. If the patches are a change to existing files then you should send them TO the maintainer(s) and CC dev@dpdk.org. The appropriate maintainer can be found in the MAINTAINERS file:

git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch

Script get-maintainer.sh can be used to select maintainers automatically:

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

New additions can be sent without a maintainer:

git send-email --to dev@dpdk.org 000*.patch

You can test the emails by sending it to yourself or with the --dry-run option.

If the patch is in relation to a previous email thread you can add it to the same thread using the Message ID:

git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch

The Message ID can be found in the raw text of emails or at the top of each Patchwork patch, for example. Shallow threading (--thread --no-chain-reply-to) is preferred for a patch series.

Once submitted your patches will appear on the mailing list and in Patchwork.

Experienced committers may send patches directly with git send-email without the git format-patch step. The options --annotate and confirm = always are recommended for checking patches before sending.

5.12. The Review Process

Patches are reviewed by the community, relying on the experience and collaboration of the members to double-check each other’s work. There are a number of ways to indicate that you have checked a patch on the mailing list.

5.12.1. Tested, Acked and Reviewed by

To indicate that you have interacted with a patch on the mailing list you should respond to the patch in an email with one of the following tags:

Reviewed-by:

Acked-by:

Tested-by:

Reported-by:

Suggested-by:

The tag should be on a separate line as follows:

tag-here: Name Surname <email@address.com>

Each of these tags has a specific meaning. In general, the DPDK community follows the kernel usage of the tags. A short summary of the meanings of each tag is given here for reference:

Reviewed-by: is a strong statement that the patch is an appropriate state for merging without any remaining serious technical issues. Reviews from community members who are known to understand the subject area and to perform thorough reviews will increase the likelihood of the patch getting merged.

Acked-by: is a record that the person named was not directly involved in the preparation of the patch but wishes to signify and record their acceptance and approval of it.

Tested-by: indicates that the patch has been successfully tested (in some environment) by the person named.

Reported-by: is used to acknowledge person who found or reported the bug.

Suggested-by: indicates that the patch idea was suggested by the named person.

5.12.2. Steps to getting your patch merged

The more work you put into the previous steps the easier it will be to get a patch accepted. The general cycle for patch review and acceptance is:

Submit the patch.
Check the automatic test reports in the coming hours.
Wait for review comments. While you are waiting review some other patches.
Fix the review comments and submit a v n+1 patchset:
```
git format-patch -3 -v 2
```
Update Patchwork to mark your previous patches as “Superseded”.
If the patch is deemed suitable for merging by the relevant maintainer(s) or other developers they will ack the patch with an email that includes something like:
```
Acked-by: Alex Smith <alex.smith@example.com>
```
Note: When acking patches please remove as much of the text of the patch email as possible. It is generally best to delete everything after the Signed-off-by: line.
Having the patch Reviewed-by: and/or Tested-by: will also help the patch to be accepted.
If the patch isn’t deemed suitable based on being out of scope or conflicting with existing functionality it may receive a nack. In this case you will need to make a more convincing technical argument in favor of your patches.
In addition a patch will not be accepted if it doesn’t address comments from a previous version with fixes or valid arguments.
It is the responsibility of a maintainer to ensure that patches are reviewed and to provide an ack or nack of those patches as appropriate.
Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a further two weeks. After that time, the patch should be merged into the relevant git tree for the next release. Additional notes and restrictions:
- Patches should be acked by a maintainer at least two days before the release merge deadline, in order to make that release.
- For patches acked with less than two weeks to go to the merge deadline, all additional comments should be made no later than two days before the merge deadline.
- After the appropriate time for additional feedback has passed, if the patch has not yet been merged to the relevant tree by the committer, it should be treated as though it had, in that any additional changes needed to it must be addressed by a follow-on patch, rather than rework of the original.
- Trivial patches may be merged sooner than described above at the tree committer’s discretion.

5.13. DPDK Maintainers

The following are the DPDK maintainers as listed in the MAINTAINERS file in the DPDK root directory.

The intention of this file is to provide a set of names that we can rely on
for helping in patch reviews and questions.
These names are additional recipients for emails sent to dev@dpdk.org.
Please avoid private emails.

Descriptions of section entries:

	M: Maintainer's Full Name <address@domain>
	T: Git tree location.
	F: Files and directories with wildcard patterns.
	   A trailing slash includes all files and subdirectory files.
	   A wildcard includes all files but not subdirectories.
	   One pattern per line. Multiple F: lines acceptable.
	X: Files and directories exclusion, same rules as F:
	K: Keyword regex pattern to match content.
	   One regex pattern per line. Multiple K: lines acceptable.


General Project Administration
------------------------------

Main Branch
M: Thomas Monjalon <thomas@monjalon.net>
M: Ferruh Yigit <ferruh.yigit@intel.com>
T: git://dpdk.org/dpdk

Stable Branches
M: Yuanhan Liu <yliu@fridaylinux.org>
M: Luca Boccassi <bluca@debian.org>
T: git://dpdk.org/dpdk-stable

Security Issues
M: maintainers@dpdk.org

Documentation (with overlaps)
M: John McNamara <john.mcnamara@intel.com>
M: Marko Kovacevic <marko.kovacevic@intel.com>
F: README
F: doc/

Developers and Maintainers Tools
M: Thomas Monjalon <thomas@monjalon.net>
F: MAINTAINERS
F: devtools/check-dup-includes.sh
F: devtools/check-maintainers.sh
F: devtools/check-git-log.sh
F: devtools/check-includes.sh
F: devtools/checkpatches.sh
F: devtools/get-maintainer.sh
F: devtools/git-log-fixes.sh
F: devtools/load-devel-config
F: devtools/test-build.sh
F: license/


Build System
------------
M: Thomas Monjalon <thomas@monjalon.net>
F: GNUmakefile
F: Makefile
F: config/
F: mk/
F: pkg/
F: buildtools/auto-config-h.sh
F: buildtools/gen-build-mk.sh
F: buildtools/gen-config-h.sh
F: buildtools/relpath.sh
F: doc/build-sdk-quick.txt
F: doc/guides/prog_guide/build_app.rst
F: doc/guides/prog_guide/dev_kit_*
F: doc/guides/prog_guide/ext_app_lib_make_help.rst

Meson build
M: Bruce Richardson <bruce.richardson@intel.com>
F: meson.build
F: lib/librte_eal/bsdapp/BSDmakefile.meson
F: meson_options.txt
F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh

ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: lib/librte_compat/
F: doc/guides/rel_notes/deprecation.rst
F: devtools/validate-abi.sh
F: buildtools/check-experimental-syms.sh

Driver information
M: Neil Horman <nhorman@tuxdriver.com>
F: buildtools/pmdinfogen/
F: usertools/dpdk-pmdinfo.py
F: doc/guides/tools/pmdinfo.rst


Environment Abstraction Layer
-----------------------------

EAL API and common code
F: lib/librte_eal/common/*
F: lib/librte_eal/common/include/*
F: lib/librte_eal/common/include/generic/
F: lib/librte_eal/rte_eal_version.map
F: doc/guides/prog_guide/env_abstraction_layer.rst
F: test/test/test_alarm.c
F: test/test/test_atomic.c
F: test/test/test_barrier.c
F: test/test/test_byteorder.c
F: test/test/test_common.c
F: test/test/test_cpuflags.c
F: test/test/test_cycles.c
F: test/test/test_debug.c
F: test/test/test_devargs.c
F: test/test/test_eal*
F: test/test/test_errno.c
F: test/test/test_interrupts.c
F: test/test/test_logs.c
F: test/test/test_memcpy*
F: test/test/test_per_lcore.c
F: test/test/test_prefetch.c
F: test/test/test_reciprocal_division*
F: test/test/test_rwlock.c
F: test/test/test_spinlock.c
F: test/test/test_string_fns.c
F: test/test/test_tailq.c
F: test/test/test_version.c

Memory Allocation
M: Anatoly Burakov <anatoly.burakov@intel.com>
F: lib/librte_eal/common/include/rte_mem*
F: lib/librte_eal/common/include/rte_malloc.h
F: lib/librte_eal/common/*malloc*
F: lib/librte_eal/common/eal_common_mem*
F: lib/librte_eal/common/eal_hugepages.h
F: doc/guides/prog_guide/env_abstraction_layer.rst
F: test/test/test_func_reentrancy.c
F: test/test/test_malloc.c
F: test/test/test_memory.c
F: test/test/test_memzone.c

Keep alive
M: Remy Horton <remy.horton@intel.com>
F: lib/librte_eal/common/include/rte_keepalive.h
F: lib/librte_eal/common/rte_keepalive.c
F: examples/l2fwd-keepalive/
F: doc/guides/sample_app_ug/keep_alive.rst

Secondary process
M: Anatoly Burakov <anatoly.burakov@intel.com>
K: RTE_PROC_
F: doc/guides/prog_guide/multi_proc_support.rst
F: test/test/test_mp_secondary.c
F: examples/multi_process/
F: doc/guides/sample_app_ug/multi_process.rst

Service Cores - EXPERIMENTAL
M: Harry van Haaren <harry.van.haaren@intel.com>
F: lib/librte_eal/common/include/rte_service.h
F: lib/librte_eal/common/include/rte_service_component.h
F: lib/librte_eal/common/rte_service.c
F: doc/guides/prog_guide/service_cores.rst
F: test/test/test_service_cores.c

Bitmap
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: lib/librte_eal/common/include/rte_bitmap.h
F: test/test/test_bitmap.c

ARM v7
M: Jan Viktorin <viktorin@rehivetech.com>
M: Jianbo Liu <jianbo.liu@arm.com>
F: lib/librte_eal/common/arch/arm/
F: lib/librte_eal/common/include/arch/arm/

ARM v8
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
M: Jianbo Liu <jianbo.liu@arm.com>
F: lib/librte_eal/common/include/arch/arm/*_64.h
F: lib/librte_net/net_crc_neon.h
F: lib/librte_acl/acl_run_neon.*
F: lib/librte_lpm/rte_lpm_neon.h
F: lib/librte_hash/rte*_arm64.h
F: lib/librte_efd/rte*_arm64.h
F: lib/librte_table/rte*_arm64.h
F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
F: drivers/net/i40e/i40e_rxtx_vec_neon.c
F: drivers/net/virtio/virtio_rxtx_simple_neon.c

IBM POWER
M: Chao Zhu <chaozhu@linux.vnet.ibm.com>
F: lib/librte_eal/common/arch/ppc_64/
F: lib/librte_eal/common/include/arch/ppc_64/
F: drivers/net/i40e/i40e_rxtx_vec_altivec.c
F: examples/l3fwd/*altivec.h

Intel x86
M: Bruce Richardson <bruce.richardson@intel.com>
M: Konstantin Ananyev <konstantin.ananyev@intel.com>
F: lib/librte_eal/common/arch/x86/
F: lib/librte_eal/common/include/arch/x86/

Linux EAL (with overlaps)
F: lib/librte_eal/linuxapp/Makefile
F: lib/librte_eal/linuxapp/eal/
F: doc/guides/linux_gsg/

Linux UIO
M: Ferruh Yigit <ferruh.yigit@intel.com>
F: lib/librte_eal/linuxapp/igb_uio/
F: drivers/bus/pci/linux/*uio*

Linux VFIO
M: Anatoly Burakov <anatoly.burakov@intel.com>
F: lib/librte_eal/linuxapp/eal/*vfio*
F: drivers/bus/pci/linux/*vfio*

FreeBSD EAL (with overlaps)
M: Bruce Richardson <bruce.richardson@intel.com>
F: lib/librte_eal/bsdapp/Makefile
F: lib/librte_eal/bsdapp/eal/
F: doc/guides/freebsd_gsg/

FreeBSD contigmem
M: Bruce Richardson <bruce.richardson@intel.com>
F: lib/librte_eal/bsdapp/contigmem/

FreeBSD UIO
M: Bruce Richardson <bruce.richardson@intel.com>
F: lib/librte_eal/bsdapp/nic_uio/


Core Libraries
--------------

Memory pool
M: Olivier Matz <olivier.matz@6wind.com>
F: lib/librte_mempool/
F: drivers/mempool/Makefile
F: drivers/mempool/ring/
F: drivers/mempool/stack/
F: doc/guides/prog_guide/mempool_lib.rst
F: test/test/test_mempool*
F: test/test/test_func_reentrancy.c

Ring queue
M: Olivier Matz <olivier.matz@6wind.com>
F: lib/librte_ring/
F: doc/guides/prog_guide/ring_lib.rst
F: test/test/test_ring*
F: test/test/test_func_reentrancy.c

Packet buffer
M: Olivier Matz <olivier.matz@6wind.com>
F: lib/librte_mbuf/
F: doc/guides/prog_guide/mbuf_lib.rst
F: test/test/test_mbuf.c

Ethernet API
M: Thomas Monjalon <thomas@monjalon.net>
T: git://dpdk.org/next/dpdk-next-net
F: lib/librte_ether/
F: devtools/test-null.sh

Flow API
M: Adrien Mazarguil <adrien.mazarguil@6wind.com>
T: git://dpdk.org/next/dpdk-next-net
F: lib/librte_ether/rte_flow*

Traffic Management API - EXPERIMENTAL
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
T: git://dpdk.org/next/dpdk-next-tm
F: lib/librte_ether/rte_tm*

Traffic Metering and Policing API - EXPERIMENTAL
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: lib/librte_ether/rte_mtr*

Baseband API - EXPERIMENTAL
M: Amr Mokhtar <amr.mokhtar@intel.com>
F: lib/librte_bbdev/
F: doc/guides/prog_guide/bbdev.rst
F: drivers/bbdev/
F: doc/guides/bbdevs/
F: app/test-bbdev/
F: doc/guides/tools/testbbdev.rst
F: examples/bbdev_app/
F: doc/guides/sample_app_ug/bbdev_app.rst

Crypto API
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
M: Declan Doherty <declan.doherty@intel.com>
T: git://dpdk.org/next/dpdk-next-crypto
F: lib/librte_cryptodev/
F: test/test/test_cryptodev*
F: examples/l2fwd-crypto/

Security API - EXPERIMENTAL
M: Akhil Goyal <akhil.goyal@nxp.com>
M: Declan Doherty <declan.doherty@intel.com>
F: lib/librte_security/
F: doc/guides/prog_guide/rte_security.rst

Eventdev API
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
T: git://dpdk.org/next/dpdk-next-eventdev
F: lib/librte_eventdev/
F: drivers/event/skeleton/
F: test/test/test_eventdev.c

Eventdev Ethdev Rx Adapter API - EXPERIMENTAL
M: Nikhil Rao <nikhil.rao@intel.com>
T: git://dpdk.org/next/dpdk-next-eventdev
F: lib/librte_eventdev/*eth_rx_adapter*
F: test/test/test_event_eth_rx_adapter.c
F: doc/guides/prog_guide/event_ethernet_rx_adapter.rst

Raw device API - EXPERIMENTAL
M: Shreyansh Jain <shreyansh.jain@nxp.com>
M: Hemant Agrawal <hemant.agrawal@nxp.com>
F: lib/librte_rawdev/
F: drivers/raw/skeleton_rawdev/
F: test/test/test_rawdev.c
F: doc/guides/prog_guide/rawdev.rst


Bus Drivers
-----------

NXP buses
M: Hemant Agrawal <hemant.agrawal@nxp.com>
M: Shreyansh Jain <shreyansh.jain@nxp.com>
F: drivers/bus/dpaa/
F: drivers/bus/fslmc/

PCI bus driver
F: drivers/bus/pci/

VDEV bus driver
M: Jianfeng Tan <jianfeng.tan@intel.com>
F: drivers/bus/vdev/


Networking Drivers
------------------
M: Ferruh Yigit <ferruh.yigit@intel.com>
T: git://dpdk.org/next/dpdk-next-net
F: doc/guides/nics/features/default.ini

Link bonding
M: Declan Doherty <declan.doherty@intel.com>
F: drivers/net/bonding/
F: doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
F: test/test/test_link_bonding*
F: examples/bond/
F: doc/guides/nics/features/bonding.ini

Linux KNI
M: Ferruh Yigit <ferruh.yigit@intel.com>
F: lib/librte_eal/linuxapp/kni/
F: lib/librte_kni/
F: doc/guides/prog_guide/kernel_nic_interface.rst
F: test/test/test_kni.c
F: examples/kni/
F: doc/guides/sample_app_ug/kernel_nic_interface.rst

Linux AF_PACKET
M: John W. Linville <linville@tuxdriver.com>
F: drivers/net/af_packet/
F: doc/guides/nics/features/afpacket.ini

Amazon ENA
M: Marcin Wojtas <mw@semihalf.com>
M: Michal Krawczyk <mk@semihalf.com>
M: Guy Tzalik <gtzalik@amazon.com>
M: Evgeny Schemeilin <evgenys@amazon.com>
F: drivers/net/ena/
F: doc/guides/nics/ena.rst
F: doc/guides/nics/features/ena.ini

Atomic Rules ARK
M: Shepard Siegel <shepard.siegel@atomicrules.com>
M: Ed Czeck <ed.czeck@atomicrules.com>
M: John Miller <john.miller@atomicrules.com>
F: drivers/net/ark/
F: doc/guides/nics/ark.rst
F: doc/guides/nics/features/ark.ini

Broadcom bnxt
M: Ajit Khaparde <ajit.khaparde@broadcom.com>
M: Somnath Kotur <somnath.kotur@broadcom.com>
F: drivers/net/bnxt/
F: doc/guides/nics/bnxt.rst
F: doc/guides/nics/features/bnxt.ini

Cavium ThunderX nicvf
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
M: Maciej Czekaj <maciej.czekaj@caviumnetworks.com>
F: drivers/net/thunderx/
F: doc/guides/nics/thunderx.rst
F: doc/guides/nics/features/thunderx.ini

Cavium LiquidIO
M: Shijith Thotton <shijith.thotton@cavium.com>
M: Srisivasubramanian Srinivasan <ssrinivasan@cavium.com>
F: drivers/net/liquidio/
F: doc/guides/nics/liquidio.rst
F: doc/guides/nics/features/liquidio.ini

Cavium OcteonTX
M: Santosh Shukla <santosh.shukla@caviumnetworks.com>
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
F: drivers/mempool/octeontx/
F: drivers/net/octeontx/
F: doc/guides/nics/octeontx.rst
F: doc/guides/nics/features/octeontx.ini

Chelsio cxgbe
M: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
F: drivers/net/cxgbe/
F: doc/guides/nics/cxgbe.rst
F: doc/guides/nics/features/cxgbe.ini

Cisco enic
M: John Daley <johndale@cisco.com>
M: Hyong Youb Kim <hyonkim@cisco.com>
F: drivers/net/enic/
F: doc/guides/nics/enic.rst
F: doc/guides/nics/features/enic.ini

Intel e1000
M: Wenzhuo Lu <wenzhuo.lu@intel.com>
T: git://dpdk.org/next/dpdk-next-net-intel
F: drivers/net/e1000/
F: doc/guides/nics/e1000em.rst
F: doc/guides/nics/intel_vf.rst
F: doc/guides/nics/features/e1000.ini
F: doc/guides/nics/features/igb*.ini

Intel ixgbe
M: Wenzhuo Lu <wenzhuo.lu@intel.com>
M: Konstantin Ananyev <konstantin.ananyev@intel.com>
T: git://dpdk.org/next/dpdk-next-net-intel
F: drivers/net/ixgbe/
F: doc/guides/nics/ixgbe.rst
F: doc/guides/nics/intel_vf.rst
F: doc/guides/nics/features/ixgbe*.ini

Intel i40e
M: Beilei Xing <beilei.xing@intel.com>
M: Qi Zhang <qi.z.zhang@intel.com>
T: git://dpdk.org/next/dpdk-next-net-intel
F: drivers/net/i40e/
F: doc/guides/nics/i40e.rst
F: doc/guides/nics/intel_vf.rst
F: doc/guides/nics/features/i40e*.ini

Intel fm10k
M: Qi Zhang <qi.z.zhang@intel.com>
M: Xiao Wang <xiao.w.wang@intel.com>
T: git://dpdk.org/next/dpdk-next-net-intel
F: drivers/net/fm10k/
F: doc/guides/nics/features/fm10k*.ini

Intel avf
M: Jingjing Wu <jingjing.wu@intel.com>
M: Wenzhuo Lu <wenzhuo.lu@intel.com>
F: drivers/net/avf/
F: doc/guides/nics/features/avf*.ini

Mellanox mlx4
M: Adrien Mazarguil <adrien.mazarguil@6wind.com>
T: git://dpdk.org/next/dpdk-next-net-mlx
F: drivers/net/mlx4/
F: doc/guides/nics/mlx4.rst
F: doc/guides/nics/features/mlx4.ini

Mellanox mlx5
M: Adrien Mazarguil <adrien.mazarguil@6wind.com>
M: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
M: Yongseok Koh <yskoh@mellanox.com>
T: git://dpdk.org/next/dpdk-next-net-mlx
F: drivers/net/mlx5/
F: doc/guides/nics/mlx5.rst
F: doc/guides/nics/features/mlx5.ini

Marvell mrvl
M: Jacek Siuda <jck@semihalf.com>
M: Tomasz Duszynski <tdu@semihalf.com>
M: Dmitri Epshtein <dima@marvell.com>
M: Natalie Samsonov <nsamsono@marvell.com>
M: Jianbo Liu <jianbo.liu@arm.com>
F: drivers/net/mrvl/
F: doc/guides/nics/mrvl.rst
F: doc/guides/nics/features/mrvl.ini

Microsoft vdev_netvsc - EXPERIMENTAL
M: Matan Azrad <matan@mellanox.com>
F: drivers/net/vdev_netvsc/
F: doc/guides/nics/vdev_netvsc.rst
F: doc/guides/nics/features/vdev_netvsc.ini

Netcope szedata2
M: Matej Vido <vido@cesnet.cz>
F: drivers/net/szedata2/
F: doc/guides/nics/szedata2.rst
F: doc/guides/nics/features/szedata2.ini

Netronome nfp
M: Alejandro Lucero <alejandro.lucero@netronome.com>
F: drivers/net/nfp/
F: doc/guides/nics/nfp.rst
F: doc/guides/nics/features/nfp*.ini

NXP dpaa
M: Hemant Agrawal <hemant.agrawal@nxp.com>
M: Shreyansh Jain <shreyansh.jain@nxp.com>
F: drivers/mempool/dpaa/
F: drivers/net/dpaa/
F: doc/guides/nics/dpaa.rst
F: doc/guides/nics/features/dpaa.ini

NXP dpaa2
M: Hemant Agrawal <hemant.agrawal@nxp.com>
M: Shreyansh Jain <shreyansh.jain@nxp.com>
F: drivers/mempool/dpaa2/
F: drivers/net/dpaa2/
F: doc/guides/nics/dpaa2.rst
F: doc/guides/nics/features/dpaa2.ini

QLogic bnx2x
M: Harish Patil <harish.patil@cavium.com>
M: Rasesh Mody <rasesh.mody@cavium.com>
F: drivers/net/bnx2x/
F: doc/guides/nics/bnx2x.rst
F: doc/guides/nics/features/bnx2x*.ini

QLogic qede PMD
M: Rasesh Mody <rasesh.mody@cavium.com>
M: Harish Patil <harish.patil@cavium.com>
M: Shahed Shaikh <shahed.shaikh@cavium.com>
F: drivers/net/qede/
F: doc/guides/nics/qede.rst
F: doc/guides/nics/features/qede*.ini

Solarflare sfc_efx
M: Andrew Rybchenko <arybchenko@solarflare.com>
F: drivers/net/sfc/
F: doc/guides/nics/sfc_efx.rst
F: doc/guides/nics/features/sfc_efx.ini

VMware vmxnet3
M: Shrikrishna Khare <skhare@vmware.com>
F: drivers/net/vmxnet3/
F: doc/guides/nics/vmxnet3.rst
F: doc/guides/nics/features/vmxnet3.ini

Vhost-user
M: Yuanhan Liu <yliu@fridaylinux.org>
M: Maxime Coquelin <maxime.coquelin@redhat.com>
T: git://dpdk.org/next/dpdk-next-virtio
F: lib/librte_vhost/
F: doc/guides/prog_guide/vhost_lib.rst
F: examples/vhost/
F: doc/guides/sample_app_ug/vhost.rst
F: examples/vhost_scsi/
F: doc/guides/sample_app_ug/vhost_scsi.rst

Vhost PMD
M: Tetsuya Mukawa <mtetsuyah@gmail.com>
M: Yuanhan Liu <yliu@fridaylinux.org>
M: Maxime Coquelin <maxime.coquelin@redhat.com>
T: git://dpdk.org/next/dpdk-next-virtio
F: drivers/net/vhost/
F: doc/guides/nics/features/vhost.ini

Virtio PMD
M: Yuanhan Liu <yliu@fridaylinux.org>
M: Maxime Coquelin <maxime.coquelin@redhat.com>
M: Tiwei Bie <tiwei.bie@intel.com>
T: git://dpdk.org/next/dpdk-next-virtio
F: drivers/net/virtio/
F: doc/guides/nics/virtio.rst
F: doc/guides/nics/features/virtio*.ini

Wind River AVP
M: Allain Legacy <allain.legacy@windriver.com>
M: Matt Peters <matt.peters@windriver.com>
F: drivers/net/avp/
F: doc/guides/nics/avp.rst
F: doc/guides/nics/features/avp.ini

PCAP PMD
M: Ferruh Yigit <ferruh.yigit@intel.com>
F: drivers/net/pcap/
F: doc/guides/nics/pcap_ring.rst
F: doc/guides/nics/features/pcap.ini

Tap PMD
M: Pascal Mazon <pascal.mazon@6wind.com>
F: drivers/net/tap/
F: doc/guides/nics/tap.rst
F: doc/guides/nics/features/tap.ini

KNI PMD
M: Ferruh Yigit <ferruh.yigit@intel.com>
F: drivers/net/kni/
F: doc/guides/nics/kni.rst
F: doc/guides/nics/features/kni.ini

Ring PMD
M: Bruce Richardson <bruce.richardson@intel.com>
F: drivers/net/ring/
F: doc/guides/nics/pcap_ring.rst
F: test/test/test_pmd_ring.c
F: test/test/test_pmd_ring_perf.c
F: doc/guides/nics/features/ring.ini

Null Networking PMD
M: Tetsuya Mukawa <mtetsuyah@gmail.com>
F: drivers/net/null/
F: doc/guides/nics/features/null.ini

Fail-safe PMD
M: Gaetan Rivet <gaetan.rivet@6wind.com>
F: drivers/net/failsafe/
F: doc/guides/nics/fail_safe.rst

Softnic PMD
M: Jasvinder Singh <jasvinder.singh@intel.com>
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: drivers/net/softnic/


Crypto Drivers
--------------
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
T: git://dpdk.org/next/dpdk-next-crypto
F: doc/guides/cryptodevs/features/default.ini

ARMv8 Crypto
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
F: drivers/crypto/armv8/
F: doc/guides/cryptodevs/armv8.rst
F: doc/guides/cryptodevs/features/armv8.ini

Crypto Scheduler
M: Fan Zhang <roy.fan.zhang@intel.com>
F: drivers/crypto/scheduler/
F: doc/guides/cryptodevs/scheduler.rst

Intel AES-NI GCM
M: Declan Doherty <declan.doherty@intel.com>
F: drivers/crypto/aesni_gcm/
F: doc/guides/cryptodevs/aesni_gcm.rst
F: doc/guides/cryptodevs/features/aesni_gcm.ini

Intel AES-NI Multi-Buffer
M: Declan Doherty <declan.doherty@intel.com>
F: drivers/crypto/aesni_mb/
F: doc/guides/cryptodevs/aesni_mb.rst
F: doc/guides/cryptodevs/features/aesni_mb.ini

Intel QuickAssist
M: John Griffin <john.griffin@intel.com>
M: Fiona Trahe <fiona.trahe@intel.com>
M: Deepak Kumar Jain <deepak.k.jain@intel.com>
F: drivers/crypto/qat/
F: doc/guides/cryptodevs/qat.rst
F: doc/guides/cryptodevs/features/qat.ini

KASUMI
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: drivers/crypto/kasumi/
F: doc/guides/cryptodevs/kasumi.rst
F: doc/guides/cryptodevs/features/kasumi.ini

Marvell Mrvl
M: Jacek Siuda <jck@semihalf.com>
M: Tomasz Duszynski <tdu@semihalf.com>
M: Dmitri Epshtein <dima@marvell.com>
M: Natalie Samsonov <nsamsono@marvell.com>
M: Jianbo Liu <jianbo.liu@arm.com>
F: drivers/crypto/mrvl/
F: doc/guides/cryptodevs/mrvl.rst
F: doc/guides/cryptodevs/features/mrvl.ini

Null Crypto
M: Declan Doherty <declan.doherty@intel.com>
F: drivers/crypto/null/
F: doc/guides/cryptodevs/null.rst
F: doc/guides/cryptodevs/features/null.ini

NXP DPAA_SEC
M: Akhil Goyal <akhil.goyal@nxp.com>
M: Hemant Agrawal <hemant.agrawal@nxp.com>
F: drivers/crypto/dpaa_sec/
F: doc/guides/cryptodevs/dpaa_sec.rst
F: doc/guides/cryptodevs/features/dpaa_sec.ini

NXP DPAA2_SEC
M: Akhil Goyal <akhil.goyal@nxp.com>
M: Hemant Agrawal <hemant.agrawal@nxp.com>
F: drivers/crypto/dpaa2_sec/
F: doc/guides/cryptodevs/dpaa2_sec.rst
F: doc/guides/cryptodevs/features/dpaa2_sec.ini

OpenSSL
M: Declan Doherty <declan.doherty@intel.com>
F: drivers/crypto/openssl/
F: doc/guides/cryptodevs/openssl.rst
F: doc/guides/cryptodevs/features/openssl.ini

SNOW 3G
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: drivers/crypto/snow3g/
F: doc/guides/cryptodevs/snow3g.rst
F: doc/guides/cryptodevs/features/snow3g.ini

ZUC
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: drivers/crypto/zuc/
F: doc/guides/cryptodevs/zuc.rst
F: doc/guides/cryptodevs/features/zuc.ini


Eventdev Drivers
----------------
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
T: git://dpdk.org/next/dpdk-next-eventdev

Cavium OCTEONTX ssovf
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
M: Santosh Shukla <santosh.shukla@caviumnetworks.com>
F: drivers/event/octeontx/
F: doc/guides/eventdevs/octeontx.rst

NXP DPAA2 eventdev
M: Hemant Agrawal <hemant.agrawal@nxp.com>
M: Nipun Gupta <nipun.gupta@nxp.com>
F: drivers/event/dpaa2/
F: doc/guides/eventdevs/dpaa2.rst

NXP DPAA eventdev
M: Hemant Agrawal <hemant.agrawal@nxp.com>
M: Sunil Kumar Kori <sunil.kori@nxp.com>
F: drivers/event/dpaa/
F: doc/guides/eventdevs/dpaa.rst

Software Eventdev PMD
M: Harry van Haaren <harry.van.haaren@intel.com>
F: drivers/event/sw/
F: doc/guides/eventdevs/sw.rst
F: examples/eventdev_pipeline/
F: doc/guides/sample_app_ug/eventdev_pipeline.rst

Software OPDL Eventdev PMD
M: Liang Ma <liang.j.ma@intel.com>
M: Peter Mccarthy <peter.mccarthy@intel.com>
F: drivers/event/opdl/
F: doc/guides/eventdevs/opdl.rst


Packet processing
-----------------

Network headers
M: Olivier Matz <olivier.matz@6wind.com>
F: lib/librte_net/

Packet CRC
M: Jasvinder Singh <jasvinder.singh@intel.com>
F: lib/librte_net/rte_net_crc*
F: lib/librte_net/net_crc_sse.h
F: test/test/test_crc.c

IP fragmentation & reassembly
M: Konstantin Ananyev <konstantin.ananyev@intel.com>
F: lib/librte_ip_frag/
F: doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
F: examples/ip_fragmentation/
F: doc/guides/sample_app_ug/ip_frag.rst
F: examples/ip_reassembly/
F: doc/guides/sample_app_ug/ip_reassembly.rst

Generic Receive Offload - EXPERIMENTAL
M: Jiayu Hu <jiayu.hu@intel.com>
F: lib/librte_gro/
F: doc/guides/prog_guide/generic_receive_offload_lib.rst

Generic Segmentation Offload
M: Jiayu Hu <jiayu.hu@intel.com>
M: Mark Kavanagh <mark.b.kavanagh@intel.com>
F: lib/librte_gso/
F: doc/guides/prog_guide/generic_segmentation_offload_lib.rst

Flow Classify - EXPERIMENTAL
M: Bernard Iremonger <bernard.iremonger@intel.com>
F: lib/librte_flow_classify/
F: test/test/test_flow_classify*
F: doc/guides/prog_guide/flow_classify_lib.rst
F: examples/flow_classify/
F: doc/guides/sample_app_ug/flow_classify.rst

Distributor
M: Bruce Richardson <bruce.richardson@intel.com>
M: David Hunt <david.hunt@intel.com>
F: lib/librte_distributor/
F: doc/guides/prog_guide/packet_distrib_lib.rst
F: test/test/test_distributor*
F: examples/distributor/
F: doc/guides/sample_app_ug/dist_app.rst

Reorder
M: Reshma Pattan <reshma.pattan@intel.com>
F: lib/librte_reorder/
F: doc/guides/prog_guide/reorder_lib.rst
F: test/test/test_reorder*
F: examples/packet_ordering/
F: doc/guides/sample_app_ug/packet_ordering.rst

Hierarchical scheduler
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: lib/librte_sched/
F: doc/guides/prog_guide/qos_framework.rst
F: test/test/test_red.c
F: test/test/test_sched.c
F: examples/qos_sched/
F: doc/guides/sample_app_ug/qos_scheduler.rst

Packet capture
M: Reshma Pattan <reshma.pattan@intel.com>
F: lib/librte_pdump/
F: doc/guides/prog_guide/pdump_lib.rst
F: app/pdump/
F: doc/guides/tools/pdump.rst

Packet Framework
----------------
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: lib/librte_pipeline/
F: lib/librte_port/
F: lib/librte_table/
F: doc/guides/prog_guide/packet_framework.rst
F: test/test/test_table*
F: test/test-pipeline/
F: doc/guides/sample_app_ug/test_pipeline.rst
F: examples/ip_pipeline/
F: doc/guides/sample_app_ug/ip_pipeline.rst


Algorithms
----------

ACL
M: Konstantin Ananyev <konstantin.ananyev@intel.com>
F: lib/librte_acl/
F: doc/guides/prog_guide/packet_classif_access_ctrl.rst
F: test/test-acl/
F: test/test/test_acl.*
F: examples/l3fwd-acl/
F: doc/guides/sample_app_ug/l3_forward_access_ctrl.rst

EFD
M: Byron Marohn <byron.marohn@intel.com>
M: Pablo de Lara Guarch <pablo.de.lara.guarch@intel.com>
F: lib/librte_efd/
F: doc/guides/prog_guide/efd_lib.rst
F: test/test/test_efd*
F: examples/server_node_efd/
F: doc/guides/sample_app_ug/server_node_efd.rst

Hashes
M: Bruce Richardson <bruce.richardson@intel.com>
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: lib/librte_hash/
F: doc/guides/prog_guide/hash_lib.rst
F: test/test/test_*hash*
F: test/test/test_func_reentrancy.c

LPM
M: Bruce Richardson <bruce.richardson@intel.com>
F: lib/librte_lpm/
F: doc/guides/prog_guide/lpm*
F: test/test/test_lpm*
F: test/test/test_func_reentrancy.c
F: test/test/test_xmmt_ops.h

Membership - EXPERIMENTAL
M: Yipeng Wang <yipeng1.wang@intel.com>
M: Sameh Gobriel <sameh.gobriel@intel.com>
F: lib/librte_member/
F: doc/guides/prog_guide/member_lib.rst
F: test/test/test_member*

Traffic metering
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: lib/librte_meter/
F: doc/guides/sample_app_ug/qos_scheduler.rst
F: test/test/test_meter.c
F: examples/qos_meter/
F: doc/guides/sample_app_ug/qos_metering.rst

Other libraries
---------------

Configuration file
M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
F: lib/librte_cfgfile/
F: test/test/test_cfgfile.c
F: test/test/test_cfgfiles/

Interactive command line
M: Olivier Matz <olivier.matz@6wind.com>
F: lib/librte_cmdline/
F: test/cmdline_test/
F: test/test/test_cmdline*
F: examples/cmdline/
F: doc/guides/sample_app_ug/cmd_line.rst

Key/Value parsing
M: Olivier Matz <olivier.matz@6wind.com>
F: lib/librte_kvargs/
F: test/test/test_kvargs.c

PCI
M: Gaetan Rivet <gaetan.rivet@6wind.com>
F: lib/librte_pci/

Power management
M: David Hunt <david.hunt@intel.com>
F: lib/librte_power/
F: doc/guides/prog_guide/power_man.rst
F: test/test/test_power*
F: examples/l3fwd-power/
F: doc/guides/sample_app_ug/l3_forward_power_man.rst
F: examples/vm_power_manager/
F: doc/guides/sample_app_ug/vm_power_management.rst

Timers
M: Robert Sanford <rsanford@akamai.com>
F: lib/librte_timer/
F: doc/guides/prog_guide/timer_lib.rst
F: test/test/test_timer*
F: examples/timer/
F: doc/guides/sample_app_ug/timer.rst

Job statistics
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: lib/librte_jobstats/
F: examples/l2fwd-jobstats/
F: doc/guides/sample_app_ug/l2_forward_job_stats.rst

Metrics
M: Remy Horton <remy.horton@intel.com>
F: lib/librte_metrics/

Bit-rate statistics
M: Remy Horton <remy.horton@intel.com>
F: lib/librte_bitratestats/

Latency statistics
M: Reshma Pattan <reshma.pattan@intel.com>
F: lib/librte_latencystats/


Test Applications
-----------------

Unit tests framework
F: test/Makefile
F: test/test/Makefile
F: test/test/autotest*
F: test/test/commands.c
F: test/test/packet_burst_generator.c
F: test/test/packet_burst_generator.h
F: test/test/process.h
F: test/test/resource.*
F: test/test/test.c
F: test/test/test.h
F: test/test/test_pmd_perf.c
F: test/test/test_resource.c
F: test/test/virtual_pmd.c
F: test/test/virtual_pmd.h

Driver testing tool
M: Wenzhuo Lu <wenzhuo.lu@intel.com>
M: Jingjing Wu <jingjing.wu@intel.com>
F: app/test-pmd/
F: doc/guides/testpmd_app_ug/

Crypto performance test application
M: Declan Doherty <declan.doherty@intel.com>
F: app/test-crypto-perf/
F: doc/guides/tools/cryptoperf.rst

Eventdev test application
M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
F: app/test-eventdev/
F: doc/guides/tools/testeventdev.rst
F: doc/guides/tools/img/eventdev_*
F: test/test/test_event_ring.c

Procinfo tool
M: Maryam Tahhan <maryam.tahhan@intel.com>
M: Reshma Pattan <reshma.pattan@intel.com>
F: app/proc_info/
F: doc/guides/tools/proc_info.rst


Other Example Applications
--------------------------

M: Remy Horton <remy.horton@intel.com>
F: examples/ethtool/
F: doc/guides/sample_app_ug/ethtool.rst

F: examples/exception_path/
F: doc/guides/sample_app_ug/exception_path.rst

M: Ori Kam <orika@mellanox.com>
F: examples/flow_filtering/
F: doc/guides/sample_app_ug/flow_filtering.rst

M: Bruce Richardson <bruce.richardson@intel.com>
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: examples/helloworld/
F: doc/guides/sample_app_ug/hello_world.rst

M: Radu Nicolau <radu.nicolau@intel.com>
M: Akhil Goyal <akhil.goyal@nxp.com>
F: examples/ipsec-secgw/
F: doc/guides/sample_app_ug/ipsec_secgw.rst

F: examples/ipv4_multicast/
F: doc/guides/sample_app_ug/ipv4_multicast.rst

M: Bruce Richardson <bruce.richardson@intel.com>
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: examples/l2fwd/
F: doc/guides/sample_app_ug/l2_forward_real_virtual.rst

M: Tomasz Kantecki <tomasz.kantecki@intel.com>
F: doc/guides/sample_app_ug/l2_forward_cat.rst
F: examples/l2fwd-cat/

F: examples/l3fwd/
F: doc/guides/sample_app_ug/l3_forward.rst

F: examples/l3fwd-vf/
F: doc/guides/sample_app_ug/l3_forward_virtual.rst

F: examples/link_status_interrupt/
F: doc/guides/sample_app_ug/link_status_intr.rst

F: examples/load_balancer/
F: doc/guides/sample_app_ug/load_balancer.rst

F: examples/netmap_compat/
F: doc/guides/sample_app_ug/netmap_compatibility.rst

L-threads - EXPERIMENTAL
M: John McNamara <john.mcnamara@intel.com>
F: examples/performance-thread/
F: doc/guides/sample_app_ug/performance_thread.rst

M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: examples/ptpclient/

F: examples/quota_watermark/
F: doc/guides/sample_app_ug/quota_watermark.rst

M: Bruce Richardson <bruce.richardson@intel.com>
M: John McNamara <john.mcnamara@intel.com>
F: examples/rxtx_callbacks/
F: doc/guides/sample_app_ug/rxtx_callbacks.rst

M: Harry van Haaren <harry.van.haaren@intel.com>
F: examples/service_cores/
F: doc/guides/sample_app_ug/service_cores.rst

M: Bruce Richardson <bruce.richardson@intel.com>
M: John McNamara <john.mcnamara@intel.com>
F: examples/skeleton/
F: doc/guides/sample_app_ug/skeleton.rst

M: Jijiang Liu <jijiang.liu@intel.com>
F: examples/tep_termination/

F: examples/vmdq/
F: examples/vmdq_dcb/
F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst