Below are the features that we're planning to submit for the 17.05 release. 
We'll submit a patch to update the roadmap page with this info.

It would be good if others are also willing to share their plans so that we can 
build up a complete picture of what's planned for 17.05 and make sure there's 
no duplication.

Cryptodev DES SW PMD: A PMD will be added which implements an optimized 
software version of the DES algorithm.

Cryptodev DOCSIS BPI+: The cryptodev API will be enhanced to enable processing 
of packets according to the Baseline Privacy Interface Plus (BPI+) 
specification described in the Data-over-Cable Service Interface Specification 
(DOCSIS) Security Specification 
 See the RFC ( for 
further details. Support will be added to the QAT PMD for AES and DES, to the 
new software PMD for DES (see previous item), and to the existing AESNI_MB PMD.

Cryptodev Scheduler: This allows packets to be encrypted/decrypted in either SW 
or HW depending on packet size and HW utilization. Reordering will be supported 
so that packet order can be preserved.

Ethernet 32-bit CRC Generation: An optimized x86 library for CRC-32 will be 
added. A CRC may need to be generated for a downstream frame by the DOCSIS MAC 
layer because the CRC may be removed by the NIC or the frame may be modified by 
the MAC for PHS (packet header suppression). 

API to Configure Programmable Devices: More devices are now supporting 
programmable components, for example the Pipeline Personalization Profiles in 
I40E. An API will be added to allow any programmable device to be configured.

I40E Hardware QoS: Hardware QoS will be supported on the I40E. This will 
include Tx bandwidth control (min and max), and Rx Traffic Class assignment.

Configurable Tunnel Filters for I40E: DPDK support will be added for a new I40E 
admin queue which allows configuration of filter types for cloud filters.

Enable MPLS on I40E: MPLSoUDP and MPLSoGRE will be supported for I40E, 
including the new protocols and filtering (RSS and Flow Director), checksum 
offload and packet type recognition.

Software Eventdev Implementation: The libeventdev API is being added in 17.02 
( A software 
implementation of this API will be added.

New Vhost Device Type: The vhost-user framework will be expanded so that it can 
support additional device types. Support for SCSI will be added initially, but 
block devices and other device types may be added in future.

Abstraction Layer for QoS: An abstraction layer for Quality of Service (QoS) 
hierarchical schedulers will be implemented. The goal of the abstraction layer 
is to provide a simple generic API that is agnostic of the underlying HW, SW or 
mixed HW-SW implementation. See the RFC 
( for details.

IPFIX Support: The Internet Protocol Flow Information Export (IPFIX) protocol 
provides network administrators with access to IP Flow information. An 
observation point (one for all the interfaces), metering process and an 
exporter process will be implemented. The observation point and metering 
process will be as defined in RFC 5474 (

Interrupt Mode for Virtio-User: Interrupt mode support will be added for 
virtio-user, which is a virtual device for high performance container 

Automated VF Processing of PF Reset for I40E: In 16.07, changes were made for 
both IXGBE and I40E to notify a VF when a PF reset occurs. This will be further 
enhanced for I40E so that the driver handles as much of the processing as 
possible, including things like resetting VF ports.

Tx Buffering in Vhost PMD: Overall throughput drops as the number of guests 
increases on a single host.  This is because a Tx burst is spread across 
multiple guests, so the burst size per guest decreases as the number of guests 
increases. Tx buffering will be added which will increase the Tx burst size and 
increase performance.

Consistent PMD Batching Behaviour: PMD Tx batching behavior is not consistent 
between PMDs. Some PMDs have no limit for nb_pkts (besides number of available 
descriptors), some (like vhost) have a limit on the max number of Tx packets 
(32 for vhost), and some define a max burst size and transmit packets in 
multiple bursts up to that size. The application needs to manage these 
differences. To make things easier for application developers, we're 
considering putting the logic for managing this directly into rte_eth_tx_burst.

Reply via email to