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
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 (http://dpdk.org/ml/archives/dev/2016-December/052433.html) 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
(http://dpdk.org/ml/archives/dev/2016-December/052877.html). 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
(http://dpdk.org/ml/archives/dev/2016-November/050956.html) 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 (https://tools.ietf.org/html/rfc5474).
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
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.