From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 147EAA054F; Mon, 15 Mar 2021 14:40:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 00E91242666; Mon, 15 Mar 2021 14:40:14 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id CB12B4003C for ; Mon, 15 Mar 2021 14:40:12 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 719815C017F; Mon, 15 Mar 2021 09:40:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 15 Mar 2021 09:40:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= l7Zws82g6xU1JJTivULDIPx+86GvqwmC6U+VcTuv7+s=; b=2wP+H2jgrz6yGqzI i/Qstti7hNhsHCgIq1VGvD8FPgX7oeGz4LdH3CEcQ0QyhqC7uWezWghvXntjYcGQ mhvGZXfgmT48yw51bg4S5XtbynrvNxp1lSyphy2voNQD5WpnSDcLERB4v4uEJAGx uujNkcHgjzjjxWOXB4JYf1Jx9a3lzEhhITtUlwsOMPTjvE+pANNy3ySSuaMUg3/e PytJIAF0sDD33QQ7mqESc/RDm7XKmn1LV6+TB9dCGXrGvC4QYElidk8hPQYBecIC aIeQMF3drOrxAetJX5VoQ9sx1WYmZEdVdD6fgsa6V36hv07yjcZ693FQB90hS2g3 D6XzWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=l7Zws82g6xU1JJTivULDIPx+86GvqwmC6U+VcTuv7 +s=; b=GJAZOvm+Gcd/E5wkcfdq/mxmErUj1AeCukUHV/rJFSgKmuWcw8l1qxTRf SJb6pVUaWJZYB+vA804ZXzwwjzB6gV1Y3KVsNgscpSRQGf6zNPQzweQHCTOU1VG3 9suy9kBReBwHiIL/8a4+rnSGXg8qQSJzHWgNaszm7k/ZaVyBh508jtxifd3OcCr5 5PslPgQdXowZRiDoPRkmImz/bA/8c9j33o+Mv0jDQrcVwMjD7u9Q12lTgxNEN76y AIUvLMNPYo1uIDYjeXqJiZ0UBc6kYGwz1bOJ6sAG9ajRRea2ta68v6n2f4L/IE6r 00j4o+urPscxzAFh1H/nxwjq+PtRA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvledgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A858240068; Mon, 15 Mar 2021 09:40:09 -0400 (EDT) From: Thomas Monjalon To: "Gal Cohen (ProdM)" , Shy Shyman , Asaf Penso Cc: "dev@dpdk.org" Date: Mon, 15 Mar 2021 14:40:07 +0100 Message-ID: <5963511.Bay49qIvfO@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] DPDK 21.05 NVIDIA Mellanox Roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 all . Now we are extending to support single flow dump using flow dump rule > > > 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