DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gal Cohen (Product)" <galco@mellanox.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] DPDK 20.08 Mellanox Roadmap
Date: Mon, 25 May 2020 13:30:38 +0000	[thread overview]
Message-ID: <AM6PR05MB50785AEFFC4F3F4132752A1EC3B30@AM6PR05MB5078.eurprd05.prod.outlook.com> (raw)

Below is Mellanox's roadmap for DPDK20.08, which we are currently working on:

rte_flow API updates:
==================

[1] Extending the DPDK flow action API to enable support of a shared rte_flow_action context:

A modification of a single rte_flow_action context replaces the current approach which requires multiple modifications of (identical) flow actions.

Motivation: When multiple flow rules such as RSS have the same action, this action is cloned and used on each of the flows. Prior to the proposed change, any update to the RSS action (e.g. adding/removing queue) required reconfiguration of all the flows. This re-configuration is non-efficient, and the newly proposed APIs provide means to influence all the relevant flows through a single change in the shared action context that is being used by all the relevant flows.

[2] Support flow-based traffic sampling or mirroring:

Packets of a given classification, can be cloned at a given sampling rate and forwarded to a vport or queue. When the sampling rate is set to 100% the traffic would be completely mirrored.
Once sampled or mirrored, a packet may be bound to an additional action such as mark, encap, decap.
Motivation: Enable monitoring and statistics on classified traffic for business or lawful interception.
Example: Monitoring of hairpined traffic;
[3] Add support for eCPRI header classification.

Motivation: Allow 5G RAN (Radio Access Network) applications to use DPDK for matching and steering traffic based on the eCPRI message header.



Introduce new rte_regex API:

========================
[4] Introduce new API in DPDK to allow injection of regex parsing rules.

Motivation: Provide flexible parsing functionality with limited code changes.

(See DPDK RFC: regexdev: introduce regexdev subsytem)

mlx5 PMD updates:
================
[*] mlx5 PMD will support the rte_flow update changes listed above.



Performance improvement

[5] Add mlx5 PMD use of vectorized instructions when using Striding RQ (MPRQ)



Memory management:

[6] Add mlx5 PMD configuration option (dev-args), allowing control of the cache memory reclaim mode ("reclaim_mem_mode").

Motivation: Allow flexible application decision on how to treat aged cache memory entries. Options are - [1] cache regularly, [2] reclaim the PMD resource, or [3] reclaim both PMD and rdma_core resources.

[7] Add mlx5 PMD configuration option (dev-args), allowing to define the flow-related memory allocation source, either from system (new) or from the hugepage (legacy).



Efficient flow management in process restart:

[8] Add mlx5 PMD support for queue stop/start APIs.

Motivation: Enable support for various process availability scenarios in which a process that is using a queue need to be switched with another process (for example due to process failure/crash or to allow graceful shutdown).
Implemented functions are: rte_eth_dev_tx_queue_stop(),rte_eth_dev_tx_queue_start().



Added support for 5g use cases:

[*] matching on eCPRI header as mentioned in [3]

[9] Add mlx5 PMD support for accurate traffic scheduling.

       Motivation: Allow sending Tx traffic on a predefined timeslot to smooth traffic capacity on end-points that cannot sustain bursts.


Other functionalities:

[10] Add mlx5 PMD support for LACP steering to kernel.

Enable steering of Link Aggregation Control Protocol (LACP) traffic to kernel instead of to DPDK, even for cases in which the DPDK application selected to get all the traffic, such as in promiscuous mode.
Motivation: Allow working in promiscuous mode while using kernel bonding;



testpmd updates:
===============

[*] testpmd will be updated to support the features that described above (eCPRI header classification; flow-based traffic sample or mirroring; adding, changing and using rte_flow_action context).



[11] Add support for IP and Port swapping.

Extending the existing 'macswap' to allow complete 5 tuple update in forwarding action.
Motivation: Improve flexibility in test and application scenarios in forwarding action with updates of 5 tuple.

Best regards,
Gal Cohen


             reply	other threads:[~2020-05-25 13:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 13:30 Gal Cohen (Product) [this message]
2020-06-24 16:55 ` Thomas Monjalon

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=AM6PR05MB50785AEFFC4F3F4132752A1EC3B30@AM6PR05MB5078.eurprd05.prod.outlook.com \
    --to=galco@mellanox.com \
    --cc=dev@dpdk.org \
    /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).