Roadmap

Version 20.02 (2020 February)

• ring API for user defined element size
• mempool for mbufs with external buffer
• Arm WFE/SEV instructions in ticket lock
• rte_flow API for DSCP field during decapsulation
• rte_flow for rules based on Intel DDP profiles
• mlx5 rte_flow features like GTP-U matching, multi-updates rule
• mlx5 memory consumption reduced
• mlx5 support of ConnectX-5 features with ConnectX-6 Dx
• mlx5 vDPA PMD
• virtio packed ring notification
• virtio 1.1 server mode
• rte_tm enhancement for OCTEON TX2
• raw driver OCTEON TX2 endpoint for SmartNIC use case
• eventdev examples in l3fwd and ipsec-secgw
• crypto Rx and Tx on different cores
• AArch64 crypto library integration with Armv8 crypto PMD
• AES-NI PMDs with latest IPsec multi-buffer library
• chachapoly symmetric crypto algorithm in Intel QAT devices
• ECDSA & ECPM asymmetric crypto for OCTEON TX
• additional crypto algorithms in Nitrox PMD
• OCTEON TX2 inline IPsec using rte_security
• rte_security improved performance for IPsec with software crypto
• regexdev
• additional Windows support for EAL functions
• basic support for OpenWRT
• UBSan in build

Nice to have - Future

• RCU API for deferred resource reclamation
• integrate RCU deferred resource reclamation API with LPM and hash libraries
• lock-free l3fwd algorithms
• multi-process rework
• automatic UIO/VFIO binding
• infiniband driver class (ibdev)
• default configuration from files
• generic white/blacklisting
• libedit integration

Cycle model

A typical release should be done after 3 months.

It is designed to allow DPDK to keep evolving at a rapid pace while giving enough opportunity to review, discuss and improve the contributions.

The merge window will open once the previous release is complete. First version of a new feature must be submitted before the proposal deadline. Features that miss this first period will be deferred until the next release.

Updated versions of patches (v2, v3, etc.) will be submitted to address comments. The new features must be properly reviewed, tested and accepted before the integration deadline. Otherwise, they will be postponed to the next releases.

At the end of the merge window, the first release candidate is out.

The last period is 1 month long and is dedicated to bug fixing.

Scheduling

20.02

• Proposal deadline: December 11, 2019
• Integration deadline: January 15, 2020
• Release: February 14, 2020

20.05

• Release: May 2020

20.08

• Release: August 2020

20.11

• Release: November 2020

Stable Releases

There is a documentation page describing the guidelines of the stable releases.

Stable point releases follow mainline releases.

After each -rc tag and after the final version, relevant bug fixes get backported by the stable maintainers into the respective branches in “bursts”.

Developers can provide stable-specific patches by sending them to stable@dpdk.org only (avoiding dev@dpdk.org).

After all the relevant bugfixes have been backported, regression tests are run, and if clear, the stable release is announced.

Typically a new stable release version follows a mainline release by 1-2 weeks, depending on the test results.