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 C27CDA0C55; Wed, 13 Oct 2021 13:12:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 72730410DA; Wed, 13 Oct 2021 13:12:09 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id D630640E64 for ; Wed, 13 Oct 2021 13:12:06 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10135"; a="208202413" X-IronPort-AV: E=Sophos;i="5.85,370,1624345200"; d="scan'208";a="208202413" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2021 04:12:03 -0700 X-IronPort-AV: E=Sophos;i="5.85,370,1624345200"; d="scan'208";a="524589800" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.25.241]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 13 Oct 2021 04:12:00 -0700 Date: Wed, 13 Oct 2021 12:11:57 +0100 From: Bruce Richardson To: "Kinsella, Ray" Cc: Thomas Monjalon , "Dumitrescu, Cristian" , "dev@dpdk.org" , "Zhang, Roy Fan" , "Singh, Jasvinder" , david.marchand@redhat.com Message-ID: References: <20210901122007.3885050-1-jasvinder.singh@intel.com> <1667999.ADG73FIASF@thomas> <54472851.rRM0y284jX@thomas> <6611694b-9293-6727-6f2f-a04148a02e46@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6611694b-9293-6727-6f2f-a04148a02e46@ashroe.eu> 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 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. /Bruce