From: Thomas Monjalon <thomas@monjalon.net>
To: "Gal Cohen (ProdM)" <galco@nvidia.com>,
Shy Shyman <shys@nvidia.com>, Asaf Penso <asafp@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK 21.05 NVIDIA Mellanox Roadmap
Date: Mon, 15 Mar 2021 14:40:07 +0100 [thread overview]
Message-ID: <5963511.Bay49qIvfO@thomas> (raw)
In-Reply-To: <DM5PR12MB2406612A7DD1E6BEE0732923CD9A9@DM5PR12MB2406.namprd12.prod.outlook.com>
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
prev parent reply other threads:[~2021-03-15 13:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 19:17 Asaf Penso
2021-03-15 13:40 ` Thomas Monjalon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5963511.Bay49qIvfO@thomas \
--to=thomas@monjalon.net \
--cc=asafp@nvidia.com \
--cc=dev@dpdk.org \
--cc=galco@nvidia.com \
--cc=shys@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).