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 B5FE8A0C52; Wed, 24 Nov 2021 15:56:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2AF0C41158; Wed, 24 Nov 2021 15:56:35 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id B085F41154 for ; Wed, 24 Nov 2021 15:56:33 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 48EDB5C01EE; Wed, 24 Nov 2021 09:56:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 24 Nov 2021 09:56:31 -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= Gwd42GpJ+yI8WPwd4Y653Nt8fvf3GzML4jZhtZotN6Q=; b=qtx1Gupre6ylpEWc S/yMTBlGuTdx8lBRdXIxzSzcRstRJTEcdCKzPUBJEQMTqiuQu9S+SgJF85k9279W /oK2PAaJjCEUGxTyjoDLTfPx7mctG0pyndt2fLgwbqpjp/8wdSeh5VXTsvcZMcLJ gRaL6YKBgy//jhySNmoaPK1bKVP27jGjCskA6Geer5T/JloqCThxzdoNu6TOQd+d rwDhn1Uz6B0gIsVWuHiA8qpMzD3mMz28VSltTDNq0ekMY0JWi1HzJ+z02K33d3Xq cfpmXMh2RLrHrzKp0pmQFt86CenYAMtpJ4fIoRLB94mElwJjJf/HUBrxZl4TJIMA fZn2aw== 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=Gwd42GpJ+yI8WPwd4Y653Nt8fvf3GzML4jZhtZotN 6Q=; b=Jcn/LW980v15ZJTxhNm+sdb1Xs21YrK29SZqnwabKa85Nm3eIR4FQxAsm bvbT7T4juJqDo3cbVpU3LVHju0WgYmplDPSLTMIRrpGB6y1p4gto1Qo4WLMyK01w DISn32fssjNMl96utSHaW6DdtL+Tvv+b4doq+0FlidzLcouVpPrKuZDuzWEwCN1y yTB9jOOW4krmOgPxkxn9UH+aeS+3e57ohYW4pa3D4gVLXRWEfRltIfwtdUggXv4d +XV0o517qWYt6Di04N5Xy0dGjnasYWTlehweWMQ5Sqwqkxr0HubPhSCm3o24g/gI hi05pAKDADDk/cs0HN2ZNaLhkMWNA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrgeekgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Nov 2021 09:56:29 -0500 (EST) From: Thomas Monjalon To: Viacheslav Ovsiienko Cc: dev@dpdk.org, ferruh.yigit@intel.com, andrew.rybchenko@oktetlabs.ru, ajit.khaparde@broadcom.com, jerinj@marvell.com, hemant.agrawal@nxp.com Subject: Re: [PATCH v2] ethdev: deprecate header fields and metadata flow actions Date: Wed, 24 Nov 2021 15:56:27 +0100 Message-ID: <4654746.vG6ePZFYC7@thomas> In-Reply-To: <20211124080610.2430-1-viacheslavo@nvidia.com> References: <20211123075940.5521-1-viacheslavo@nvidia.com> <20211124080610.2430-1-viacheslavo@nvidia.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 +Cc some maintainers 24/11/2021 09:06, Viacheslav Ovsiienko: > There generic RTE_FLOW_ACTION_TYPE_MODIFY_FIELD action was s/There/The/ > introduced by [1]. This action provides the unified way s/the/an/ > 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 bnxt* > RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL bnxt* > RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL bnxt* > RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL bnxt*, sfc > RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT bnxt* > RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN bnxt* > 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 bnxt*, cxgbe, mlx5 > RTE_FLOW_ACTION_TYPE_SET_IPV6_DST bnxt*, cxgbe, mlx5 > RTE_FLOW_ACTION_TYPE_SET_TP_SRC bnxt, cxgbe, mlx5 > RTE_FLOW_ACTION_TYPE_SET_TP_DST bnxt, cxgbe, mlx5 > RTE_FLOW_ACTION_TYPE_DEC_TTL bnxt, mlx5, sfc > RTE_FLOW_ACTION_TYPE_SET_TTL bnxt*, mlx5 > RTE_FLOW_ACTION_TYPE_SET_MAC_SRC bnxt*, cxgbe, mlx5 > RTE_FLOW_ACTION_TYPE_SET_MAC_DST bnxt*, cxgbe, mlx5 > RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ bnxt*, mlx5 > RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ bnxt*, mlx5 > RTE_FLOW_ACTION_TYPE_INC_TCP_ACK bnxt*, mlx5 > RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK bnxt*, 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 > > [bnxt*] means the PMD source code references the action, but there > is no support implemented (actions rejected with ENOTSUP error) You can drop these "bnxt*", it is not relevant. > 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 What means "interrelated" here? > and supported by multiple PMDs and supposed not to be deprecated. I think it should be deprecated but not removed, so users can be aware of the possible (better) replacement. > Signed-off-by: Viacheslav Ovsiienko [...] > Action: ``OF_SET_MPLS_TTL`` > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > +This action is deprecated as there are no PMDs supporting this. The true reason is that it is replaced. I think you should mention the replacement for each action. [...] > Action: ``OF_DEC_NW_TTL`` > ^^^^^^^^^^^^^^^^^^^^^^^^^ > +This action is deprecated. Consider: > + - `Action: MODIFY_FIELD`_ The syntax is surprising. Please make it a single line: This action is deprecated. Consider `Action: MODIFY_FIELD`_. [...] > +* ethdev: Actions ``OF_SET_MPLS_TTL``, ``OF_DEC_MPLS_TTL``, ``OF_SET_NW_TTL``, > + ``OF_COPY_TTL_OUT``, ``OF_COPY_TTL_IN`` are deprecated as not supported by > + PMDs, will be removed in DPDK 22.11. +1 > +* ethdev: Actions ``OF_DEC_NW_TTL``, ``SET_IPV4_SRC``, ``SET_IPV4_DST``, > + ``SET_IPV6_SRC``, ``SET_IPV6_DST``, ``SET_TP_SRC``, ``SET_TP_DST``, > + ``DEC_TTL``, ``SET_TTL``, ``SET_MAC_SRC``, ``SET_MAC_DST``, ``INC_TCP_SEQ``, > + ``DEC_TCP_SEQ``, ``INC_TCP_ACK``, ``DEC_TCP_ACK``, ``SET_IPV4_DSCP``, > + ``SET_IPV6_DSCP``, ``SET_TAG``, ``SET_META`` are deprecated as superseded > + by generic MODIFY_FIELD action, will be removed in DPDK 22.11. +1 [...] > /** > + * @deprecated > + * @see RTE_FLOW_ACTION_TYPE_MODIFY_FIELD > + * > * Implements OFPAT_SET_MPLS_TTL ("MPLS TTL") as defined by the > * OpenFlow Switch Specification. > * +1 for this comment on each action. I have minor comments, but overrall, Acked-by: Thomas Monjalon