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 F2D23A0C45; Thu, 25 Nov 2021 14:06:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BE394426F2; Thu, 25 Nov 2021 14:06:45 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 17CEF426E3 for ; Thu, 25 Nov 2021 14:06:44 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B76725C00DD; Thu, 25 Nov 2021 08:06:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 25 Nov 2021 08:06:43 -0500 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=fm2; bh= Ot9GOOf3xVYVUh46j8j8qIILhNdfiZSb+vMhniT06ns=; b=I+mIRldN8hM69mVj NaifgK72PLjhdmZ+PHvtIeNBujY5HHzd+M1+cxNMaCnPjNd7TiF/dFTkVFC2FeYO vDkPPgY+M2Y1L3kJlqccvMmCX2tpFwI8o8KzkhBgRqpgQ4qKfY3Dp1RXXVsk64dB 9U3bPZT87fM5JLxfTeMKfqKdOaenL6hkdCna+OkYChdXdW3v26EgB8/dn7cH3dua Pam2HTWsHwGrtulxAL6B31Jqj+ITggD3DQzUW2vIyuDpi18W1KImyfUJtflSyy29 HOJmG+i60/4I43Sa56jcrTxQGGOG+EPXLSBmN28mI+1Y7aeuNkwMg6+B3QWX5bG8 /X5Wuw== 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=fm1; bh=Ot9GOOf3xVYVUh46j8j8qIILhNdfiZSb+vMhniT06 ns=; b=DC0RERqz1Rjn8qeTlW4NNPFRXLHPoPjixBZ72DvFOXRPR5IgCjVzbIEa3 H8Ws1c1UzBntJ/gdmocQwTD7GkS0MnHwDmOMYo9qcHgRQey6PB35Fp+EF8D6m246 T9hXBC+krG91r69ctN2FL1VDocu0p8SKm0ywUE5yw6LIKhab859WiFdqqDBMqNq0 foUqvwBTaZowFbZa3iAbjL40V6NB5Wv3Nr3kAuJSVFHE2wY6eYMoVPqahPSXP6RG EUOxtPTUL5UdrYNKHw3sBvPRPAmRTK6NBODnVAwUGABWVRxQkocf1PYYcDXmMac5 E3L9c93Ta6eDYXaYXEKPF8zvPo0xA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedtgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeehkefhlefgueduteekkedvgeejkedthfejjeeffeffffetjeevueei ffetkeeffeenucffohhmrghinhepuddurdhithenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Nov 2021 08:06:42 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko , Ajit Khaparde , Somnath Kotur , Rahul Lakkireddy , Viacheslav Ovsiienko , Ferruh Yigit Cc: dev@dpdk.org, orika@nvidia.com Subject: Re: [PATCH v3] ethdev: deprecate header fields and metadata flow actions Date: Thu, 25 Nov 2021 14:06:40 +0100 Message-ID: <1989679.70EXCg8c8L@thomas> In-Reply-To: <0e5753c9-85c3-1dc1-69d8-460cb0a7b5a4@intel.com> References: <20211123075940.5521-1-viacheslavo@nvidia.com> <20211124153756.12198-1-viacheslavo@nvidia.com> <0e5753c9-85c3-1dc1-69d8-460cb0a7b5a4@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 25/11/2021 12:53, Ferruh Yigit: > On 11/24/2021 3:37 PM, Viacheslav Ovsiienko wrote: > > The generic RTE_FLOW_ACTION_TYPE_MODIFY_FIELD action was > > introduced by [1]. This action provides an unified way > > to perform various arithmetic and transfer operations over > > packet network header fields and packet metadata. > > > > [1] commit 641dbe4fb053 ("net/mlx5: support modify field flow action") > > > > On other side there are a bunch of multiple legacy actions, > > that can be superseded by the generic modify field action: > > > > RTE_FLOW_ACTION_TYPE_OF_SET_MPLS_TTL > > RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL > > RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL > > RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL sfc > > RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT > > RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN > > RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC bnxt, cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_SET_IPV4_DST bnxt, cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_SET_IPV6_DST cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_SET_TP_SRC cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_SET_TP_DST cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_DEC_TTL mlx5, sfc > > RTE_FLOW_ACTION_TYPE_SET_TTL mlx5 > > RTE_FLOW_ACTION_TYPE_SET_MAC_SRC cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_SET_MAC_DST cxgbe, mlx5 > > RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ mlx5 > > RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ mlx5 > > RTE_FLOW_ACTION_TYPE_INC_TCP_ACK mlx5 > > RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK mlx5 > > RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP mlx5 > > RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP mlx5 > > RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID bnxt, cnxk, cxgbe, enic, > > mlx5, octeontx2, sfc > > RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP bnxt, cnxk, cxgbe, enic, > > mlx5, octeontx2, sfc > > RTE_FLOW_ACTION_TYPE_SET_TAG mlx5 > > RTE_FLOW_ACTION_TYPE_SET_META mlx5 > > > > This note deprecates the following RTE Flow actions: > > 1. As not supported by any of PMDs: > > > > RTE_FLOW_ACTION_TYPE_OF_SET_MPLS_TTL > > RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL > > RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL > > RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT > > RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN > > > > 2. As supposed to be replaced by generig field modify action: > > RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL > > RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC > > RTE_FLOW_ACTION_TYPE_SET_IPV4_DST > > RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC > > RTE_FLOW_ACTION_TYPE_SET_IPV6_DST > > RTE_FLOW_ACTION_TYPE_SET_TP_SRC > > RTE_FLOW_ACTION_TYPE_SET_TP_DST > > RTE_FLOW_ACTION_TYPE_DEC_TTL > > RTE_FLOW_ACTION_TYPE_SET_TTL > > RTE_FLOW_ACTION_TYPE_SET_MAC_SRC > > RTE_FLOW_ACTION_TYPE_SET_MAC_DST > > RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ > > RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ > > RTE_FLOW_ACTION_TYPE_INC_TCP_ACK > > RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK > > RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP > > RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP > > RTE_FLOW_ACTION_TYPE_SET_TAG > > RTE_FLOW_ACTION_TYPE_SET_META > > > > The VLAN set actions are interrelated to VLAN header insertion/removal > > and supported by multiple PMDs and supposed to be just deprecated but > > not be removed in 22.11. > > > > Why not remove them for v22.11? Do you think PMDs can't change the > existing implementation until 22.11? > > > Signed-off-by: Viacheslav Ovsiienko > > > > -- > > v2 - deprecation.rst is updated > > v3 - doc comments addressed > > - commit message comments addressed > > - SET_VLAN_VID and SET_VLAN_PCP actions deprecated, but will not > > be removed in 22.11 > > Deprecated symbols are to prevent new code using them, but for this case > there is no alternative, since PMDs still don't support > 'RTE_FLOW_ACTION_TYPE_MODIFY_FIELD' yet. This patch is not preventing new code using old actions, there are just comments to point to the new direction. > This patch is forcing users to use deprecated actions (except from mlx). I don't get it. It is encouraging to use the new generic action, which is supported only by mlx5 for now. > What about a slight change: > 1- In this release, update header/document as 'RTE_FLOW_ACTION_TYPE_MODIFY_FIELD' > is preferred way if supported. Instead of deprecating old ones. Deprecation is just a comment, clearly showing that it may be removed in future. In my opinion, it makes the message simple and clear. > 2- Have an agreement with PMD maintainers to switch to new action before v22.11, > and don't accept old action implementation in PMDs anymore. > Based on agreement update 'deprecation.rst' in this release to note that > old actions will be removed on v22.11. > (It would be good to have a check to prevent old actions merged during that time.) Not sure I get it. You want to remove VLAN actions? I think it is premature. > 3- In v22.11, remove old actions, the PMDs that don't support MODIFY_FIELD > action will lose the feature. The VLAN actions are probably already used a lot in the field. I would consider removing them only if it becomes a burden to maintain.