DPDK-dev Archive on lore.kernel.org
 help / color / Atom feed
* [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
@ 2019-12-17 13:07 Eelco Chaudron
  2019-12-17 13:52 ` Dumitrescu, Cristian
  2020-01-16 11:25 ` [dpdk-dev] [dpdk-stable] " David Marchand
  0 siblings, 2 replies; 11+ messages in thread
From: Eelco Chaudron @ 2019-12-17 13:07 UTC (permalink / raw)
  To: cristian.dumitrescu; +Cc: stable, dev

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;


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2019-12-17 13:07 [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental Eelco Chaudron
@ 2019-12-17 13:52 ` Dumitrescu, Cristian
  2020-01-20 15:17   ` Thomas Monjalon
  2020-01-16 11:25 ` [dpdk-dev] [dpdk-stable] " David Marchand
  1 sibling, 1 reply; 11+ messages in thread
From: Dumitrescu, Cristian @ 2019-12-17 13:52 UTC (permalink / raw)
  To: Eelco Chaudron; +Cc: stable, dev



> -----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>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2019-12-17 13:07 [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental Eelco Chaudron
  2019-12-17 13:52 ` Dumitrescu, Cristian
@ 2020-01-16 11:25 ` " David Marchand
  2020-01-16 11:54   ` Neil Horman
  1 sibling, 1 reply; 11+ messages in thread
From: David Marchand @ 2020-01-16 11:25 UTC (permalink / raw)
  To: Ray Kinsella, Thomas Monjalon, Neil Horman
  Cc: Cristian Dumitrescu, dpdk stable, dev, Eelco Chaudron,
	Kevin Traynor, Ian Stokes, Ilya Maximets, Luca Boccassi, Yigit,
	Ferruh

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-16 11:25 ` [dpdk-dev] [dpdk-stable] " David Marchand
@ 2020-01-16 11:54   ` Neil Horman
  2020-01-16 12:42     ` Ferruh Yigit
  0 siblings, 1 reply; 11+ messages in thread
From: Neil Horman @ 2020-01-16 11:54 UTC (permalink / raw)
  To: David Marchand
  Cc: Ray Kinsella, Thomas Monjalon, Cristian Dumitrescu, dpdk stable,
	dev, Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
	Luca Boccassi, Yigit, Ferruh

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
> 
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-16 11:54   ` Neil Horman
@ 2020-01-16 12:42     ` Ferruh Yigit
  2020-01-16 14:38       ` Thomas Monjalon
                         ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Ferruh Yigit @ 2020-01-16 12:42 UTC (permalink / raw)
  To: Neil Horman, David Marchand
  Cc: Ray Kinsella, Thomas Monjalon, Cristian Dumitrescu, dpdk stable,
	dev, Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
	Luca Boccassi

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-16 12:42     ` Ferruh Yigit
@ 2020-01-16 14:38       ` Thomas Monjalon
  2020-01-17  8:27         ` David Marchand
  2020-01-22 13:55       ` Ray Kinsella
  2020-01-30 16:33       ` Ray Kinsella
  2 siblings, 1 reply; 11+ messages in thread
From: Thomas Monjalon @ 2020-01-16 14:38 UTC (permalink / raw)
  To: Neil Horman, David Marchand, Ferruh Yigit
  Cc: Ray Kinsella, Cristian Dumitrescu, dpdk stable, dev,
	Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
	Luca Boccassi

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 :)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-16 14:38       ` Thomas Monjalon
@ 2020-01-17  8:27         ` David Marchand
  2020-01-17 10:46           ` Luca Boccassi
  0 siblings, 1 reply; 11+ messages in thread
From: David Marchand @ 2020-01-17  8:27 UTC (permalink / raw)
  To: Thomas Monjalon, Luca Boccassi
  Cc: Neil Horman, Ferruh Yigit, Ray Kinsella, Cristian Dumitrescu,
	dpdk stable, dev, Eelco Chaudron, Kevin Traynor, Ian Stokes,
	Ilya Maximets

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-17  8:27         ` David Marchand
@ 2020-01-17 10:46           ` Luca Boccassi
  0 siblings, 0 replies; 11+ messages in thread
From: Luca Boccassi @ 2020-01-17 10:46 UTC (permalink / raw)
  To: David Marchand, Thomas Monjalon
  Cc: Neil Horman, Ferruh Yigit, Ray Kinsella, Cristian Dumitrescu,
	dpdk stable, dev, Eelco Chaudron, Kevin Traynor, Ian Stokes,
	Ilya Maximets

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2019-12-17 13:52 ` Dumitrescu, Cristian
@ 2020-01-20 15:17   ` Thomas Monjalon
  0 siblings, 0 replies; 11+ messages in thread
From: Thomas Monjalon @ 2020-01-20 15:17 UTC (permalink / raw)
  To: Eelco Chaudron, Dumitrescu, Cristian; +Cc: dev, 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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-16 12:42     ` Ferruh Yigit
  2020-01-16 14:38       ` Thomas Monjalon
@ 2020-01-22 13:55       ` Ray Kinsella
  2020-01-30 16:33       ` Ray Kinsella
  2 siblings, 0 replies; 11+ messages in thread
From: Ray Kinsella @ 2020-01-22 13:55 UTC (permalink / raw)
  To: Ferruh Yigit, Neil Horman, David Marchand
  Cc: Thomas Monjalon, Cristian Dumitrescu, dpdk stable, dev,
	Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
	Luca Boccassi



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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
  2020-01-16 12:42     ` Ferruh Yigit
  2020-01-16 14:38       ` Thomas Monjalon
  2020-01-22 13:55       ` Ray Kinsella
@ 2020-01-30 16:33       ` Ray Kinsella
  2 siblings, 0 replies; 11+ messages in thread
From: Ray Kinsella @ 2020-01-30 16:33 UTC (permalink / raw)
  To: Ferruh Yigit, Neil Horman, David Marchand
  Cc: Thomas Monjalon, Cristian Dumitrescu, dpdk stable, dev,
	Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
	Luca Boccassi



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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-17 13:07 [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental Eelco Chaudron
2019-12-17 13:52 ` Dumitrescu, Cristian
2020-01-20 15:17   ` Thomas Monjalon
2020-01-16 11:25 ` [dpdk-dev] [dpdk-stable] " David Marchand
2020-01-16 11:54   ` Neil Horman
2020-01-16 12:42     ` Ferruh Yigit
2020-01-16 14:38       ` Thomas Monjalon
2020-01-17  8:27         ` David Marchand
2020-01-17 10:46           ` Luca Boccassi
2020-01-22 13:55       ` Ray Kinsella
2020-01-30 16:33       ` Ray Kinsella

DPDK-dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dpdk-dev/0 dpdk-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dpdk-dev dpdk-dev/ https://lore.kernel.org/dpdk-dev \
		dev@dpdk.org
	public-inbox-index dpdk-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git