[dpdk-dev] 17.05 Roadmap

Hanoch Haim (hhaim) hhaim at cisco.com
Sun Jan 15 15:42:40 CET 2017

Hi Tim, 
It's great that you are going to expose the i40E Qos capability, would it be possible to expose the low-latency configuration too?

-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
Sent: Friday, January 13, 2017 12:24 PM
To: dev at dpdk.org
Subject: [dpdk-dev] 17.05 Roadmap

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 (http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-SECv3.1-I06-160602.pdf). 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 networking.

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.

More information about the dev mailing list