[dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Eelco Chaudron]

Moved RFC4115 APIs to none experimental as they have been there
since 19.02. Also, these APIs are the same as the none RFC4115 APIs.

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
 lib/librte_meter/rte_meter.h           |    6 ------
 lib/librte_meter/rte_meter_version.map |    4 ++--
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index d69b118..62c8c1e 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -140,7 +140,6 @@ struct rte_meter_trtcm_rfc4115_params {
  * @return
  *    0 upon success, error code otherwise
  */
-__rte_experimental
 int
 rte_meter_trtcm_rfc4115_profile_config(
 	struct rte_meter_trtcm_rfc4115_profile *p,
@@ -187,7 +186,6 @@ struct rte_meter_trtcm_rfc4115_params {
  * @return
  *    0 upon success, error code otherwise
  */
-__rte_experimental
 int
 rte_meter_trtcm_rfc4115_config(struct rte_meter_trtcm_rfc4115 *m,
 	struct rte_meter_trtcm_rfc4115_profile *p);
@@ -295,7 +293,6 @@ struct rte_meter_trtcm_rfc4115_params {
  * @return
  *    Color assigned to the current IP packet
  */
-__rte_experimental
 static inline enum rte_color
 rte_meter_trtcm_rfc4115_color_blind_check(
 	struct rte_meter_trtcm_rfc4115 *m,
@@ -322,7 +319,6 @@ struct rte_meter_trtcm_rfc4115_params {
  * @return
  *    Color assigned to the current IP packet
  */
-__rte_experimental
 static inline enum rte_color
 rte_meter_trtcm_rfc4115_color_aware_check(
 	struct rte_meter_trtcm_rfc4115 *m,
@@ -582,7 +578,6 @@ struct rte_meter_trtcm_rfc4115 {
 	return RTE_COLOR_GREEN;
 }
 
-__rte_experimental
 static inline enum rte_color
 rte_meter_trtcm_rfc4115_color_blind_check(
 	struct rte_meter_trtcm_rfc4115 *m,
@@ -626,7 +621,6 @@ struct rte_meter_trtcm_rfc4115 {
 	return RTE_COLOR_RED;
 }
 
-__rte_experimental
 static inline enum rte_color
 rte_meter_trtcm_rfc4115_color_aware_check(
 	struct rte_meter_trtcm_rfc4115 *m,
diff --git a/lib/librte_meter/rte_meter_version.map b/lib/librte_meter/rte_meter_version.map
index 46410b0..fc12cc0 100644
--- a/lib/librte_meter/rte_meter_version.map
+++ b/lib/librte_meter/rte_meter_version.map
@@ -13,11 +13,11 @@ DPDK_20.0 {
 	local: *;
 };
 
-EXPERIMENTAL {
+DPDK_20.0.1 {
 	global:
 
 	rte_meter_trtcm_rfc4115_color_aware_check;
 	rte_meter_trtcm_rfc4115_color_blind_check;
 	rte_meter_trtcm_rfc4115_config;
 	rte_meter_trtcm_rfc4115_profile_config;
-};
+} DPDK_20.0;

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Eelco Chaudron <echaudro@redhat.com>
> Sent: Tuesday, December 17, 2019 1:08 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: stable@dpdk.org; dev@dpdk.org
> Subject: [PATCH] meter: move RFC4115 trTCM APIs as none experimental
> 
> Moved RFC4115 APIs to none experimental as they have been there
> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> 
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> ---
>  lib/librte_meter/rte_meter.h           |    6 ------
>  lib/librte_meter/rte_meter_version.map |    4 ++--
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
> index d69b118..62c8c1e 100644
> --- a/lib/librte_meter/rte_meter.h
> +++ b/lib/librte_meter/rte_meter.h

Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[David Marchand]

On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>
> Moved RFC4115 APIs to none experimental as they have been there
> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
>
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

There is a discussion on the OVS ml at the moment to get these symbols
in the stable ABI for 19.11.
I want to understand how this would be done.

- I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
On the other hand, the 19.11 release maintains the 20.0 ABI.

Does it mean the backport adds these symbols with the 20.0 version in
the 19.11 branch?
Or is 20.0.1 version acceptable / a thing we want?


- These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
We can go and remove these entries since we are not bound to preserve
the experimental APIs.
But, on the other hand, nothing should prevent us from keeping some
aliases so that the symbols versioned EXPERIMENTAL are still available
to existing users.


-- 
David Marchand

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Neil Horman]

On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
> >
> > Moved RFC4115 APIs to none experimental as they have been there
> > since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> >
> > Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> 
> There is a discussion on the OVS ml at the moment to get these symbols
> in the stable ABI for 19.11.
> I want to understand how this would be done.
> 
> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
> On the other hand, the 19.11 release maintains the 20.0 ABI.
> 
> Does it mean the backport adds these symbols with the 20.0 version in
> the 19.11 branch?
> Or is 20.0.1 version acceptable / a thing we want?
> 
> 
> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
> We can go and remove these entries since we are not bound to preserve
> the experimental APIs.
> But, on the other hand, nothing should prevent us from keeping some
> aliases so that the symbols versioned EXPERIMENTAL are still available
> to existing users.
> 
I would say that choice is up to you.  If you want to alias them to be nice to
prior users, thats fine by me. But experimental means experimental, and so users
have to be prepared to rebuild when things change, even if that change is
changing the version from experimental to a concrete version.

Neil

> 
> -- 
> David Marchand
> 
> 

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Ferruh Yigit]

On 1/16/2020 11:54 AM, Neil Horman wrote:
> On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
>> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>>>
>>> Moved RFC4115 APIs to none experimental as they have been there
>>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
>>>
>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>
>> There is a discussion on the OVS ml at the moment to get these symbols
>> in the stable ABI for 19.11.
>> I want to understand how this would be done.
>>
>> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
>> On the other hand, the 19.11 release maintains the 20.0 ABI.
>>
>> Does it mean the backport adds these symbols with the 20.0 version in
>> the 19.11 branch?
>> Or is 20.0.1 version acceptable / a thing we want?
>>
>>
>> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
>> We can go and remove these entries since we are not bound to preserve
>> the experimental APIs.
>> But, on the other hand, nothing should prevent us from keeping some
>> aliases so that the symbols versioned EXPERIMENTAL are still available
>> to existing users.
>>
> I would say that choice is up to you.  If you want to alias them to be nice to
> prior users, thats fine by me. But experimental means experimental, and so users
> have to be prepared to rebuild when things change, even if that change is
> changing the version from experimental to a concrete version.
> 

I would prefer to keep the alias and don't break the existing users, specially
for the case experimental API is becoming mature without change.

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Thomas Monjalon]

16/01/2020 13:42, Ferruh Yigit:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
> > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> >> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
> >>>
> >>> Moved RFC4115 APIs to none experimental as they have been there
> >>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> >>>
> >>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> >>
> >> There is a discussion on the OVS ml at the moment to get these symbols
> >> in the stable ABI for 19.11.
> >> I want to understand how this would be done.
> >>
> >> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
> >> On the other hand, the 19.11 release maintains the 20.0 ABI.
> >>
> >> Does it mean the backport adds these symbols with the 20.0 version in
> >> the 19.11 branch?
> >> Or is 20.0.1 version acceptable / a thing we want?

We cannot have the symbol with different versions in different releases,
otherwise the compatibility is broken when upgrading.
So we have no choice, the symbol must have version 20.0.1
in release 19.11.1, as in release 20.02.


> >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
> >> We can go and remove these entries since we are not bound to preserve
> >> the experimental APIs.
> >> But, on the other hand, nothing should prevent us from keeping some
> >> aliases so that the symbols versioned EXPERIMENTAL are still available
> >> to existing users.
> >>
> > I would say that choice is up to you.  If you want to alias them to be nice to
> > prior users, thats fine by me. But experimental means experimental, and so users
> > have to be prepared to rebuild when things change, even if that change is
> > changing the version from experimental to a concrete version.
> > 
> 
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.

I agree, it's cool to be nice :)

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[David Marchand]

On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 16/01/2020 13:42, Ferruh Yigit:
> > On 1/16/2020 11:54 AM, Neil Horman wrote:
> > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> > >> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
> > >>>
> > >>> Moved RFC4115 APIs to none experimental as they have been there
> > >>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> > >>>
> > >>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> > >>
> > >> There is a discussion on the OVS ml at the moment to get these symbols
> > >> in the stable ABI for 19.11.
> > >> I want to understand how this would be done.
> > >>
> > >> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
> > >> On the other hand, the 19.11 release maintains the 20.0 ABI.
> > >>
> > >> Does it mean the backport adds these symbols with the 20.0 version in
> > >> the 19.11 branch?
> > >> Or is 20.0.1 version acceptable / a thing we want?
>
> We cannot have the symbol with different versions in different releases,
> otherwise the compatibility is broken when upgrading.
> So we have no choice, the symbol must have version 20.0.1
> in release 19.11.1, as in release 20.02.

Indeed, good point.


> > >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
> > >> We can go and remove these entries since we are not bound to preserve
> > >> the experimental APIs.
> > >> But, on the other hand, nothing should prevent us from keeping some
> > >> aliases so that the symbols versioned EXPERIMENTAL are still available
> > >> to existing users.
> > >>
> > > I would say that choice is up to you.  If you want to alias them to be nice to
> > > prior users, thats fine by me. But experimental means experimental, and so users
> > > have to be prepared to rebuild when things change, even if that change is
> > > changing the version from experimental to a concrete version.
> > >
> >
> > I would prefer to keep the alias and don't break the existing users, specially
> > for the case experimental API is becoming mature without change.
>
> I agree, it's cool to be nice :)

Luca, opinion?


-- 
David Marchand

Re: [dpdk-stable] [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Luca Boccassi]

On Fri, 2020-01-17 at 09:27 +0100, David Marchand wrote:
> On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon <
> thomas@monjalon.net
> > wrote:
> > 16/01/2020 13:42, Ferruh Yigit:
> > > On 1/16/2020 11:54 AM, Neil Horman wrote:
> > > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> > > > > On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <
> > > > > echaudro@redhat.com
> > > > > > wrote:
> > > > > > Moved RFC4115 APIs to none experimental as they have been
> > > > > > there
> > > > > > since 19.02. Also, these APIs are the same as the none
> > > > > > RFC4115 APIs.
> > > > > > 
> > > > > > Signed-off-by: Eelco Chaudron <
> > > > > > echaudro@redhat.com
> > > > > > >
> > > > > 
> > > > > There is a discussion on the OVS ml at the moment to get
> > > > > these symbols
> > > > > in the stable ABI for 19.11.
> > > > > I want to understand how this would be done.
> > > > > 
> > > > > - I take this patch in 20.02, these symbols are added in the
> > > > > 20.0.1 ABI.
> > > > > On the other hand, the 19.11 release maintains the 20.0 ABI.
> > > > > 
> > > > > Does it mean the backport adds these symbols with the 20.0
> > > > > version in
> > > > > the 19.11 branch?
> > > > > Or is 20.0.1 version acceptable / a thing we want?
> > 
> > We cannot have the symbol with different versions in different
> > releases,
> > otherwise the compatibility is broken when upgrading.
> > So we have no choice, the symbol must have version 20.0.1
> > in release 19.11.1, as in release 20.02.
> 
> Indeed, good point.
> 
> 
> > > > > - These symbol already existed in the 20.0 ABI, versioned as
> > > > > EXPERIMENTAL.
> > > > > We can go and remove these entries since we are not bound to
> > > > > preserve
> > > > > the experimental APIs.
> > > > > But, on the other hand, nothing should prevent us from
> > > > > keeping some
> > > > > aliases so that the symbols versioned EXPERIMENTAL are still
> > > > > available
> > > > > to existing users.
> > > > > 
> > > > 
> > > > I would say that choice is up to you.  If you want to alias
> > > > them to be nice to
> > > > prior users, thats fine by me. But experimental means
> > > > experimental, and so users
> > > > have to be prepared to rebuild when things change, even if that
> > > > change is
> > > > changing the version from experimental to a concrete version.
> > > > 
> > > 
> > > I would prefer to keep the alias and don't break the existing
> > > users, specially
> > > for the case experimental API is becoming mature without change.
> > 
> > I agree, it's cool to be nice :)
> 
> Luca, opinion?

I'd not only prefer it but also go as far as require it for backporting
to 19.11 - experimental means experimental, but stable means stable :-)

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-stable] [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Thomas Monjalon]

17/12/2019 14:52, Dumitrescu, Cristian:
> From: Eelco Chaudron <echaudro@redhat.com>
> > Moved RFC4115 APIs to none experimental as they have been there
> > since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> > 
> > Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> 
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>

Applied, thanks

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Ray Kinsella]

On 16/01/2020 12:42, Ferruh Yigit wrote:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
>> On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
>>> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>>>>
>>>> Moved RFC4115 APIs to none experimental as they have been there
>>>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
>>>>
>>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>>
>>> There is a discussion on the OVS ml at the moment to get these symbols
>>> in the stable ABI for 19.11.
>>> I want to understand how this would be done.
>>>
>>> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
>>> On the other hand, the 19.11 release maintains the 20.0 ABI.
>>>
>>> Does it mean the backport adds these symbols with the 20.0 version in
>>> the 19.11 branch?
>>> Or is 20.0.1 version acceptable / a thing we want?
>>>
>>>
>>> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
>>> We can go and remove these entries since we are not bound to preserve
>>> the experimental APIs.
>>> But, on the other hand, nothing should prevent us from keeping some
>>> aliases so that the symbols versioned EXPERIMENTAL are still available
>>> to existing users.
>>>
>> I would say that choice is up to you.  If you want to alias them to be nice to
>> prior users, thats fine by me. But experimental means experimental, and so users
>> have to be prepared to rebuild when things change, even if that change is
>> changing the version from experimental to a concrete version.
>>
> 
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.
> 

+1 keeping an alias until 20.11/v21 is a good idea, particularly if the API is "baked" 
and has not changed in some time - as is the case here. 

Ray K

Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Ray Kinsella]

On 16/01/2020 12:42, Ferruh Yigit wrote:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
>> On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
>>> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>>>>
>>>> Moved RFC4115 APIs to none experimental as they have been there
>>>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
>>>>
>>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>>
>>> There is a discussion on the OVS ml at the moment to get these symbols
>>> in the stable ABI for 19.11.
>>> I want to understand how this would be done.
>>>
>>> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
>>> On the other hand, the 19.11 release maintains the 20.0 ABI.
>>>
>>> Does it mean the backport adds these symbols with the 20.0 version in
>>> the 19.11 branch?
>>> Or is 20.0.1 version acceptable / a thing we want?
>>>
>>>
>>> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
>>> We can go and remove these entries since we are not bound to preserve
>>> the experimental APIs.
>>> But, on the other hand, nothing should prevent us from keeping some
>>> aliases so that the symbols versioned EXPERIMENTAL are still available
>>> to existing users.
>>>
>> I would say that choice is up to you.  If you want to alias them to be nice to
>> prior users, thats fine by me. But experimental means experimental, and so users
>> have to be prepared to rebuild when things change, even if that change is
>> changing the version from experimental to a concrete version.
>>
> 
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.
> 

Apologies for dragging up an older thread.
I had a thought later that we should add something formal to the ABI Policy.

Such that if we have an API that has been part of DPDK as experimental for a long time, 
to the point it has a number of users - out of kindness, the maintainer may ask a
contributor to add an alias until the next major ABI version is declared?
So as not to break consuming projects - make sense?

Thanks, 

Ray K