[dpdk-dev] 16.11 Roadmap

[O'Driscoll, Tim]

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 update 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 build 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 Technology) for Additional Algorithms:
Add support for additional algorithms which are supported by Intel(r) QuickAssist Technology but are not currently supported in DPDK. This includes: 3DES_CBC_128/192, KASUMI, NULL, SHA224_HMAC, SHA384_HMAC and AES-GMAC. 

Cryptodev Support for Software Acceleration for Additional Algorithms:
Add support for software implementations of additional crypto algorithms. This 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 software library similar to KASUMI and SNOW3G. 3DES, and potentially other software implementations in future, will not be an optimized implementation, so it will not perform to the same level as other optimized software libraries.

Cryptodev Performance Optimization:
Analyze the performance of the cryptodev API, identify bottlenecks, and optimize 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 Adrien's RFC: http://dpdk.org/ml/archives/dev/2016-July/043365.html), implement support for that API for ixgbe and i40e.
     
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 packet copy on Tx 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.

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Tuesday, May 3, 2016 12:25 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] 16.11 Roadmap
> 
> 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.
> 
> 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
> 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.
> 
> 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.
> 
> 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.
> 
> Cryptodev Performance Optimization:
> Analyze the performance of the cryptodev API, identify bottlenecks, and
> optimize where required.
> 
> 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.
> 
> Enhanced Packet Distributor:
> Optimize performance of the Packet Distributor library by using vector
> instructions and other techniques.
> 
> 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.
> 
> 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.
> 
> Cuckoo Hash Acceleration using TSX:
> Improve performance of Cuckoo Hash using Transactional Synchronization
> Extensions (TSX).