From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id E0AC42BF3 for ; Fri, 13 Jan 2017 11:24:04 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP; 13 Jan 2017 02:24:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,221,1477983600"; d="scan'208";a="48434279" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga004.jf.intel.com with ESMTP; 13 Jan 2017 02:24:03 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX151.ger.corp.intel.com ([169.254.4.20]) with mapi id 14.03.0248.002; Fri, 13 Jan 2017 10:24:02 +0000 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: 17.05 Roadmap Thread-Index: AdJthHtgT93bnbBzSNmabkEXEAQoQw== Date: Fri, 13 Jan 2017 10:24:01 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA722A7A17@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2I0NjFhOGYtZTQ2NC00MjVlLTlhNDgtMDk4NDNiNTE1NWM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiIxbEFnK1A3U0V0SkV3amQySjVna2o3OHRKTGlRWnRKS1FQN3NaRWd5UFQwPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dpdk-dev] 17.05 Roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:24:05 -0000 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 sof= tware version of the DES algorithm. Cryptodev DOCSIS BPI+: The cryptodev API will be enhanced to enable process= ing of packets according to the Baseline Privacy Interface Plus (BPI+) spec= ification described in the Data-over-Cable Service Interface Specification = (DOCSIS) Security Specification (http://www.cablelabs.com/wp-content/upload= s/specdocs/CM-SP-SECv3.1-I06-160602.pdf). See the RFC (http://dpdk.org/ml/a= rchives/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 eithe= r 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 mo= dified by the MAC for PHS (packet header suppression).=20 API to Configure Programmable Devices: More devices are now supporting prog= rammable components, for example the Pipeline Personalization Profiles in I= 40E. 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 in= clude 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 filte= rs. Enable MPLS on I40E: MPLSoUDP and MPLSoGRE will be supported for I40E, incl= uding the new protocols and filtering (RSS and Flow Director), checksum off= load 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 initia= lly, 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/arch= ives/dev/2016-November/050956.html) for details. IPFIX Support: The Internet Protocol Flow Information Export (IPFIX) protoc= ol provides network administrators with access to IP Flow information. An o= bservation point (one for all the interfaces), metering process and an expo= rter process will be implemented. The observation point and metering proces= s 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 vi= rtio-user, which is a virtual device for high performance container network= ing. Automated VF Processing of PF Reset for I40E: In 16.07, changes were made f= or 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 process= ing 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 m= ultiple guests, so the burst size per guest decreases as the number of gues= ts increases. Tx buffering will be added which will increase the Tx burst s= ize and increase performance. Consistent PMD Batching Behaviour: PMD Tx batching behavior is not consiste= nt between PMDs. Some PMDs have no limit for nb_pkts (besides number of ava= ilable 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 pack= ets in multiple bursts up to that size. The application needs to manage the= se differences. To make things easier for application developers, we're con= sidering putting the logic for managing this directly into rte_eth_tx_burst= .