From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 7CBBD2952 for ; Tue, 3 May 2016 13:24:47 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 03 May 2016 04:24:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,572,1455004800"; d="scan'208";a="967607246" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga002.jf.intel.com with ESMTP; 03 May 2016 04:24:44 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.238]) by IRSMSX103.ger.corp.intel.com ([169.254.3.12]) with mapi id 14.03.0248.002; Tue, 3 May 2016 12:24:43 +0100 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: 16.11 Roadmap Thread-Index: AdGlKwFO4OYItmoSTNGXRCjLFD/nmA== Date: Tue, 3 May 2016 11:24:41 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA6751EB16@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDZiZmUzYzAtNjQyYy00Mzg4LTkwZmUtMzg5OTFjMTlhMjI2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InJvODBRbjZpK21Yc0lIcG5oSFoxRnJTMHJ2REc1Qk9ScWxFWnRhejRocTA9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dpdk-dev] 16.11 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: Tue, 03 May 2016 11:24:48 -0000 We were a little late doing this for 16.07, so we're going to try and commu= nicate our roadmap for future releases earlier. Our aim is to do this 6 mon= ths before a release. Some things will obviously change during planning/dev= elopment, so we'll provide an update 4 months before the release. After tha= t, things should hopefully be relatively stable. Below are the features that we're planning to submit for 16.11. 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 16.11. Cryptodev Scheduler & Packet Reordering: Add a scheduler to cryptodev which will allow hardware and software acceler= ation to be used on the same core. If both are available, the scheduler wil= l determine whether to use hardware or software acceleration based on packe= t size and other factors (TBD). Support packet reordering in cryptodev so t= hat packet order is maintained when hardware and software acceleration are = combined. Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist Techn= ology) for Additional Algorithms: Add support for all algorithms which are supported by Intel(r) QuickAssist = Technology but are not currently supported in DPDK. This includes: AES_CTR_= 128/192/256, MD5, MD5_HMAC, SHA1, SHA224, SHA224_HMAC, SHA256, SHA384, SHA3= 84_HMAC, SHA512, AES-XTS, KASUMI. Cryptodev Support for Software Acceleration for Additional Algorithms: For every algorithm that we support in hardware, provide a software impleme= ntation. This means that an application can always rely on the cryptodev AP= I to provide the requested service, even if hardware acceleration is not av= ailable. Cryptodev Performance Optimization: Analyze the performance of the cryptodev API, identify bottlenecks, and opt= imize where required. Generic Classification API: Create a new API to provide generic filtering capabilities that works acros= s NICs. This will include a software implementation which can be used in ca= ses where NICs that don't support all the capabilities of the API. An RFC w= ill be submitted in the 16.07 timeframe. We're targeting the implementation= at the 16.11 release, but this is a complex change and there may be signif= icant community interest/feedback on it, so it may be deferred until a late= r release. Enhanced Packet Distributor: Optimize performance of the Packet Distributor library by using vector inst= ructions and other techniques. =09 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 again it cannot reconnect to the e= xisting VMs. To address this, both QEMU and vhost-user need to support clie= nt mode (currently only server mode is supported), which implements reconne= ction messages that allow the vswitch to reconnect to the VMs. Changes are = required in QEMU as well as in DPDK, so this change will need to be coordin= ated with the QEMU community. =09 Delay Packet Copy in vHost-User Dequeue: It may be possible to increase vhost-user performance by delaying the packe= t 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 defin= itely required. Further investigation is required to determine how much of = a performance gain can be achieved. Cuckoo Hash Acceleration using TSX: Improve performance of Cuckoo Hash using Transactional Synchronization Exte= nsions (TSX).