Roadmap

Version 22.07 (2022 July)

• index-based per core mempool cache
• Arm CRC32 in generic API
• direct-rearm of Rx side buffers
• Tx QoS marking API
• VLAN-based input color metering
• protocol-based header split
• ethdev event on traffic threshold
• ethdev flow field ID to modify ECN
• ethdev flow rules pre-configuration flags
• ethdev queue-based ageing event info
• pipeline connection tracking improvements
• pipeline packet mirroring
• pipeline hash
• pipeline default action arguments
• AVF software back-end driver with device emulation libraries
• bonding Tx prepare
• octeontx2 mirroring
• qede initial support for next generation hardware
• qede flow API support
• spnic driver for Ramaxel devices
• iavf raw flow pattern
• iavf Rx timestamp offload
• ice header split
• ice 3-level QoS
• idpf PMD for Intel IPU SoC
• Intel AFU PMD based on rawdev
• mlx5 RSS on ESP SPI
• mlx5 flow header rewrite of ECN field
• mlx5 flow header rewrite with metering
• mlx5 flow matching of all switch ports in one rule
• mlx5 shaper based on traffic threshold
• vhost async dequeue for split ring and enable in vhost sample app
• vhost thread safety in-flight packets check
• vhost small copy with CPU in DSA-accelerated vhost
• vhost library statistics
• virtio hash reporting
• more info in dpdk-proc-info
• mlx5 crypto in plain text
• openssl PMD with OpenSSL-3.0
• qat with OpenSSL-3.0 library
• qat without dependency on OpenSSL-1.x
• qat asymmetric algorithm for Gen 4
• aesni-mb chained mbuf for AES-GCM and ChaChaPoly
• event vector support in SW Rx eventdev adapter
• control adapter and RX adapter enhancements in DLB driver
• DLB support for DLB 2.5 QE weight hardware feature
• DLB assignment of SW/HW credit quanta on port usage hint
• DLB specific COS on per port basis
• bbdev PMD for Intel ACC101 device
• dmadev telemetry
• EEPROM dump telemetry

Nice to have - Future

• lock-free l3fwd algorithms
• multi-process rework
• automatic UIO/VFIO binding
• infiniband driver class (ibdev)
• default configuration from files
• generic allow/blocklisting
• libedit integration
• UBSan in build
• regex driver based on libpcre
• IF proxy
• performance test for IP reassembly
• IPv6 in lookaside IPsec example
• anti-replay in inline IPsec example

Cycle model

A typical release should be done after 4 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 windows, the first release candidates are out.

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

Scheduling

22.07

• Proposal deadline (RFC/v1 patches): 10 April 2022
• API freeze (-rc1): 8 June 2022
• PMD features freeze (-rc2): 23 June 2022
• Builtin applications features freeze (-rc3): 30 June 2022
• Release: 13 July 2022

22.11

• Proposal deadline (RFC/v1 patches): 14 August 2022
• API freeze (-rc1): 3 October 2022
• PMD features freeze (-rc2): 24 October 2022
• Builtin applications features freeze (-rc3): 31 October 2022
• Release: 16 November 2022

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). Further information on subject prefixes for this case is documented here.

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 3-6 weeks, depending on the test results.