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
