DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kinsella, Ray" <mdr@ashroe.eu>
To: Thomas Monjalon <thomas@monjalon.net>,
	"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
	"Singh, Jasvinder" <jasvinder.singh@intel.com>,
	david.marchand@redhat.com
Subject: Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
Date: Wed, 13 Oct 2021 10:43:16 +0100	[thread overview]
Message-ID: <c9689552-7bb9-b7de-55e9-55bb9326b6fc@ashroe.eu> (raw)
In-Reply-To: <1667999.ADG73FIASF@thomas>



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 <thomas@monjalon.net>
>>>>> 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 <jasvinder.singh@intel.com>
>>>>>> ---
>>>>>>  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."

Ray K

  reply	other threads:[~2021-10-13  9:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 12:20 Jasvinder Singh
2021-09-01 13:48 ` Kinsella, Ray
2021-09-03 12:56 ` Zhang, Roy Fan
2021-09-03 13:00 ` Kinsella, Ray
2021-09-27 10:17 ` Thomas Monjalon
2021-10-12 20:34   ` Dumitrescu, Cristian
2021-10-12 21:52     ` Thomas Monjalon
2021-10-13  8:51       ` Kinsella, Ray
2021-10-13  9:40         ` Thomas Monjalon
2021-10-13  9:43           ` Kinsella, Ray [this message]
2021-10-13  9:49             ` Thomas Monjalon
2021-10-13 10:02               ` Kinsella, Ray
2021-10-13 11:11                 ` Bruce Richardson
2021-10-13 11:42                   ` Kinsella, Ray
2021-10-13 11:58                     ` Thomas Monjalon
2021-10-12 20:34 ` Dumitrescu, Cristian
2021-10-13  8:51   ` Kinsella, Ray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c9689552-7bb9-b7de-55e9-55bb9326b6fc@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=cristian.dumitrescu@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jasvinder.singh@intel.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).