meter: move RFC4115 trTCM APIs as none experimental
PATCH 1/1 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.
--- lib/librte_meter/rte_meter.h | 6 ------ lib/librte_meter/rte_meter_version.map | 4 ++-- 2 files changed, 2 insertions(+), 8 deletions(-)
lib/librte_meter/rte_meter.h +0 -6
@@ -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,
lib/librte_meter/rte_meter_version.map +2 -2
@@ -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;
lib/librte_meter/rte_meter.h
Quoted 22 lines
-----Original Message-----
From: Eelco Chaudron <[email protected]>
Sent: Tuesday, December 17, 2019 1:08 PM
To: Dumitrescu, Cristian <[email protected]>
Cc: [email protected]; [email protected]
Subject: [PATCH] meter: move RFC4115 trTCM APIs as none experimentalMoved 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 <[email protected]>--- lib/librte_meter/rte_meter.h | 6 ------ lib/librte_meter/rte_meter_version.map | 4 ++-- 2 files changed, 2 insertions(+), 8 deletions(-)lib/librte_meter/rte_meter.h +0
-0
Thomas Monjalon
Applied17/12/2019 14:52, Dumitrescu, Cristian:
Quoted 7 lines
From: Eelco Chaudron <[email protected]>
Quoted 4 lines
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 <[email protected]>
Applied, thanks
Quoted 5 lines · 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 <[email protected]>
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.
Signature · 1 line
David Marchand
Quoted 19 lines · David Marchand
Quoted 5 lines · 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 <[email protected]>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?
Quoted 7 lines
- 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
Quoted 5 lines
Signature · 2 lines
-- David Marchand
Quoted 27 lines · Neil Horman
Quoted 19 lines · David Marchand
Quoted 5 lines · 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 <[email protected]>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?Quoted 7 lines
- 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.
Quoted 5 lines
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:
Quoted 13 lines · Neil Horman
Quoted 12 lines · David Marchand
Quoted 11 lines · Eelco Chaudron
Quoted 5 lines
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 <[email protected]>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.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
- 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.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
- 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.
Quoted 8 lines
Quoted 5 lines
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 :)
Quoted 18 lines · Thomas Monjalon
16/01/2020 13:42, Ferruh Yigit:
Quoted 16 lines · Neil Horman
Quoted 15 lines · David Marchand
Quoted 14 lines · Eelco Chaudron
Quoted 5 lines
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 <[email protected]>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.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 7 lines
- 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.
Quoted 4 lines
Quoted 2 lines
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?
Signature · 1 line
David Marchand
Quoted 62 lines · David Marchand
On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon <
[email protected]Quoted 30 lines
wrote:
16/01/2020 13:42, Ferruh Yigit:Quoted 19 lines · Neil Horman
Quoted 18 lines · David Marchand
Quoted 17 lines
On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <
[email protected]Quoted 9 lines
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 <
[email protected]Quoted 1 line
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.Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
- 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?Quoted 5 lines
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.
Quoted 21 lines
Quoted 21 lines
Quoted 20 lines
Quoted 11 lines
- 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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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 :-)
Signature · 2 lines
Kind regards, Luca Boccassi
Quoted 28 lines · Ferruh Yigit
Quoted 27 lines · Neil Horman
Quoted 26 lines · David Marchand
Quoted 5 lines · 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 <[email protected]>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.
Quoted 9 lines
Quoted 5 lines
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
Quoted 28 lines · Ferruh Yigit
Quoted 27 lines · Neil Horman
Quoted 26 lines · David Marchand
Quoted 5 lines · 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 <[email protected]>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.
Quoted 9 lines
Quoted 5 lines
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