From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 9C3C3569A for ; Thu, 31 Mar 2016 10:21:10 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP; 31 Mar 2016 01:21:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,421,1455004800"; d="scan'208";a="922419860" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 31 Mar 2016 01:21:08 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.13]) by IRSMSX101.ger.corp.intel.com ([169.254.1.157]) with mapi id 14.03.0248.002; Thu, 31 Mar 2016 09:21:07 +0100 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: 16.07 Roadmap Thread-Index: AdGLIy2O3Xn8kX4sQ5CIPqgQCRAD9A== Date: Thu, 31 Mar 2016 08:21:07 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA674E4351@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTZkM2I2ZWEtZGU1OC00ZDdiLWFlYWEtNWE3N2U0MDUxYmI2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImFvSFU2eTFwZXR5SjVvQlk1S05RVTBndWduak9ZWVM2QlVvUHZKK0haRjQ9In0= 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] 16.07 Roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 08:21:11 -0000 As we're nearing the completion of the 16.04 release, I'd like to let the c= ommunity know our plans for 16.07. It would be good if others are also will= ing to share their plans so that we can build up a complete picture of what= 's targeted for 16.07. These are the features that we're planning to submit: Vhost/Virtio Performance Loopback Utility: A tool will be provided which wi= ll allow virtio/vhost performance testing without the need for NIC traffic. Virtio Code Refactoring for Rx/TX Split: The Rx and Tx queues will be split= as they have different information to maintain apart from the common vring= . Other cleanups will be made to make the queues more friendly for optimiza= tion. Virtio Descriptor Index Update: The virtio descriptor index will be optimiz= ed for cache2cache transfer in the virtio PMD. The performance increase is = expected to be below 10%. Virtio in Containers: Support will be added for virtio in containers (see h= ttp://dpdk.org/ml/archives/dev/2016-February/032786.html). Multi-queue supp= ort will also be added. I40e NSH: This includes: 1. Recognize the Network Services Header packet ty= pe; 2. Direct traffic to queues based on service path header and service in= dex (dependent on firmware change so may not make 16.07); 3. Checksum offlo= ad. I40e Floating VEB: Deferred from 16.04. See http://dpdk.org/ml/archives/dev= /2016-March/036470.html for details. Automatic VF Reset From PF (i40e/ixgbe): Currently, when a PF notifies a VF= that a reset is required, DPDK just reports this event to the application,= which then needs to restart the VF port. A more user-friendly mechanism wi= ll be implemented where DPDK will reset the VF port directly. The applicati= on will still be notified, but will not need to handle the reset of the VF = port. Software Implementation of the KASUMI Algorithm: Under the cryptodev API, a= software implementation of the KASUMI algorithm will be supported. KASUMI = is widely used in mobile communications systems. Bit-Level Support for SNOW 3G: Support for the SNOW 3G algorithm is being a= dded in the 16.04 release. In 16.07, this will be enhanced so that offsets = and lengths can be specified in bits instead of bytes (so, you could encryp= t 50 bits of a stream starting from the 5th bit for example). IPsec Sample App Enhancements: Support for IPv6 and Transport Mode will be = added to the IPsec sample application that was submitted in 16.04. XStats Enhancements: Improve the extended NIC stats API to use id value pai= rs instead of string value pairs. Remap stats registers to use standard int= erface MIB naming and sizing. Keep-Alive Enhancements: Improve DPDK keep-alive to use the DPDK alarm/inte= rrupt API instead of using callbacks. Live Migration for SRIOV: Support for live migration for vhost-user is bein= g added to 16.04. This will be further enhanced to support live migration f= or SR-IOV by using link bonding to bond an SRIOV interface with a virtio in= terface. IP Pipeline Enhancements: This includes: 1. Configure the MAC address in th= e routing pipeline; 2. Enable RSS per network interface through the configu= ration file; 3. Streamline the CLI code of the IP pipeline application. Packet Capture Framework: In 16.04, there was lots of discussion on require= ments for tcpdump support in DPDK (see http://dpdk.org/ml/archives/dev/2016= -March/035592.html). For 16.07, we plan to submit a packet capture framewor= k which will support hooks for filtering capabilities such as BPF. Our spec= ific use case for this is for low rate packet capture for debug purposes. I= t should be possible for others to extend the framework to support high rat= e packet capture if they require that capability. External Mempool Manager: This was originally submitted for 16.04 but had t= o be deferred due to ABI changes. See http://dpdk.org/ml/archives/dev/2016-= March/035107.html for details. In addition, there are some features that we're working on now but which we= know won't make 16.07, either because time is too tight or because of exte= rnal dependencies. These include: QEMU vHost Back-End Reconnect: Currently, if a vswitch is connected to VMs = via vhost-user and the vswitch is restarted, then when it comes back up aga= in it cannot reconnect to the existing VMs. To address this, both QEMU and = vhost-user need to support client mode (currently only server mode is suppo= rted), which implements reconnection messages that allow the vswitch to rec= onnect to the VMs. Changes are required in QEMU as well as in DPDK, so this= change will need to be coordinated with the QEMU community. Delay Packet Copy in vHost-User Dequeue: It may be possible to increase vho= st-user performance by delaying the packet copy until a point where we know= for certain whether the copy is required or not. This would avoid copying = the packet in cases where it is not definitely required. Further investigat= ion is required to determine how much of a performance gain can be achieved= . Tim