Roadmap

Version 19.11 (2019 November)

• configurability of Rx offloads
• rte_flow patterns for NSH, IGMP, AH
• rte_flow actions for mirroring and multicast
• Rx metadata in mbuf, with rte_flow API and mlx5 implementation
• hairpin forwarding offload, with mlx5 implementation
• VF configuration from host via representor port id
• Arm N1 platform config
• Arm optimizations in i40e and ixgbe
• ice support of DDP, multi-process and flexible descriptor
• ice rte_flow updates to support RSS, high/low priority flows, DDP profiles
• ice and iavf avx2 vector path
• ipn3ke graceful shutdown
• mlx5 HW support of VLAN id update and push/pop, VF LAG, flow metering and EEPROM module
• virtio packed ring performance optimizations
• use C11 atomic functions in memif
• Arm WFE/SEV instructions in spinlock and ring library
• integrate RCU library with LPM and hash libraries
• optimized algorithm for resizeable hash table
• lock-free stack mempool handler
• lock-free l3fwd algorithms
• ntb FIFO ring for Rx/Tx
• eventdev examples in l2fwd-event, l3fwd and ipsec-secgw
• cryptodev session-less asymmetric crypto
• Nitrox cryptodev
• OCTEON TX asymmetric crypto
• OCTEON TX2 cryptodev
• OCTEON TX2 inline IPsec using rte_security
• rte_security support of inline crypto statistics
• rte_security improved performance for IPsec with software crypto
• IPsec add security association database
• ipsec-secgw support of multiple sessions for the same SA
• QAT stateful decompression
• regexdev
• template based ring API
• sched library configuration more flexible
• eBPF arm64 JIT
• KNI IOVA as VA
• sample application for ioat
• UBSan in build

Nice to have - Future

• 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

19.11

• Proposal deadline: September 6, 2019
• Integration deadline: October 23, 2019
• Release: November 22, 2019

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.