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 25639A0C55; Wed, 13 Oct 2021 13:42:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E6270410DA; Wed, 13 Oct 2021 13:42:14 +0200 (CEST) Received: from mail-108-mta148.mxroute.com (mail-108-mta148.mxroute.com [136.175.108.148]) by mails.dpdk.org (Postfix) with ESMTP id 6BB5D40E64 for ; Wed, 13 Oct 2021 13:42:13 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta148.mxroute.com (ZoneMTA) with ESMTPSA id 17c7975b0b30000b55.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 13 Oct 2021 11:42:08 +0000 X-Zone-Loop: 27bab615cb26e682afee2319773319f0db0376d65913 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=+7IeQLVnq1ENPT3QtIVQcj8aN0qVzNg1q9VwEgmN2Vw=; b=hl32GHmBFUNJbOLa+FAILYz6/Y CBa3mDDbppw2CxL33ltkXGK4MpJXQJdNo+EFdsZ3KmOzHe5/Pwxg9uP69vmI/nv6rJBFjLzYKUgPU 9A2Rvw9rY2dp8vSvSqNXXY12ACbYx1OaWoA7xDR1eMd7aFUzsjn4VxvjeW2f5S5q6FyrFm3h488hB xzkzKs3v64TsrxYfITmi5QstMbn2+9xguHStXjXJII4vsjN6e+5BjfwsHR8ahKkotZ8Nrkb0Lv6QU nTzn56ccsbNNMRyxym9PtNGHCNWbuhfGBm9Q0LSJid7NUhDjfnO5pGUlgDBX8RyIGNOsD8Q68DgoW Pf8pg31A==; To: Bruce Richardson Cc: Thomas Monjalon , "Dumitrescu, Cristian" , "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> <6611694b-9293-6727-6f2f-a04148a02e46@ashroe.eu> From: "Kinsella, Ray" Message-ID: Date: Wed, 13 Oct 2021 12:42:03 +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: 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, RCPT_COUNT_SEVEN=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0, MID_RHS_MATCH_FROM=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 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 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." >> > If an API is planned for removal, then I think it falls under the bucket 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. > To be clear (again). 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. Since we have argued this out, endlessly ... we can agree, we have been careful about this exception and move on? Ray K