[RFC,v2] meter: fix ABI break due to experimental tag removal
Checks
Commit Message
Duplicated the existing symbol and versioned one as experimental and
other as stable.
Created VERSION_SYMBOL_EXPERIMENTAL helper macro.
Updated the 'check-experimental-syms.sh' buildtool, which was
complaining that the symbol is in EXPERIMENTAL tag in .map file but it
is not in the .experimental section (__rte_experimental tag is missing).
Updated tool in a way it won't complain if the symbol in the
EXPERIMENTAL tag duplicated in some other block in .map file (versioned)
Enabled function versioning for meson build for the library.
Fixes: 30512af820fe ("meter: remove experimental flag from RFC4115 trTCM API")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Thomas Monjalon <thomas@monjalon.net>
Cc: Luca Boccassi <bluca@debian.org>
Cc: David Marchand <david.marchand@redhat.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>
Cc: Ian Stokes <ian.stokes@intel.com>
Cc: Eelco Chaudron <echaudro@redhat.com>
Cc: Andrzej Ostruszka <amo@semihalf.com>
v2:
* allow versioning only for meter library, instead of enabling it
globally
I didn't like the idea of duplicating the symbol but not able to find to
alias it without duplicating, if there is a way please share.
Also not tested with old binaries, only verified the symbols in new
binaries.
---
buildtools/check-experimental-syms.sh | 3 +-
.../common/include/rte_function_versioning.h | 4 ++
lib/librte_meter/meson.build | 1 +
lib/librte_meter/rte_meter.c | 59 ++++++++++++++++++-
lib/librte_meter/rte_meter_version.map | 8 +++
5 files changed, 71 insertions(+), 4 deletions(-)
Comments
On 1/29/20 5:43 PM, Ferruh Yigit wrote:
[...]
> diff --git a/lib/librte_meter/rte_meter.c b/lib/librte_meter/rte_meter.c
> index da01429a8..5244537fa 100644
> --- a/lib/librte_meter/rte_meter.c
> +++ b/lib/librte_meter/rte_meter.c
> @@ -9,6 +9,7 @@
> #include <rte_common.h>
> #include <rte_log.h>
> #include <rte_cycles.h>
> +#include <rte_function_versioning.h>
>
> #include "rte_meter.h"
>
> @@ -119,8 +120,8 @@ rte_meter_trtcm_config(struct rte_meter_trtcm *m,
> return 0;
> }
>
> -int
> -rte_meter_trtcm_rfc4115_profile_config(
> +static int
> +rte_meter_trtcm_rfc4115_profile_config_(
> struct rte_meter_trtcm_rfc4115_profile *p,
> struct rte_meter_trtcm_rfc4115_params *params)
> {
> @@ -145,7 +146,35 @@ rte_meter_trtcm_rfc4115_profile_config(
> }
>
> int
> -rte_meter_trtcm_rfc4115_config(
> +rte_meter_trtcm_rfc4115_profile_config_s(
> + struct rte_meter_trtcm_rfc4115_profile *p,
> + struct rte_meter_trtcm_rfc4115_params *params);
> +int
> +rte_meter_trtcm_rfc4115_profile_config_s(
> + struct rte_meter_trtcm_rfc4115_profile *p,
> + struct rte_meter_trtcm_rfc4115_params *params)
> +{
> + return rte_meter_trtcm_rfc4115_profile_config_(p, params);
> +}
> +BIND_DEFAULT_SYMBOL(rte_meter_trtcm_rfc4115_profile_config, _s, 20.0.1);
You might want to mark these version symbols with __vsym macro. Without
this shared lib build with LTO might remove them (due to long standing
gcc bug - it does not have proper way to mark .symver in internal
representation and so does not recognize that function is used).
This comment is global - for all symbols mentioned in BIND_/VERSION_ macros.
Out of curiosity - why do you need separate declaration just before
definition?
With regards
Andrzej Ostruszka
Hi,
I disagree with the need of this patch.
The symbol was experimental, meaning we can change it.
Removing experimental tag is not an ABI break.
29/01/2020 17:43, Ferruh Yigit:
> Duplicated the existing symbol and versioned one as experimental and
> other as stable.
[..]
> --- a/lib/librte_meter/rte_meter_version.map
> +++ b/lib/librte_meter/rte_meter_version.map
> @@ -20,4 +20,12 @@ DPDK_20.0.1 {
> rte_meter_trtcm_rfc4115_color_blind_check;
> rte_meter_trtcm_rfc4115_config;
> rte_meter_trtcm_rfc4115_profile_config;
> +
> } DPDK_20.0;
> +
> +EXPERIMENTAL {
> + global:
> +
> + rte_meter_trtcm_rfc4115_config;
> + rte_meter_trtcm_rfc4115_profile_config;
> +};
On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
> Hi,
>
> I disagree with the need of this patch.
> The symbol was experimental, meaning we can change it.
> Removing experimental tag is not an ABI break.
Hi,
This symbol change was requested for backport in 19.11.x, and
experimental or not I'm not too keen on backward incompatible changes
to the public interface in an _LTS point release_. The compromise was
to see if we could support both symbols version, which makes the change
backward compatible.
If you prefer not to have this patch in mainline I'm also fine in
taking it just for the LTS. I agree with you that it is not required
for mainline releases (although nicer for me if it's a backport rather
than a new change).
> 29/01/2020 17:43, Ferruh Yigit:
> > Duplicated the existing symbol and versioned one as experimental
> > and
> > other as stable.
>
> [..]
> > --- a/lib/librte_meter/rte_meter_version.map
> > +++ b/lib/librte_meter/rte_meter_version.map
> > @@ -20,4 +20,12 @@ DPDK_20.0.1 {
> > rte_meter_trtcm_rfc4115_color_blind_check;
> > rte_meter_trtcm_rfc4115_config;
> > rte_meter_trtcm_rfc4115_profile_config;
> > +
> > } DPDK_20.0;
> > +
> > +EXPERIMENTAL {
> > + global:
> > +
> > + rte_meter_trtcm_rfc4115_config;
> > + rte_meter_trtcm_rfc4115_profile_config;
> > +};
>
>
>
>
>
30/01/2020 13:57, Luca Boccassi:
> On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
> > Hi,
> >
> > I disagree with the need of this patch.
> > The symbol was experimental, meaning we can change it.
> > Removing experimental tag is not an ABI break.
>
> Hi,
>
> This symbol change was requested for backport in 19.11.x, and
> experimental or not I'm not too keen on backward incompatible changes
> to the public interface in an _LTS point release_. The compromise was
> to see if we could support both symbols version, which makes the change
> backward compatible.
>
> If you prefer not to have this patch in mainline I'm also fine in
> taking it just for the LTS. I agree with you that it is not required
> for mainline releases (although nicer for me if it's a backport rather
> than a new change).
I would like to avoid opening the door for maintaining the experimental ABI
in the mainline. Please take it directly in the LTS.
The next question is to know whether we really want to have such patch in LTS.
Anyway, 19.11.0 has this symbol as experimental.
How adding a non-experimental version of the function in 19.11.1 will change
the ABI status of the whole 19.11 branch?
> > 29/01/2020 17:43, Ferruh Yigit:
> > > Duplicated the existing symbol and versioned one as experimental
> > > and
> > > other as stable.
> >
> > [..]
> > > --- a/lib/librte_meter/rte_meter_version.map
> > > +++ b/lib/librte_meter/rte_meter_version.map
> > > @@ -20,4 +20,12 @@ DPDK_20.0.1 {
> > > rte_meter_trtcm_rfc4115_color_blind_check;
> > > rte_meter_trtcm_rfc4115_config;
> > > rte_meter_trtcm_rfc4115_profile_config;
> > > +
> > > } DPDK_20.0;
> > > +
> > > +EXPERIMENTAL {
> > > + global:
> > > +
> > > + rte_meter_trtcm_rfc4115_config;
> > > + rte_meter_trtcm_rfc4115_profile_config;
> > > +};
On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:
> 30/01/2020 13:57, Luca Boccassi:
> > On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
> > > Hi,
> > >
> > > I disagree with the need of this patch.
> > > The symbol was experimental, meaning we can change it.
> > > Removing experimental tag is not an ABI break.
> >
> > Hi,
> >
> > This symbol change was requested for backport in 19.11.x, and
> > experimental or not I'm not too keen on backward incompatible
> > changes
> > to the public interface in an _LTS point release_. The compromise
> > was
> > to see if we could support both symbols version, which makes the
> > change
> > backward compatible.
> >
> > If you prefer not to have this patch in mainline I'm also fine in
> > taking it just for the LTS. I agree with you that it is not
> > required
> > for mainline releases (although nicer for me if it's a backport
> > rather
> > than a new change).
>
> I would like to avoid opening the door for maintaining the
> experimental ABI
> in the mainline. Please take it directly in the LTS.
>
> The next question is to know whether we really want to have such
> patch in LTS.
> Anyway, 19.11.0 has this symbol as experimental.
> How adding a non-experimental version of the function in 19.11.1 will
> change
> the ABI status of the whole 19.11 branch?
The problem is not adding the new symbol, but removing the experimental
one. Changing the version of the symbol was requested by OVS for
inclusion in 19.11.
30/01/2020 15:21, Luca Boccassi:
> On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:
> > 30/01/2020 13:57, Luca Boccassi:
> > > On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
> > > > Hi,
> > > >
> > > > I disagree with the need of this patch.
> > > > The symbol was experimental, meaning we can change it.
> > > > Removing experimental tag is not an ABI break.
> > >
> > > Hi,
> > >
> > > This symbol change was requested for backport in 19.11.x, and
> > > experimental or not I'm not too keen on backward incompatible
> > > changes
> > > to the public interface in an _LTS point release_. The compromise
> > > was
> > > to see if we could support both symbols version, which makes the
> > > change
> > > backward compatible.
> > >
> > > If you prefer not to have this patch in mainline I'm also fine in
> > > taking it just for the LTS. I agree with you that it is not
> > > required
> > > for mainline releases (although nicer for me if it's a backport
> > > rather
> > > than a new change).
> >
> > I would like to avoid opening the door for maintaining the
> > experimental ABI
> > in the mainline. Please take it directly in the LTS.
> >
> > The next question is to know whether we really want to have such
> > patch in LTS.
> > Anyway, 19.11.0 has this symbol as experimental.
> > How adding a non-experimental version of the function in 19.11.1 will
> > change
> > the ABI status of the whole 19.11 branch?
>
> The problem is not adding the new symbol, but removing the experimental
> one. Changing the version of the symbol was requested by OVS for
> inclusion in 19.11.
Yes, sorry, this is what I meant.
Given 19.11.0 already has the symbol as experimental,
and that applications like OVS had to accept it as experimental,
why removing experimental tag in 19.11.1?
On Thu, 2020-01-30 at 16:55 +0100, Thomas Monjalon wrote:
> 30/01/2020 15:21, Luca Boccassi:
> > On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:
> > > 30/01/2020 13:57, Luca Boccassi:
> > > > On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
> > > > > Hi,
> > > > >
> > > > > I disagree with the need of this patch.
> > > > > The symbol was experimental, meaning we can change it.
> > > > > Removing experimental tag is not an ABI break.
> > > >
> > > > Hi,
> > > >
> > > > This symbol change was requested for backport in 19.11.x, and
> > > > experimental or not I'm not too keen on backward incompatible
> > > > changes
> > > > to the public interface in an _LTS point release_. The
> > > > compromise
> > > > was
> > > > to see if we could support both symbols version, which makes
> > > > the
> > > > change
> > > > backward compatible.
> > > >
> > > > If you prefer not to have this patch in mainline I'm also fine
> > > > in
> > > > taking it just for the LTS. I agree with you that it is not
> > > > required
> > > > for mainline releases (although nicer for me if it's a backport
> > > > rather
> > > > than a new change).
> > >
> > > I would like to avoid opening the door for maintaining the
> > > experimental ABI
> > > in the mainline. Please take it directly in the LTS.
> > >
> > > The next question is to know whether we really want to have such
> > > patch in LTS.
> > > Anyway, 19.11.0 has this symbol as experimental.
> > > How adding a non-experimental version of the function in 19.11.1
> > > will
> > > change
> > > the ABI status of the whole 19.11 branch?
> >
> > The problem is not adding the new symbol, but removing the
> > experimental
> > one. Changing the version of the symbol was requested by OVS for
> > inclusion in 19.11.
>
> Yes, sorry, this is what I meant.
> Given 19.11.0 already has the symbol as experimental,
> and that applications like OVS had to accept it as experimental,
> why removing experimental tag in 19.11.1?
I think it was mentioned that it was preferred not to suppress the
compiler warning to avoid any accidental use in the future, but the OVS
maintainer(s) should answer as I might remember wrongly.
On 30 Jan 2020, at 17:04, Luca Boccassi wrote:
> On Thu, 2020-01-30 at 16:55 +0100, Thomas Monjalon wrote:
>> 30/01/2020 15:21, Luca Boccassi:
>>> On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:
>>>> 30/01/2020 13:57, Luca Boccassi:
>>>>> On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I disagree with the need of this patch.
>>>>>> The symbol was experimental, meaning we can change it.
>>>>>> Removing experimental tag is not an ABI break.
>>>>>
>>>>> Hi,
>>>>>
>>>>> This symbol change was requested for backport in 19.11.x, and
>>>>> experimental or not I'm not too keen on backward incompatible
>>>>> changes
>>>>> to the public interface in an _LTS point release_. The
>>>>> compromise
>>>>> was
>>>>> to see if we could support both symbols version, which makes
>>>>> the
>>>>> change
>>>>> backward compatible.
>>>>>
>>>>> If you prefer not to have this patch in mainline I'm also fine
>>>>> in
>>>>> taking it just for the LTS. I agree with you that it is not
>>>>> required
>>>>> for mainline releases (although nicer for me if it's a backport
>>>>> rather
>>>>> than a new change).
>>>>
>>>> I would like to avoid opening the door for maintaining the
>>>> experimental ABI
>>>> in the mainline. Please take it directly in the LTS.
>>>>
>>>> The next question is to know whether we really want to have such
>>>> patch in LTS.
>>>> Anyway, 19.11.0 has this symbol as experimental.
>>>> How adding a non-experimental version of the function in 19.11.1
>>>> will
>>>> change
>>>> the ABI status of the whole 19.11 branch?
>>>
>>> The problem is not adding the new symbol, but removing the
>>> experimental
>>> one. Changing the version of the symbol was requested by OVS for
>>> inclusion in 19.11.
>>
>> Yes, sorry, this is what I meant.
>> Given 19.11.0 already has the symbol as experimental,
>> and that applications like OVS had to accept it as experimental,
>> why removing experimental tag in 19.11.1?
>
> I think it was mentioned that it was preferred not to suppress the
> compiler warning to avoid any accidental use in the future, but the
> OVS
> maintainer(s) should answer as I might remember wrongly.
Yes this is the reason, OVS compiles with -Werror so we would like to
avoid the warnings. You can not disable them per include, it’s global
for all of DPDK.
//Eelco
30/01/2020 17:15, Eelco Chaudron:
> On 30 Jan 2020, at 17:04, Luca Boccassi wrote:
> > On Thu, 2020-01-30 at 16:55 +0100, Thomas Monjalon wrote:
> >> 30/01/2020 15:21, Luca Boccassi:
> >>> On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:
> >>>> 30/01/2020 13:57, Luca Boccassi:
> >>>>> On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I disagree with the need of this patch.
> >>>>>> The symbol was experimental, meaning we can change it.
> >>>>>> Removing experimental tag is not an ABI break.
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> This symbol change was requested for backport in 19.11.x, and
> >>>>> experimental or not I'm not too keen on backward incompatible
> >>>>> changes
> >>>>> to the public interface in an _LTS point release_. The
> >>>>> compromise
> >>>>> was
> >>>>> to see if we could support both symbols version, which makes
> >>>>> the
> >>>>> change
> >>>>> backward compatible.
> >>>>>
> >>>>> If you prefer not to have this patch in mainline I'm also fine
> >>>>> in
> >>>>> taking it just for the LTS. I agree with you that it is not
> >>>>> required
> >>>>> for mainline releases (although nicer for me if it's a backport
> >>>>> rather
> >>>>> than a new change).
> >>>>
> >>>> I would like to avoid opening the door for maintaining the
> >>>> experimental ABI
> >>>> in the mainline. Please take it directly in the LTS.
> >>>>
> >>>> The next question is to know whether we really want to have such
> >>>> patch in LTS.
> >>>> Anyway, 19.11.0 has this symbol as experimental.
> >>>> How adding a non-experimental version of the function in 19.11.1
> >>>> will
> >>>> change
> >>>> the ABI status of the whole 19.11 branch?
> >>>
> >>> The problem is not adding the new symbol, but removing the
> >>> experimental
> >>> one. Changing the version of the symbol was requested by OVS for
> >>> inclusion in 19.11.
> >>
> >> Yes, sorry, this is what I meant.
> >> Given 19.11.0 already has the symbol as experimental,
> >> and that applications like OVS had to accept it as experimental,
> >> why removing experimental tag in 19.11.1?
> >
> > I think it was mentioned that it was preferred not to suppress the
> > compiler warning to avoid any accidental use in the future, but the
> > OVS
> > maintainer(s) should answer as I might remember wrongly.
>
> Yes this is the reason, OVS compiles with -Werror so we would like to
> avoid the warnings. You can not disable them per include, it’s global
> for all of DPDK.
Yes but anyway OVS must accept the experimental function as the next release
will use it with DPDK 19.11.0.
On 1/30/2020 12:33 PM, Thomas Monjalon wrote:
> Hi,
>
> I disagree with the need of this patch.
> The symbol was experimental, meaning we can change it.
> Removing experimental tag is not an ABI break.
In theory what you said is correct, this is experimental API and anything can
happen to it, this is the contract.
And when we need to change an experimental API, the users will be affected,
there is no escape from it.
But for this case limitation is more mechanical I believe,
because API is not changing at all, and it is becoming mature.
So we are breaking the user application because the experimental API they are
using becoming mature without any change.
This looks annoying from the user perspective, and if we can prevent this break,
I am for preventing it.
>
>
> 29/01/2020 17:43, Ferruh Yigit:
>> Duplicated the existing symbol and versioned one as experimental and
>> other as stable.
> [..]
>> --- a/lib/librte_meter/rte_meter_version.map
>> +++ b/lib/librte_meter/rte_meter_version.map
>> @@ -20,4 +20,12 @@ DPDK_20.0.1 {
>> rte_meter_trtcm_rfc4115_color_blind_check;
>> rte_meter_trtcm_rfc4115_config;
>> rte_meter_trtcm_rfc4115_profile_config;
>> +
>> } DPDK_20.0;
>> +
>> +EXPERIMENTAL {
>> + global:
>> +
>> + rte_meter_trtcm_rfc4115_config;
>> + rte_meter_trtcm_rfc4115_profile_config;
>> +};
>
>
>
>
On 30 Jan 2020, at 21:20, Thomas Monjalon wrote:
<SNIP>
>>>>
>>>> Yes, sorry, this is what I meant.
>>>> Given 19.11.0 already has the symbol as experimental,
>>>> and that applications like OVS had to accept it as experimental,
>>>> why removing experimental tag in 19.11.1?
>>>
>>> I think it was mentioned that it was preferred not to suppress the
>>> compiler warning to avoid any accidental use in the future, but the
>>> OVS
>>> maintainer(s) should answer as I might remember wrongly.
>>
>> Yes this is the reason, OVS compiles with -Werror so we would like to
>> avoid the warnings. You can not disable them per include, it’s
>> global
>> for all of DPDK.
>
> Yes but anyway OVS must accept the experimental function as the next
> release
> will use it with DPDK 19.11.0.
Yes, we do for now, but we would like to remove it ASAP as it opens up
the code base for the experimental APIs to slip in…
@@ -26,7 +26,8 @@ ret=0
for SYM in `$LIST_SYMBOL -S EXPERIMENTAL $MAPFILE |cut -d ' ' -f 3`
do
if grep -q "\.text.*[[:space:]]$SYM$" $DUMPFILE &&
- ! grep -q "\.text\.experimental.*[[:space:]]$SYM$" $DUMPFILE
+ ! grep -q "\.text\.experimental.*[[:space:]]$SYM$" $DUMPFILE &&
+ $LIST_SYMBOL -s $SYM $MAPFILE | grep -q EXPERIMENTAL
then
cat >&2 <<- END_OF_MESSAGE
$SYM is not flagged as experimental
@@ -46,6 +46,9 @@
*/
#define VERSION_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@DPDK_" RTE_STR(n))
+
+#define VERSION_SYMBOL_EXPERIMENTAL(b, e) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@EXPERIMENTAL")
+
/*
* BIND_DEFAULT_SYMBOL
* Creates a symbol version entry instructing the linker to bind references to
@@ -79,6 +82,7 @@
* No symbol versioning in use
*/
#define VERSION_SYMBOL(b, e, n)
+#define VERSION_SYMBOL_EXPERIMENTAL(b, e)
#define __vsym
#define BIND_DEFAULT_SYMBOL(b, e, n)
#define MAP_STATIC_SYMBOL(f, p) f __attribute__((alias(RTE_STR(p))))
@@ -3,3 +3,4 @@
sources = files('rte_meter.c')
headers = files('rte_meter.h')
+use_function_versioning = true
@@ -9,6 +9,7 @@
#include <rte_common.h>
#include <rte_log.h>
#include <rte_cycles.h>
+#include <rte_function_versioning.h>
#include "rte_meter.h"
@@ -119,8 +120,8 @@ rte_meter_trtcm_config(struct rte_meter_trtcm *m,
return 0;
}
-int
-rte_meter_trtcm_rfc4115_profile_config(
+static int
+rte_meter_trtcm_rfc4115_profile_config_(
struct rte_meter_trtcm_rfc4115_profile *p,
struct rte_meter_trtcm_rfc4115_params *params)
{
@@ -145,7 +146,35 @@ rte_meter_trtcm_rfc4115_profile_config(
}
int
-rte_meter_trtcm_rfc4115_config(
+rte_meter_trtcm_rfc4115_profile_config_s(
+ struct rte_meter_trtcm_rfc4115_profile *p,
+ struct rte_meter_trtcm_rfc4115_params *params);
+int
+rte_meter_trtcm_rfc4115_profile_config_s(
+ struct rte_meter_trtcm_rfc4115_profile *p,
+ struct rte_meter_trtcm_rfc4115_params *params)
+{
+ return rte_meter_trtcm_rfc4115_profile_config_(p, params);
+}
+BIND_DEFAULT_SYMBOL(rte_meter_trtcm_rfc4115_profile_config, _s, 20.0.1);
+MAP_STATIC_SYMBOL(int rte_meter_trtcm_rfc4115_profile_config(struct rte_meter_trtcm_rfc4115_profile *p,
+ struct rte_meter_trtcm_rfc4115_params *params), rte_meter_trtcm_rfc4115_profile_config_s);
+
+int
+rte_meter_trtcm_rfc4115_profile_config_e(
+ struct rte_meter_trtcm_rfc4115_profile *p,
+ struct rte_meter_trtcm_rfc4115_params *params);
+int
+rte_meter_trtcm_rfc4115_profile_config_e(
+ struct rte_meter_trtcm_rfc4115_profile *p,
+ struct rte_meter_trtcm_rfc4115_params *params)
+{
+ return rte_meter_trtcm_rfc4115_profile_config_(p, params);
+}
+VERSION_SYMBOL_EXPERIMENTAL(rte_meter_trtcm_rfc4115_profile_config, _e);
+
+static int
+rte_meter_trtcm_rfc4115_config_(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p)
{
@@ -160,3 +189,27 @@ rte_meter_trtcm_rfc4115_config(
return 0;
}
+
+int
+rte_meter_trtcm_rfc4115_config_s(struct rte_meter_trtcm_rfc4115 *m,
+ struct rte_meter_trtcm_rfc4115_profile *p);
+int
+rte_meter_trtcm_rfc4115_config_s(struct rte_meter_trtcm_rfc4115 *m,
+ struct rte_meter_trtcm_rfc4115_profile *p)
+{
+ return rte_meter_trtcm_rfc4115_config_(m, p);
+}
+BIND_DEFAULT_SYMBOL(rte_meter_trtcm_rfc4115_config, _s, 20.0.1);
+MAP_STATIC_SYMBOL(int rte_meter_trtcm_rfc4115_config(struct rte_meter_trtcm_rfc4115 *m,
+ struct rte_meter_trtcm_rfc4115_profile *p), rte_meter_trtcm_rfc4115_config_s);
+
+int
+rte_meter_trtcm_rfc4115_config_e(struct rte_meter_trtcm_rfc4115 *m,
+ struct rte_meter_trtcm_rfc4115_profile *p);
+int
+rte_meter_trtcm_rfc4115_config_e(struct rte_meter_trtcm_rfc4115 *m,
+ struct rte_meter_trtcm_rfc4115_profile *p)
+{
+ return rte_meter_trtcm_rfc4115_config_(m, p);
+}
+VERSION_SYMBOL_EXPERIMENTAL(rte_meter_trtcm_rfc4115_config, _e);
@@ -20,4 +20,12 @@ DPDK_20.0.1 {
rte_meter_trtcm_rfc4115_color_blind_check;
rte_meter_trtcm_rfc4115_config;
rte_meter_trtcm_rfc4115_profile_config;
+
} DPDK_20.0;
+
+EXPERIMENTAL {
+ global:
+
+ rte_meter_trtcm_rfc4115_config;
+ rte_meter_trtcm_rfc4115_profile_config;
+};