From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 12FDC37B3 for ; Mon, 10 Oct 2016 18:13:45 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2016 09:13:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,325,1473145200"; d="scan'208";a="1042757787" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga001.jf.intel.com with ESMTP; 10 Oct 2016 09:13:44 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.164]) by IRSMSX106.ger.corp.intel.com ([169.254.8.209]) with mapi id 14.03.0248.002; Mon, 10 Oct 2016 17:13:43 +0100 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] 17.02 Roadmap Thread-Index: AdIjEO/XuwgAwtvSSO2S83/x+sibww== Date: Mon, 10 Oct 2016 16:13:42 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA675F11C5@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzMzZTg3YmUtMzdmYS00MThiLWE0M2ItNjY0YWI5MTM4MjQ4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkI3TEdFME93UTI5UWZoSFM0NE45R1JNMWVKakkyOXhXczlCUG9QdFBcL2pJPSJ9 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: Re: [dpdk-dev] 17.02 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: Mon, 10 Oct 2016 16:13:46 -0000 We published our initial roadmap for 17.02 at the end of August. 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. This is our curr= ent plan, which should hopefully remain fairly stable now: Consistent Filter API: Add support for the Consistent Filter API (see http:= //dpdk.org/ml/archives/dev/2016-September/047924.html) for IGB, IXGBE and I= 40E. Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-base= d load balancing library which scales linearly for both lookup and insert w= ith the number of threads or cores. EFD lookup uses a "perfect hashing" sc= heme where only the information needed to compute a key's value (and not th= e key itself) is stored in the lookup table, thus reducing CPU cache storag= e requirements.=20 Extended Stats (Latency and Bit Rate Statistics): Enhance the Extended NIC = Stats (Xstats) implementation to support the collection and reporting of la= tency and bit rate measurements. Latency statistics will include min, max a= nd average latency, and jitter. Bit rate statistics will include peak and a= verage bit rate aggregated over a user-defined time period. This will be im= plemented for IXGBE and I40E. Run-Time Configuration of Packet Type (PTYPE) for I40E: At the moment all p= acket types in DPDK are statically defined. This makes impossible to add ne= w values without first defining them statically and then recompiling DPDK. = The ability to configure packet types at run time will be added for I40E. Packet Distributor Enhancements: Enhancements will be made to the Packet Di= stributor library to improve performance: 1. Introduce burst functionality to allow batches of packets to be sent to = workers. 2. Improve the performance of the flow/core affinity through the use of SSE= /AVX instructions. Add MACsec for IXGBE: MACsec support will be added for IXGBE. Ethdev API pr= imitives will be added to create/delete/enable/disable SC/SA, Next_PN etc. = similar to those used in Linux for the macsec_ops. Sample apps (l3fwd, test= pmd, etc.) will be updated to support MACsec for the IXGBE.=20 Enhance AESNI_GCM PMD: The current AESNI_GCM PMD is limited to AES-128 and = does not support other features such as "any AAD length value". It will be = updated to use a newer GCM implementation supporting AES128/192/256 and oth= er features. Create Crypto Performance Test App: A new app, similar to testpmd, will be = created to allow crypto performance to be tested using any crypto PMD and a= ny supported crypto algorithm. Enable Cipher-Only and Hash-Only Support in AESNI_MB PMD: Support will be a= dded for cipher-only and hash-only operations in the AESNI_MB PMD. Support Chained Mbufs in Cryptodev: Currently, an application using the cry= ptodev API needs to reserve a continuous block of memory for mbufs. Support= will be added for chaining of mbufs in both the QAT and SW PMDs supported = by cryptodev. Optimize Vhost-User Performance for Large Packets: A new memory copy functi= on optimized for core-to-core memory copy which will be added. This will be= beneficial for virtualization cases involving large packets, but it can be= used for other core-to-core cases as well. Support New Device Types in Vhost-User: Support will be added to vhost-user= for new device types including vhost-scsi and vhost-blk. Interrupt Mode Support in Virtio PMD: Support for interrupt mode will be ad= ded to the virtio PMD. Virtio-User as an Alternative Exception Path: Investigate the use of virtio= -user and vhost-net as an alternative exception path to KNI that does not r= equire out of tree drivers. This work is still at an experimental stage, so= it may not be included in 17.02. > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of O'Driscoll, Tim > Sent: Wednesday, August 31, 2016 11:32 AM > To: dev@dpdk.org > Subject: [dpdk-dev] 17.02 Roadmap >=20 > Below are the features that we're planning to submit for the 17.02 > release. We'll submit a patch to update the roadmap page with this info. >=20 > Some things will obviously change during planning/development, so we'll > provide a more detailed update in late September/early October. After > that, things should hopefully be relatively stable. >=20 > 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.02 and make > sure there's no duplication. >=20 >=20 > Consistent Filter API phase 2: Extend support for the Consistent Filter > API that will be first implemented in 16.11 to IGB and FM10K. >=20 > Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow- > based load balancing library which scales linearly for both lookup and > insert with the number of threads or cores. EFD lookup uses a "perfect > hashing" scheme where only the information needed to compute a key's > value (and not the key itself) is stored in the lookup table, thus > reducing CPU cache storage requirements. >=20 > Cryptodev: Additional Software Algorithms: > - Optimize the AES-GCM software PMD. > - Enhance the Intel(r) AES-NI MB PMD to add support for cipher-only and > authentication-only operations. Add support for AES_CBC_MAC, > AES_CMAC_128, AES_GMAC_128. > - Add software support for: 3DES_ECB_128/192, AES_ECB_128/192/256, > AES_F8, AES_XTS, ARC4. >=20 > Run-Time Configuration of Flow Type (PCTYPE) and Packet Type (PTYPE) for > I40E: At the moment all flow types and packet types in DPDK are > statically defined. This makes impossible to add new values without > first defining them statically and then recompiling DPDK. The ability to > configure flow types and packet types at run time will be added for > I40E. >=20 > Extended Stats Latency and Bit Rate Statistics: Enhance the Extended NIC > Stats (Xstats) implementation to support the collection and reporting of > latency and bit rate measurements. Latency statistics will include min, > max and average latency, and jitter. Bit rate statistics will include > peak and average bit rate aggregated over a user-defined time period. > This will be implemented for IXGBE and I40E. >=20 > Hardware QoS for IXGBE and I40E: Implement support for Hardware QoS for > IXGBE and I40E. This involves using DCB so that a PF or VF can receive > packets for each of the Traffic Classes (TCs) based on the User Priority > field (in the VLAN header). Bandwidth on transmit for each TC is > programmable.