meter: move RFC4115 trTCM APIs as none experimental
Checks
Commit Message
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(-)
Comments
> -----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>
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.
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
>
>
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.
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 :)
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?
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 :-)
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
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
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
@@ -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,
@@ -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;