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 D7B8EA0C55; Wed, 13 Oct 2021 12:02:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 92AB5410EB; Wed, 13 Oct 2021 12:02:10 +0200 (CEST) Received: from mail-108-mta99.mxroute.com (mail-108-mta99.mxroute.com [136.175.108.99]) by mails.dpdk.org (Postfix) with ESMTP id 2962B40150 for ; Wed, 13 Oct 2021 12:02:08 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta99.mxroute.com (ZoneMTA) with ESMTPSA id 17c791a1a5a0000b55.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 13 Oct 2021 10:02:06 +0000 X-Zone-Loop: 5b8f37e9c72d1f27317b62643eac6962e06b16fb1b7d X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=N7eCZnvHp3kKMlamKOkjAKhKNgNCU3tAZYfwQrmoI4Y=; b=JQkWpPQ5+7ZLQZWEUWpTBg7Kz9 dAbp5AAALdEWYiP+eOxVvpH7XfhZR+4Jb9yT8hF+2bkycgForm1gBcS27aCW4Cu4xyVbSrKfWyqfV njf8oMqg+Xvrm2QYzPKOaBzRhLhIvjolzU9C6UkN70JMOaIa18a4qK3nCyyAI6rhhoBosrzK/gK8E yyhAWcb5ll8r88bknXLbciMSF+sWRnmafZzr3kvwFfA75Pj4DuoilpUicUn9GvswScspI0rPYwRA+ CsB5fqUIpSZptdThrDqIdJTL1EhRf2s7x9XmHmaQrZQWhHiPC8xOY7/F34ArgN2jZRskENR74a/3i Er+Z7QAg==; To: Thomas Monjalon , "Dumitrescu, Cristian" Cc: "dev@dpdk.org" , "Zhang, Roy Fan" , "Singh, Jasvinder" , david.marchand@redhat.com References: <20210901122007.3885050-1-jasvinder.singh@intel.com> <1667999.ADG73FIASF@thomas> <54472851.rRM0y284jX@thomas> From: "Kinsella, Ray" Message-ID: <6611694b-9293-6727-6f2f-a04148a02e46@ashroe.eu> Date: Wed, 13 Oct 2021 11:02:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <54472851.rRM0y284jX@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, TO_DN_EQ_ADDR_SOME=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, RCPT_COUNT_FIVE=0, MID_RHS_MATCH_FROM=0, NEURAL_SPAM=0] 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" 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 promote 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 functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11. >>>>>> >>>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach. >>>>> >>>>> I think we should not promote API that we know will disappear soon. >>>>> 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 ago). >>>> My position is if you are going to maintain an API, that means giving 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. >>>> 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. >>> >>> 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 pragmatic about the situation. >> >> As I said "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." > > Sorry, I don't understand your position. > Do you think we should promote functions to stable which are candidate to be removed soon? > I am just reflecting the policy here. "An API’s 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 become satisfied that the API is mature and is unlikely to change." then, "The promotion or removal of symbols will typically form part of a conversation between the maintainer and the original contributor.". As I said, in my email above ... "Maturing of any ABI/API is a conversation between a maintainer and the contributor. If they strongly feel, it is a pointless exercise [to make the symbols stable] - I won't argue. Or to be _abundantly clear_ ... I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue. 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 policy becomes irrelevant and ignored. Ray K