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 C087CA0C55; Wed, 13 Oct 2021 13:58:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4C113410EB; Wed, 13 Oct 2021 13:58:16 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 7F7A640E64 for ; Wed, 13 Oct 2021 13:58:15 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 30FE85C00E4; Wed, 13 Oct 2021 07:58:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 13 Oct 2021 07:58:15 -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=fm2; bh= cdFjX+8UXgenqXxF0dka0g6DbKjp7SQoQTdhFj7YVyg=; b=qox954WVY3D+zW0C kUGlXHS8x+jvhSR7dn8U/p883Rg9K1Y/fEj9REUq1FAdFCs7LR9FgYGlg01bIfWP ptfD3HMyx0/pCPSG0ovJeGipSU9PUXHcaoZbkoxZEMctw4dSf6DDxoEevq4ebVx2 qBg0aBDnDAOYvrdTDi7LtTNXvVrEwMkz7CmTR+7TcqfmuKVf7EiCkNPPxVRe0a5E HMeCxKK/dkvUIgHMOKr0tx6dF4oIuku8+GYooIx1lpkjgWjrVrXNSdugj05cgA57 a64ty+OzeaLZu7GP3eLWfsU/QTNyvEWaNSZdxAsoX0yA36RBBgxgzTFsNOkztpH1 WEWkWA== 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=cdFjX+8UXgenqXxF0dka0g6DbKjp7SQoQTdhFj7YV yg=; b=Ov/fSHU1P0N8azqjqCHSDHluN17n2+c3ntb6TlmkYOzSubQTMqX3yS9rN zNqylVKY88g/5QIRPgM2UoJ0b/NK32E10P6YFpnRg6kz0lNgQHRS6HXnhBP4TnIv EQjKwL0hcPC0CgONPiiKooQkAt+5OOw53wpilXTdbbDpjsU69nBWvdjUKkvpoQxH 5ZvG9UjrxqtEXxCyS9ftJppR3o8UslKGoxEZdw6RKHhgJm9zTkrlK8+dbdyjDRyl pOD6GHrB+utIZ2HgtY7EsFn1PX3Lk1jzccHUhwV8Ex9wU6RAl1eQqqgq4s9iWAE0 VaER/E1YgAfFZQ0CMXCKorKpMw7vQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddutddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Oct 2021 07:58:13 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , "Kinsella, Ray" , "Dumitrescu, Cristian" , "Singh, Jasvinder" Cc: "dev@dpdk.org" , "Zhang, Roy Fan" , david.marchand@redhat.com Date: Wed, 13 Oct 2021 13:58:10 +0200 Message-ID: <13850759.ZlXQ0zniox@thomas> In-Reply-To: References: <20210901122007.3885050-1-jasvinder.singh@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API 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" 13/10/2021 13:42, Kinsella, Ray: > On 13/10/2021 12:11, Bruce Richardson wrote: > > On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote: > >> On 13/10/2021 10:49, Thomas Monjalon wrote: > >>> 13/10/2021 11:43, Kinsella, Ray: > >>>> On 13/10/2021 10:40, Thomas Monjalon wrote: > >>>>> 13/10/2021 10:51, Kinsella, Ray: > >>>>>> On 12/10/2021 22:52, Thomas Monjalon wrote: > >>>>>>> 12/10/2021 22:34, Dumitrescu, Cristian: > >>>>>>>> From: Thomas Monjalon > >>>>>>>>> 01/09/2021 14:20, Jasvinder Singh: > >>>>>>>>>> These APIs were introduced in 18.05, therefore removing > >>>>>>>>>> experimental tag to promote them to stable state. > >>>>>>>>>> > >>>>>>>>>> Signed-off-by: Jasvinder Singh > >>>>>>>>>> --- > >>>>>>>>>> lib/pipeline/rte_port_in_action.h | 10 ---------- > >>>>>>>>>> lib/pipeline/rte_table_action.h | 18 ------------------ > >>>>>>>>>> lib/pipeline/version.map | 16 ++++++---------- > >>>>>>>>>> 3 files changed, 6 insertions(+), 38 deletions(-) > >>>>>>>>> > >>>>>>>>> Cristian, please can you check whether you intend to keep these= functions in > >>>>>>>>> future? > >>>>>>>>> If they are candidate to be removed, there is no point to promo= te them. > >>>>>>>> > >>>>>>>> Hi Thomas, > >>>>>>>> > >>>>>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline= API evolves. > >>>>>>>> > >>>>>>>> But removing them requires updating the drivers/net/softnic code= to use the new API, which is not going to be completed in time for release= 21.11. > >>>>>>>> > >>>>>>>> So given this lag, it might be better to simply promote these fu= nctions to stable API now, as Ray suggests, instead of continuing to keep t= hem experimental; then, once these functions are no longer used, then we ca= n remove them, most likely in 22.11. > >>>>>>>> > >>>>>>>> So I will ack these patches, but I am willing to reconsider if y= ou feel strongly against this approach. > >>>>>>> > >>>>>>> I think we should not promote API that we know will disappear soo= n. > >>>>>>> The stable status means something for the users. > >>>>>>> Ray, what is your opinion? > >>>>>>> > >>>>>> > >>>>>> Well - I agree with Cristian (he and I discuss this a few weeks ag= o). > >>>>>> My position is if you are going to maintain an API, that means giv= ing a few guarantees. > >>>>>> The API's have been experimental for 3 years ... at what point do = they mature? > >>>>>> > >>>>>> However, I agree there is two ways to look at this thing, I try to= be pragmatic.=20 > >>>>>> Maturing of any ABI/API is a conversation between a maintainer and= the contributor. > >>>>>> If they strongly feel, it is a pointless exercise - I won't argue.= =20 > >>>>> > >>>>> I think you did't get it. > >>>>> This API will be removed soon. > >>>>> That's why I think it doesn't make sense to make them stable, just = before removing. > >>>>> > >>>> > >>>> Nope, I got it 110% > >>>> I reflected both my opinion as ABI Maintainer, and tried to be pragm= atic about the situation. > >>>> > >>>> As I said "Maturing of any ABI/API is a conversation between a maint= ainer and the contributor. > >>>> If they strongly feel, it is a pointless exercise - I won't argue." > >>> > >>> Sorry, I don't understand your position. > >>> Do you think we should promote functions to stable which are candidat= e to be removed soon? > >>> > >> > >> I am just reflecting the policy here. > >> > >> "An API=E2=80=99s experimental status should be reviewed annually, by = both the maintainer and/or the original contributor. Ordinarily APIs marked= as experimental will be promoted to the stable ABI once a maintainer has b= ecome satisfied that the API is mature and is unlikely to change." > >> > > If an API is planned for removal, then I think it falls under the bucke= t of > > "likely to change", so should not be made non-experimental. Therefore I= 'd > > agree with Thomas view on this - not so much that promoting them is > > pointless, but I'd actually view it as harmful in encouraging use that = will > > be broken in future. > >=20 >=20 > To be clear (again). >=20 > I don't think we should promote functions needlessly, as I said, if other= s decide it is pointless, I won't argue. =20 > I do think if we have a policy, that experimental symbols will mature or = be removed, we should be careful about the exceptions we make, lest the pol= icy becomes irrelevant and ignored.=20 >=20 > Since we have argued this out, endlessly ... we can agree, we have been c= areful about this exception and move on? The patch is set as rejected.