From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AE199A0C45; Thu, 25 Nov 2021 13:50:50 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5BE06426E2; Thu, 25 Nov 2021 13:50:50 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 42D0D426E4 for <dev@dpdk.org>; Thu, 25 Nov 2021 13:50:48 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AFA7D5C01AE; Thu, 25 Nov 2021 07:50:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 25 Nov 2021 07:50:46 -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= bzrTIu9RKMayjJHdFWgyb2QN53HdvT4coAbldRHxuNk=; b=Vjdf29Kiad6NH3i5 q5fwIknFTMGYZpgA/6i/2HaQQ5JTtX5Cq4cyEVS4FGOozKf5YxL5ajMV9gyahjTy zkDePhwq1pmWKqJE3Riezx0aZfoQO3P3zBbzUCcpOYrSfdtB3GRB390cgxCzAthh LGC3+gXG9Xp2+WkZrQur3LfoK8ZtE/SrFY467BJ+6NsGMonSKuXeLAJMJwkb399k PD5mQmE/SQ0omPuOP9jMnH79e+SVT34z1sdtS3UAlHTMfhn7/qiInfBNULXksVZs D/9lpQozx1twxqf44lHj+l6agpoYyKMd7waECHvP6WyBeNzcM1mRGOInTICy2b3C x6n9hQ== 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=bzrTIu9RKMayjJHdFWgyb2QN53HdvT4coAbldRHxu Nk=; b=Sg87Faz7ieSSIwb3XriDiEzd66m9YOYTkaAwPCvzyz98Q3bjBbxvIeCfu yOnuGLDAsSxk8BTX1JR90UZk5j0ozn91Ln36TI3wysEEQgPPT1h2RYT10hRgY8qc GFlVd7gMjy6sWIdKrCnainto8yFaTtHcDsjTahgvFFjpsrLmq2oGXX0xcYVFr9Fo BA92imKsY3OjwA8v6eOx7vy9kQBr6o5706AYpymSzC+9J6CmNWvwEPGyV3AHpnn4 jgI0qwOXS5IwSOTv5LdfoYAKa/EwkKc+M2FvS0ANGnYSXlDMTZ8JatphjdQ/vj6r cWhwjt4FKqn1uQZDyvZ/zzu8u3xWw== X-ME-Sender: <xms:poafYdJOxXWafEjH2xOXCdexpH_QUUZliLXW1coUGjZMpxq1L7-k3Q> <xme:poafYZJXYXdVzG5b022BPn9ULtEJdnUStcqYTdc8HpeFaZLH0j1nFQhxHHiChzjnB H6zaM3ncESVQKDQuw> X-ME-Received: <xmr:poafYVvNF5dk1kDADQl0sZ88IJhpTwxj91M0rvKKMhBY5Sr-8x2Sl1nGufUjZUtl9C_HyiEkSJpHIhYHt75e_VxpGA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedtgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:poafYeadaTawJADMZZAx9YqZ-oUtZ6G-sk1kJeS9-TRLsL8dvL809g> <xmx:poafYUajIE9JeY8L-buFfeep363RB7EOdxQVBZ6C3j3QerFeOHS0iA> <xmx:poafYSAFBb0P7oETJuKoQKbBAtUM_oPDNAYhpSVXcSTw97zp2QouIQ> <xmx:poafYTyKaQ5NporLkDU6QJiWImqAwrtYnYFX-B8pALk_1JTEC8cuHg> Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Nov 2021 07:50:45 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: Ray Kinsella <mdr@ashroe.eu>, Ori Kam <orika@nvidia.com>, Ferruh Yigit <ferruh.yigit@intel.com> Cc: dev@dpdk.org, Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, David Marchand <david.marchand@redhat.com> Subject: Re: [PATCH v3] ethdev: deprecate header fields and metadata flow actions Date: Thu, 25 Nov 2021 13:50:43 +0100 Message-ID: <1919853.K5XBjjXOGd@thomas> In-Reply-To: <2ad462dd-11d0-33f0-778e-bd3f00e5e668@intel.com> References: <20211123075940.5521-1-viacheslavo@nvidia.com> <20211124153756.12198-1-viacheslavo@nvidia.com> <2ad462dd-11d0-33f0-778e-bd3f00e5e668@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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org 25/11/2021 13:31, Ferruh Yigit: > On 11/24/2021 3:37 PM, Viacheslav Ovsiienko wrote: > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > > index 6d087c64ef..d04a606b7d 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -101,6 +101,20 @@ Deprecation Notices > > is deprecated as ambiguous with respect to the embedded switch. The use of > > these attributes will become invalid starting from DPDK 22.11. > > > > +* 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. > > + > > +* 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. > > + > > +* ethdev: Actions ``OF_SET_VLAN_VID``, ``OF_SET_VLAN_PCP`` are deprecated > > + as superseded by generic MODIFY_FIELD action. > > + > > > I have a question about ABI/API related issue for rte_flow support, > > If a driver removes an flow API item/action support, it directly impacts > the user application. The application previously working may stop working > and require code update, this is something we want to prevent with > ABI policy. And this kind of changes are not caught by our tools. > > Do we have a process to deprecate/remove a flow API item/action support? > Like they can be only removed on ABI break release... If possible, we should avoid removing them, or dropping support in a driver. I think removing a feature could be considered only if not too many drivers use it, or if it becomes a real burden to maintain.