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 5476E2A5D for ; Thu, 7 Jul 2016 18:18:13 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 07 Jul 2016 09:18:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,324,1464678000"; d="scan'208";a="1012603884" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 07 Jul 2016 09:18:12 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.125]) by IRSMSX101.ger.corp.intel.com ([169.254.1.155]) with mapi id 14.03.0248.002; Thu, 7 Jul 2016 17:18:10 +0100 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] 16.11 Roadmap Thread-Index: AdHYNjZagRwNrbBHRnarWzVSv3cQaQ== Date: Thu, 7 Jul 2016 16:18:09 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA6757E669@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.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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: Thu, 07 Jul 2016 16:18:13 -0000 We published our initial roadmap for 16.11 at the start of May. Since then,= we've been doing more detailed planning and would like to provide an updat= e on the features that we plan to submit for this release. We'll schedule a community call where some of our software developers will = describe their work in a bit more detail and answer any questions. It would= be good if others are also willing to share their plans so that we can bui= ld up a complete picture of what's planned for 16.11. This is what we're planning to submit for 16.11: Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist Techn= ology) for Additional Algorithms: Add support for additional algorithms which are supported by Intel(r) Quick= Assist Technology but are not currently supported in DPDK. This includes: 3= DES_CBC_128/192, KASUMI, NULL, SHA224_HMAC, SHA384_HMAC and AES-GMAC.=20 Cryptodev Support for Software Acceleration for Additional Algorithms: Add support for software implementations of additional crypto algorithms. T= his includes: ZUC (EEA3 and EIA3) and 3DES_CBC_128/192 with MD5_HMAC, SHA1/= SHA224/SHA256_HMAC and AES-GMAC. ZUC will be supported via an optimized so= ftware library similar to KASUMI and SNOW3G. 3DES, and potentially other so= ftware implementations in future, will not be an optimized implementation, = so it will not perform to the same level as other optimized software librar= ies. Cryptodev Performance Optimization: Analyze the performance of the cryptodev API, identify bottlenecks, and opt= imize where required. IPsec Sample App Enhancements: Add support for AES-GCM, AES-CTR, config file support to remove hard-coding= of SAs/SPs etc., use forward cipher function to generate IV on CBC mode. Generic Flow Director/Filtering/Classification API: When a Generic Flow Director/Filtering/Classification API is agreed (see Ad= rien's RFC: http://dpdk.org/ml/archives/dev/2016-July/043365.html), impleme= nt support for that API for ixgbe and i40e. =20 Cuckoo Hash Enhancements: Optimize the Cuckoo Hash lookup stages by using intelligent prefetching for= keys and using IA AVX instructions for vector processing of keys. Add vHost PMD xStats: Update the vHost PMD to support the extended statistics API. Delay Packet Copy in vHost-User Dequeue: It may be possible to increase vhost-user performance by delaying the packe= t copy on Tx until a point where we know for certain whether the copy is re= quired or not. This would avoid copying the packet in cases where it is not= definitely required. Further investigation is required to determine how mu= ch of a performance gain can be achieved. > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of O'Driscoll, Tim > Sent: Tuesday, May 3, 2016 12:25 PM > To: dev@dpdk.org > Subject: [dpdk-dev] 16.11 Roadmap >=20 > We were a little late doing this for 16.07, so we're going to try and > communicate our roadmap for future releases earlier. Our aim is to do > this 6 months before a release. Some things will obviously change during > planning/development, so we'll provide an update 4 months before the > release. After that, things should hopefully be relatively stable. >=20 > 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. >=20 >=20 > Cryptodev Scheduler & Packet Reordering: > Add a scheduler to cryptodev which will allow hardware and software > acceleration to be used on the same core. If both are available, the > scheduler will determine whether to use hardware or software > acceleration based on packet size and other factors (TBD). Support > packet reordering in cryptodev so that packet order is maintained when > hardware and software acceleration are combined. >=20 > Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist > Technology) 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, SHA384_HMAC, SHA512, AES-XTS, KASUMI. >=20 > Cryptodev Support for Software Acceleration for Additional Algorithms: > For every algorithm that we support in hardware, provide a software > implementation. This means that an application can always rely on the > cryptodev API to provide the requested service, even if hardware > acceleration is not available. >=20 > Cryptodev Performance Optimization: > Analyze the performance of the cryptodev API, identify bottlenecks, and > optimize where required. >=20 > Generic Classification API: > Create a new API to provide generic filtering capabilities that works > across NICs. This will include a software implementation which can be > used in cases where NICs that don't support all the capabilities of the > API. An RFC will 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 significant community interest/feedback on it, so it > may be deferred until a later release. >=20 > Enhanced Packet Distributor: > Optimize performance of the Packet Distributor library by using vector > instructions and other techniques. >=20 > 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 existing VMs. To address this, both QEMU and vhost-user > need to support client mode (currently only server mode is supported), > which implements reconnection 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 coordinated with the QEMU community. >=20 > Delay Packet Copy in vHost-User Dequeue: > It may be possible to increase vhost-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 investigation is required to > determine how much of a performance gain can be achieved. >=20 > Cuckoo Hash Acceleration using TSX: > Improve performance of Cuckoo Hash using Transactional Synchronization > Extensions (TSX).