[dpdk-dev] DPDK 21.05 NVIDIA Mellanox Roadmap

[dpdk-dev] DPDK 21.05 NVIDIA Mellanox Roadmap

[Asaf Penso]

Below is NVIDIA Mellanox's roadmap for DPDK21.05, on which we are currently working:

rte_flow new APIs:
===============
[1]Support a new action offload which perform connection tracking window validation.
Motivation:
TCP connection tracking is needed for many applications that act as a mediator and perform forwarding. The new offload connection tracking(CT) window validation is used for enforcing TCP protocol adherence.
It also enforces several sanity checks for TCP packets like the validity of L3 and L4 headers as well as the accuracy of L3 and L4 checksum.
The new offload action API will provide means to create, configure, query, and modify the connection tracking object by a SW application. It will support a bi-directional, cross vport TCP handshake in an optimized manner
 
[2]Add support for matching based on sanity checks of TCP packets. Able to match the validity of L3 and L4 headers as well as L3 checksum and L4 checksum.
Motivation:
Allow TCP connection tracking flow to intercept corrupted packets before they alter the connection tracking object. An application may match on such cases and handle differently than regular route(e.g drop or pass to SW queue
 
[3]Extend meter capabilities with the concept of meter policy
Motivation:
Extend meter capabilities to add support for a shared meter policy. A meter policy is an object that can be shared among different meters. It provides the ability to associate different actions per color Red/Yellow/Green and thus use a meter as a steering mechanism. The first implementation will support queue, rss, jump, mark, and set_tag actions. Given the fact that the policy is shared across many meter flows a performance gain is also expected. 
rte API will be augmented with an additional create meter API to make use of the new policy object.
                           
[4]Add support for writing information related to a single rte flow
Motivation: 
Allow finely grained debug of how flows are represented in the HW. Previously support was added to dump all rte flows using 'flow dump <port> all <output_file>. Now we are extending to support single flow dump using flow dump <port> rule <rule_id> <output_file>


rte_mtr new APIs
===============
[5] add support for a meter profile that enable packet per second metering
Motivation:
Provide flexibility to applications that would like to meter based on packets per second granularity on top of byte per second granularity that exist today as part of meter profile.
 

mlx5 PMD updates: 
================
mlx5 PMD will support the rte_flow update changes listed above and below
 
[6]Extend support for VLAN pop on egress direction and VLAN push on ingress direction
Motivation:
Some applications like firewalls, need to alter the routing information bi-directionally. Today mlx5 PMD supports VLAN pop on ingress and VLAN push on ingress and the intention here is the augment with the corresponding pop/push actions.

[7]Add support for rte_security API
Motivation: enable IPsec inline offload to be used in conjunction with other rte flow API to enable inline encrypt/decrypt of packets. Mlx5 will support Encapsulating Security Payload(ESP) with ConnectX-6 Dx and BlueField-2 

[8]Add support for power saving in rx queues
Motivation: support for umwait command to enable reduction of power consumption if no packets are received.
 
[9]Add support for using HW configured timestamp format 
Motivation: modify the pmd to use the timestamp format based on HW ability - either UTC or free-running


New PMDs:
==============
[10]Implement look aside AES-XTS encryption/decryption PMD over BlueField-2 SmartNIC and ConnectX-6 Dx to support existing rte_cryptodev API


Regex PMD updates:
=================
[11]Added support for regex(regular expression engine in BlueField-2  with chained mbuf   
Motivation: Allow  regex to handle jobs that require a multiple chained mbuf jobs efficiently 


testpmd updates: 
================
testpmd updated to support the changes listed above
 

flow-perf updates:
================
enhance flow-perf application to support the connection tracking window validation offload

Re: [dpdk-dev] DPDK 21.05 NVIDIA Mellanox Roadmap

[Thomas Monjalon]

This roadmap has been integrated in the web page
	https://core.dpdk.org/roadmap/#2105


01/03/2021 20:17, Asaf Penso:
> Below is NVIDIA Mellanox's roadmap for DPDK21.05, on which we are currently working:
> 
> rte_flow new APIs:
> ===============
> [1]Support a new action offload which perform connection tracking window validation.
> Motivation:
> TCP connection tracking is needed for many applications that act as a mediator and perform forwarding. The new offload connection tracking(CT) window validation is used for enforcing TCP protocol adherence.
> It also enforces several sanity checks for TCP packets like the validity of L3 and L4 headers as well as the accuracy of L3 and L4 checksum.
> The new offload action API will provide means to create, configure, query, and modify the connection tracking object by a SW application. It will support a bi-directional, cross vport TCP handshake in an optimized manner
>  
> [2]Add support for matching based on sanity checks of TCP packets. Able to match the validity of L3 and L4 headers as well as L3 checksum and L4 checksum.
> Motivation:
> Allow TCP connection tracking flow to intercept corrupted packets before they alter the connection tracking object. An application may match on such cases and handle differently than regular route(e.g drop or pass to SW queue
>  
> [3]Extend meter capabilities with the concept of meter policy
> Motivation:
> Extend meter capabilities to add support for a shared meter policy. A meter policy is an object that can be shared among different meters. It provides the ability to associate different actions per color Red/Yellow/Green and thus use a meter as a steering mechanism. The first implementation will support queue, rss, jump, mark, and set_tag actions. Given the fact that the policy is shared across many meter flows a performance gain is also expected. 
> rte API will be augmented with an additional create meter API to make use of the new policy object.
>                            
> [4]Add support for writing information related to a single rte flow
> Motivation: 
> Allow finely grained debug of how flows are represented in the HW. Previously support was added to dump all rte flows using 'flow dump <port> all <output_file>. Now we are extending to support single flow dump using flow dump <port> rule <rule_id> <output_file>
> 
> 
> rte_mtr new APIs
> ===============
> [5] add support for a meter profile that enable packet per second metering
> Motivation:
> Provide flexibility to applications that would like to meter based on packets per second granularity on top of byte per second granularity that exist today as part of meter profile.
>  
> 
> mlx5 PMD updates: 
> ================
> mlx5 PMD will support the rte_flow update changes listed above and below
>  
> [6]Extend support for VLAN pop on egress direction and VLAN push on ingress direction
> Motivation:
> Some applications like firewalls, need to alter the routing information bi-directionally. Today mlx5 PMD supports VLAN pop on ingress and VLAN push on ingress and the intention here is the augment with the corresponding pop/push actions.
> 
> [7]Add support for rte_security API
> Motivation: enable IPsec inline offload to be used in conjunction with other rte flow API to enable inline encrypt/decrypt of packets. Mlx5 will support Encapsulating Security Payload(ESP) with ConnectX-6 Dx and BlueField-2 
> 
> [8]Add support for power saving in rx queues
> Motivation: support for umwait command to enable reduction of power consumption if no packets are received.
>  
> [9]Add support for using HW configured timestamp format 
> Motivation: modify the pmd to use the timestamp format based on HW ability - either UTC or free-running
> 
> 
> New PMDs:
> ==============
> [10]Implement look aside AES-XTS encryption/decryption PMD over BlueField-2 SmartNIC and ConnectX-6 Dx to support existing rte_cryptodev API
> 
> 
> Regex PMD updates:
> =================
> [11]Added support for regex(regular expression engine in BlueField-2  with chained mbuf   
> Motivation: Allow  regex to handle jobs that require a multiple chained mbuf jobs efficiently 
> 
> 
> testpmd updates: 
> ================
> testpmd updated to support the changes listed above
>  
> 
> flow-perf updates:
> ================
> enhance flow-perf application to support the connection tracking window validation offload