* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 12:32 4% ` Bruce Richardson
@ 2019-04-24 12:32 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-24 12:32 UTC (permalink / raw)
To: Peng Huang; +Cc: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
2019-04-24 12:08 4% ` Neil Horman
@ 2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-24 12:32 UTC (permalink / raw)
To: Peng Huang; +Cc: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:22 9% ` Ray Kinsella
@ 2019-04-24 12:22 9% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-24 12:22 UTC (permalink / raw)
To: Burakov, Anatoly, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24/04/2019 12:08, Burakov, Anatoly wrote:
> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>>
>>
>> On 18/04/2019 11:28, Bruce Richardson wrote:
>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>>
>>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>>>> Hello,
>>>>>> There was a conversation [1] in the context of RCU library. I
>>>>>> thought
>>>>>> it needs participation from broader audience. Summary for the context
>>>>>> (please look at [1] for full details)
>>>>>>
>>>>>
>>>>> Thanks for kicking off this discussion
>>>>>
>>>>>> 1) How do we provide ABI compatibility when the code base contains
>>>>> inline functions? Unless we freeze development in these inline
>>>>> functions and
>>>>> corresponding structures, it might not be possible to claim ABI
>>>>> compatibility.
>>>>> Application has to be recompiled.
>>>>>
>>>>> I agree that in some cases the application "might" need to be
>>>>> recompiled,
>>>>> but on the other hand I also think that there are many cases where ABI
>>>>> function versioning can still be used to mitigate things. For
>>>>> example, if we
>>>>> think of a couple of various scenarios:
>>>>>
>>>>> 1. If everything is inline and variables are allocated by app, e.g.
>>>>> spinlock on stack, then there is no issue as everything is application
>>>>> contained.
>>>> If there is a bug fix which requires the structure to change, the
>>>> application would need to recompile. I guess you are talking about a
>>>> scenario when nothing changed in the inline function/variables.
>>>>
>>>
>>> If the application wants the bugfix, then yes. However, if the app is
>>> unaffected by the bug, then it should have the option of updating DPDK
>>> without a recompile.
>>
>> I would also imagine that should be an extremely rare case, that a
>> bugfix would require a structure change ... perhaps for an alignment
>> issues?
>
> Multiprocess threading issues is one case i've had to do that more than
> once.
Another reason to dislike multi process I guess.
>
> <snip>
>
>
>>
>> The reality is that most other system libraries provide strong
>> guarantees ... to date we have provided very little.
>>
>
> To our credit, the libraries you're likely referring to aren't trying to
> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
> just because we like doing them - DPDK is complex, and getting
> everything right the first time *and* allowing for future evolution is
> not a trivial undertaking.
>
>
> To me, part of the problem is that DPDK is an "everything and the
> kitchen sink" kind of library where there is a bunch of drivers, a whole
> quasi-OS layer of dealing with hardware in a cross-platform manner, a
> separate memory management system, a bunch of libraries such as hash/lpm
> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> library" would concentrate on doing one thing well. DPDK, on the other
> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> is, i think, contributing to the breakages. If you keep 99% of your
> libraries stable between version, but there's a small ABI tweak in an
> LPM library, the entire DPDK stability gets invalidated.
Well I guess DPDK is no more complex than Java or .NET Framework in that
respect, as these also feature OS-layers, memory management systems,
application frameworks, primitives etc but do manage to give their
consumers strong guarantee's on API stability. Clearly ABI stability has
a no meaning when you always being JIT compiled.
I understand that doing everything right the first time, allowing for
future evolution, while keep ABI/APIs relatively stable is a tough ask.
I would propose that API's marked as "experimental" be given greater
freedom to change to give time of API's to bake, so they don't need to
be always "right first time", that there is wriggle room for these.
I would also propose more use of ABI Versioning to enable evolution of
DPDK while preserving backward compatibility.
>
> Perhaps limiting DPDK's scope would help with this as well.
I agree.
>
>>
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 11:08 8% ` Burakov, Anatoly
@ 2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-24 12:22 UTC (permalink / raw)
To: Burakov, Anatoly, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24/04/2019 12:08, Burakov, Anatoly wrote:
> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>>
>>
>> On 18/04/2019 11:28, Bruce Richardson wrote:
>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>>
>>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>>>> Hello,
>>>>>> There was a conversation [1] in the context of RCU library. I
>>>>>> thought
>>>>>> it needs participation from broader audience. Summary for the context
>>>>>> (please look at [1] for full details)
>>>>>>
>>>>>
>>>>> Thanks for kicking off this discussion
>>>>>
>>>>>> 1) How do we provide ABI compatibility when the code base contains
>>>>> inline functions? Unless we freeze development in these inline
>>>>> functions and
>>>>> corresponding structures, it might not be possible to claim ABI
>>>>> compatibility.
>>>>> Application has to be recompiled.
>>>>>
>>>>> I agree that in some cases the application "might" need to be
>>>>> recompiled,
>>>>> but on the other hand I also think that there are many cases where ABI
>>>>> function versioning can still be used to mitigate things. For
>>>>> example, if we
>>>>> think of a couple of various scenarios:
>>>>>
>>>>> 1. If everything is inline and variables are allocated by app, e.g.
>>>>> spinlock on stack, then there is no issue as everything is application
>>>>> contained.
>>>> If there is a bug fix which requires the structure to change, the
>>>> application would need to recompile. I guess you are talking about a
>>>> scenario when nothing changed in the inline function/variables.
>>>>
>>>
>>> If the application wants the bugfix, then yes. However, if the app is
>>> unaffected by the bug, then it should have the option of updating DPDK
>>> without a recompile.
>>
>> I would also imagine that should be an extremely rare case, that a
>> bugfix would require a structure change ... perhaps for an alignment
>> issues?
>
> Multiprocess threading issues is one case i've had to do that more than
> once.
Another reason to dislike multi process I guess.
>
> <snip>
>
>
>>
>> The reality is that most other system libraries provide strong
>> guarantees ... to date we have provided very little.
>>
>
> To our credit, the libraries you're likely referring to aren't trying to
> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
> just because we like doing them - DPDK is complex, and getting
> everything right the first time *and* allowing for future evolution is
> not a trivial undertaking.
>
>
> To me, part of the problem is that DPDK is an "everything and the
> kitchen sink" kind of library where there is a bunch of drivers, a whole
> quasi-OS layer of dealing with hardware in a cross-platform manner, a
> separate memory management system, a bunch of libraries such as hash/lpm
> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> library" would concentrate on doing one thing well. DPDK, on the other
> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> is, i think, contributing to the breakages. If you keep 99% of your
> libraries stable between version, but there's a small ABI tweak in an
> LPM library, the entire DPDK stability gets invalidated.
Well I guess DPDK is no more complex than Java or .NET Framework in that
respect, as these also feature OS-layers, memory management systems,
application frameworks, primitives etc but do manage to give their
consumers strong guarantee's on API stability. Clearly ABI stability has
a no meaning when you always being JIT compiled.
I understand that doing everything right the first time, allowing for
future evolution, while keep ABI/APIs relatively stable is a tough ask.
I would propose that API's marked as "experimental" be given greater
freedom to change to give time of API's to bake, so they don't need to
be always "right first time", that there is wriggle room for these.
I would also propose more use of ABI Versioning to enable evolution of
DPDK while preserving backward compatibility.
>
> Perhaps limiting DPDK's scope would help with this as well.
I agree.
>
>>
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 12:08 4% ` Neil Horman
@ 2019-04-24 12:08 4% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-04-24 12:08 UTC (permalink / raw)
To: Peng Huang; +Cc: qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
@ 2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2 siblings, 1 reply; 200+ results
From: Neil Horman @ 2019-04-24 12:08 UTC (permalink / raw)
To: Peng Huang; +Cc: qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-24 11:37 0% ` Neil Horman
@ 2019-04-24 11:37 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-04-24 11:37 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1993 bytes --]
On Tue, Apr 23, 2019 at 07:13:24PM +0200, Mattias Rönnblom wrote:
> On 2019-04-23 13:33, Neil Horman wrote:
> > On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> > > On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > > > On 2019-04-22 13:34, Neil Horman wrote:
> > > >
> > > > > > +uint64_t __rte_experimental
> > > > > > +rte_rand(void)
> > > > > Do you really want to mark this as experimental? I know it will
> > > > > trigger the
> > > > > symbol checker with a warning if you don't, but this function
> > > > > already existed
> > > > > previously and was accepted as part of the ABI. Given that the
> > > > > prototype hasn't
> > > > > changed, I think you just need to accept it as a non-experimental
> > > > > function
> > > > >
> > > >
> > > > I'll remove the experimental tag and move it into the 19_05 section
> > > > (without suggesting it should go into 19.05). That maneuver seems not to
> > > > trigger any build warnings/errors.
> > > >
> > >
> > > OK, so that wasn't true. It does trigger a build error, courtesy of
> > > buildtools/check-experimental-syms.sh.
> > >
> > > I can't see any obvious way around it. Ideas, anyone?
> > >
> > No, we would have to waive it.
>
> I don't understand. What do you mean?
>
I mean we have to work around the error, understanding that its not really
experimental. My first suggestion would be to make a commit with the symbol as
experimental, than add a new commit moving it into the proper section of the
version map
> > But its pretty clear that This function has been
> > around forever, so I think it would be worse to demote it to an experimental
> > symbol. The only thing you're doing here is moving it from an inline function
> > (which is arguably part of the ABI, even if it never appeared as a symbol in the
> > ELF file), to a fully fleged symbol with a new implementation.
> >
>
> I agree it shouldn't be marked experimental. The reason for doing so was to
> avoid triggering a build error.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 17:13 0% ` Mattias Rönnblom
@ 2019-04-24 11:37 0% ` Neil Horman
2019-04-24 11:37 0% ` Neil Horman
1 sibling, 1 reply; 200+ results
From: Neil Horman @ 2019-04-24 11:37 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Tue, Apr 23, 2019 at 07:13:24PM +0200, Mattias Rönnblom wrote:
> On 2019-04-23 13:33, Neil Horman wrote:
> > On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> > > On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > > > On 2019-04-22 13:34, Neil Horman wrote:
> > > >
> > > > > > +uint64_t __rte_experimental
> > > > > > +rte_rand(void)
> > > > > Do you really want to mark this as experimental? I know it will
> > > > > trigger the
> > > > > symbol checker with a warning if you don't, but this function
> > > > > already existed
> > > > > previously and was accepted as part of the ABI. Given that the
> > > > > prototype hasn't
> > > > > changed, I think you just need to accept it as a non-experimental
> > > > > function
> > > > >
> > > >
> > > > I'll remove the experimental tag and move it into the 19_05 section
> > > > (without suggesting it should go into 19.05). That maneuver seems not to
> > > > trigger any build warnings/errors.
> > > >
> > >
> > > OK, so that wasn't true. It does trigger a build error, courtesy of
> > > buildtools/check-experimental-syms.sh.
> > >
> > > I can't see any obvious way around it. Ideas, anyone?
> > >
> > No, we would have to waive it.
>
> I don't understand. What do you mean?
>
I mean we have to work around the error, understanding that its not really
experimental. My first suggestion would be to make a commit with the symbol as
experimental, than add a new commit moving it into the proper section of the
version map
> > But its pretty clear that This function has been
> > around forever, so I think it would be worse to demote it to an experimental
> > symbol. The only thing you're doing here is moving it from an inline function
> > (which is arguably part of the ABI, even if it never appeared as a symbol in the
> > ELF file), to a fully fleged symbol with a new implementation.
> >
>
> I agree it shouldn't be marked experimental. The reason for doing so was to
> avoid triggering a build error.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 11:08 8% ` Burakov, Anatoly
@ 2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 12:22 9% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 11:08 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>
>
> On 18/04/2019 11:28, Bruce Richardson wrote:
>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>
>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>>> Hello,
>>>>> There was a conversation [1] in the context of RCU library. I thought
>>>>> it needs participation from broader audience. Summary for the context
>>>>> (please look at [1] for full details)
>>>>>
>>>>
>>>> Thanks for kicking off this discussion
>>>>
>>>>> 1) How do we provide ABI compatibility when the code base contains
>>>> inline functions? Unless we freeze development in these inline functions and
>>>> corresponding structures, it might not be possible to claim ABI compatibility.
>>>> Application has to be recompiled.
>>>>
>>>> I agree that in some cases the application "might" need to be recompiled,
>>>> but on the other hand I also think that there are many cases where ABI
>>>> function versioning can still be used to mitigate things. For example, if we
>>>> think of a couple of various scenarios:
>>>>
>>>> 1. If everything is inline and variables are allocated by app, e.g.
>>>> spinlock on stack, then there is no issue as everything is application
>>>> contained.
>>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>>
>>
>> If the application wants the bugfix, then yes. However, if the app is
>> unaffected by the bug, then it should have the option of updating DPDK
>> without a recompile.
>
> I would also imagine that should be an extremely rare case, that a
> bugfix would require a structure change ... perhaps for an alignment issues?
Multiprocess threading issues is one case i've had to do that more than
once.
<snip>
>
> The reality is that most other system libraries provide strong
> guarantees ... to date we have provided very little.
>
To our credit, the libraries you're likely referring to aren't trying to
reimplement the Linux kernel :) I don't think we do these API/ABI breaks
just because we like doing them - DPDK is complex, and getting
everything right the first time *and* allowing for future evolution is
not a trivial undertaking.
To me, part of the problem is that DPDK is an "everything and the
kitchen sink" kind of library where there is a bunch of drivers, a whole
quasi-OS layer of dealing with hardware in a cross-platform manner, a
separate memory management system, a bunch of libraries such as hash/lpm
tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
library" would concentrate on doing one thing well. DPDK, on the other
hand, tries to do *everything* well. The sheer breadth of DPDK's scope
is, i think, contributing to the breakages. If you keep 99% of your
libraries stable between version, but there's a small ABI tweak in an
LPM library, the entire DPDK stability gets invalidated.
Perhaps limiting DPDK's scope would help with this as well.
>
>>
>> Regards,
>> /Bruce
>>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:15 7% ` Honnappa Nagarahalli
@ 2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 12:22 9% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 11:08 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>
>
> On 18/04/2019 11:28, Bruce Richardson wrote:
>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>
>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>>> Hello,
>>>>> There was a conversation [1] in the context of RCU library. I thought
>>>>> it needs participation from broader audience. Summary for the context
>>>>> (please look at [1] for full details)
>>>>>
>>>>
>>>> Thanks for kicking off this discussion
>>>>
>>>>> 1) How do we provide ABI compatibility when the code base contains
>>>> inline functions? Unless we freeze development in these inline functions and
>>>> corresponding structures, it might not be possible to claim ABI compatibility.
>>>> Application has to be recompiled.
>>>>
>>>> I agree that in some cases the application "might" need to be recompiled,
>>>> but on the other hand I also think that there are many cases where ABI
>>>> function versioning can still be used to mitigate things. For example, if we
>>>> think of a couple of various scenarios:
>>>>
>>>> 1. If everything is inline and variables are allocated by app, e.g.
>>>> spinlock on stack, then there is no issue as everything is application
>>>> contained.
>>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>>
>>
>> If the application wants the bugfix, then yes. However, if the app is
>> unaffected by the bug, then it should have the option of updating DPDK
>> without a recompile.
>
> I would also imagine that should be an extremely rare case, that a
> bugfix would require a structure change ... perhaps for an alignment issues?
Multiprocess threading issues is one case i've had to do that more than
once.
<snip>
>
> The reality is that most other system libraries provide strong
> guarantees ... to date we have provided very little.
>
To our credit, the libraries you're likely referring to aren't trying to
reimplement the Linux kernel :) I don't think we do these API/ABI breaks
just because we like doing them - DPDK is complex, and getting
everything right the first time *and* allowing for future evolution is
not a trivial undertaking.
To me, part of the problem is that DPDK is an "everything and the
kitchen sink" kind of library where there is a bunch of drivers, a whole
quasi-OS layer of dealing with hardware in a cross-platform manner, a
separate memory management system, a bunch of libraries such as hash/lpm
tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
library" would concentrate on doing one thing well. DPDK, on the other
hand, tries to do *everything* well. The sheer breadth of DPDK's scope
is, i think, contributing to the breakages. If you keep 99% of your
libraries stable between version, but there's a small ABI tweak in an
LPM library, the entire DPDK stability gets invalidated.
Perhaps limiting DPDK's scope would help with this as well.
>
>>
>> Regards,
>> /Bruce
>>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
2019-04-24 8:56 4% ` Bruce Richardson
@ 2019-04-24 8:56 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-24 8:56 UTC (permalink / raw)
To: Peng Huang; +Cc: maintainer, dev
On Wed, Apr 24, 2019 at 08:18:09AM +0000, Peng Huang wrote:
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
I think you need a fuller description of the problem here - that although
"linux" is the new target name, we still need to use "linuxapp" for testing
historical versions.
Fixes tag also needed.
/Bruce
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
2019-04-24 8:18 20% [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh Peng Huang
2019-04-24 8:18 20% ` Peng Huang
@ 2019-04-24 8:56 4% ` Bruce Richardson
2019-04-24 8:56 4% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-24 8:56 UTC (permalink / raw)
To: Peng Huang; +Cc: maintainer, dev
On Wed, Apr 24, 2019 at 08:18:09AM +0000, Peng Huang wrote:
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
I think you need a fuller description of the problem here - that although
"linux" is the new target name, we still need to use "linuxapp" for testing
historical versions.
Fixes tag also needed.
/Bruce
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 8:49 4% ` Bruce Richardson
@ 2019-04-24 8:49 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-24 8:49 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 24, 2019 at 05:08:46AM +0000, Honnappa Nagarahalli wrote:
> > > > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> > wrote:
> > > > > Hello,
<snip>
> > > >
> > > > 2. If the situation is as in #1, but the structures in question are
> > > > passed to non-inline DPDK functions. In this case, any changes to
> > > > the structures require those functions taking the structures to be
> > > > versioned for old and new structures
> > > I think this can get complicated on the inline function side. The application
> > and the DPDK library will end up having different inline functions. The
> > changed inline function needs to be aware of 2 structure formats or the inline
> > function needs to be duplicated (one for each version of the structure). I
> > guess these are the workarounds we have to do.
> > >
> > No, there is never any need for two versions of the inline functions, only the
> > newest version is needed. This is because in the case of a newly compiled
> > application only the newest version of the non-inline functions is ever used.
> > The other older versions are only used at runtime for compatilibity with pre-
> > compiled apps with the older inlines.
> >
> Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
>
Ok, if the inline function is used both in DPDK libs and apps, then indeed
we have a slightly more complex problem. I was mostly assuming the inlines
were for app use only, but you are right that we have internally used ones
also. However, I expect this only makes the problem a little harder rather
than impossible - we would need two versions of the inline function,
however, only one needs to be exposed publically.
Really, the main upshot is that we need to reduce use of inline functions
except where absolutely necessary, and then hide structures as much as
possible. I don't see anyone disagreeing with that goal. :-)
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 5:08 7% ` Honnappa Nagarahalli
@ 2019-04-24 8:49 4% ` Bruce Richardson
2019-04-24 8:49 4% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-24 8:49 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 24, 2019 at 05:08:46AM +0000, Honnappa Nagarahalli wrote:
> > > > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> > wrote:
> > > > > Hello,
<snip>
> > > >
> > > > 2. If the situation is as in #1, but the structures in question are
> > > > passed to non-inline DPDK functions. In this case, any changes to
> > > > the structures require those functions taking the structures to be
> > > > versioned for old and new structures
> > > I think this can get complicated on the inline function side. The application
> > and the DPDK library will end up having different inline functions. The
> > changed inline function needs to be aware of 2 structure formats or the inline
> > function needs to be duplicated (one for each version of the structure). I
> > guess these are the workarounds we have to do.
> > >
> > No, there is never any need for two versions of the inline functions, only the
> > newest version is needed. This is because in the case of a newly compiled
> > application only the newest version of the non-inline functions is ever used.
> > The other older versions are only used at runtime for compatilibity with pre-
> > compiled apps with the older inlines.
> >
> Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
>
Ok, if the inline function is used both in DPDK libs and apps, then indeed
we have a slightly more complex problem. I was mostly assuming the inlines
were for app use only, but you are right that we have internally used ones
also. However, I expect this only makes the problem a little harder rather
than impossible - we would need two versions of the inline function,
however, only one needs to be exposed publically.
Really, the main upshot is that we need to reduce use of inline functions
except where absolutely necessary, and then hide structures as much as
possible. I don't see anyone disagreeing with that goal. :-)
/Bruce
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:32 4% ` Bruce Richardson
@ 2019-04-24 15:11 22% ` Peng Huang
2 siblings, 0 replies; 200+ results
From: Peng Huang @ 2019-04-24 15:11 UTC (permalink / raw)
To: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu; +Cc: dev, peng.huang, stable
The new default-taget "linux" is introduced in v19.05-rc1
but not exist in before release such as v19.02 which have
default-target "linuxapp", there is no compatibility report
when run validate-abi.sh to check ABI compatibility between
v19.05-rc1 and v19.02, changed default-target from "linux"
to "linuxapp" in validate-abi.sh
Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
Cc: stable@dpdk.org
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 22%]
* [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
@ 2019-04-24 15:11 22% Peng Huang
2019-04-24 12:08 4% ` Neil Horman
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Peng Huang @ 2019-04-24 15:11 UTC (permalink / raw)
To: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu; +Cc: dev, peng.huang, stable
The new default-taget "linux" is introduced in v19.05-rc1
but not exist in before release such as v19.02 which have
default-target "linuxapp", there is no compatibility report
when run validate-abi.sh to check ABI compatibility between
v19.05-rc1 and v19.02, changed default-target from "linux"
to "linuxapp" in validate-abi.sh
Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
Cc: stable@dpdk.org
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 22%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-24 7:52 0% ` Mattias Rönnblom
@ 2019-04-24 7:52 0% ` Mattias Rönnblom
0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-24 7:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 19:17, Mattias Rönnblom wrote:
> On 2019-04-23 17:31, Stephen Hemminger wrote:
>> On Mon, 22 Apr 2019 19:44:39 +0200
>> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>>
>>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>>>> +uint64_t __rte_experimental
>>>>>> +rte_rand(void)
>>>>> Do you really want to mark this as experimental? I know it will
>>>>> trigger the
>>>>> symbol checker with a warning if you don't, but this function already
>>>>> existed
>>>>> previously and was accepted as part of the ABI. Given that the
>>>>> prototype hasn't
>>>>> changed, I think you just need to accept it as a non-experimental
>>>>> function
>>>>
>>>> I'll remove the experimental tag and move it into the 19_05 section
>>>> (without suggesting it should go into 19.05). That maneuver seems
>>>> not to
>>>> trigger any build warnings/errors.
>>>
>>> OK, so that wasn't true. It does trigger a build error, courtesy of
>>> buildtools/check-experimental-syms.sh.
>>>
>>> I can't see any obvious way around it. Ideas, anyone?
>>
>> Ignore the error, the build tool is not smart enough for this kind of
>> change.
>>
>
> It stops the build.
OK, so what was the way of a successful build was not the
check-experimental-syms.sh script, but my incompetence. I had listed
rte_rand in both the 19_05 section, and the EXPERIMENTAL section.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-23 17:17 0% ` Mattias Rönnblom
@ 2019-04-24 7:52 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
1 sibling, 1 reply; 200+ results
From: Mattias Rönnblom @ 2019-04-24 7:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 19:17, Mattias Rönnblom wrote:
> On 2019-04-23 17:31, Stephen Hemminger wrote:
>> On Mon, 22 Apr 2019 19:44:39 +0200
>> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>>
>>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>>>> +uint64_t __rte_experimental
>>>>>> +rte_rand(void)
>>>>> Do you really want to mark this as experimental? I know it will
>>>>> trigger the
>>>>> symbol checker with a warning if you don't, but this function already
>>>>> existed
>>>>> previously and was accepted as part of the ABI. Given that the
>>>>> prototype hasn't
>>>>> changed, I think you just need to accept it as a non-experimental
>>>>> function
>>>>
>>>> I'll remove the experimental tag and move it into the 19_05 section
>>>> (without suggesting it should go into 19.05). That maneuver seems
>>>> not to
>>>> trigger any build warnings/errors.
>>>
>>> OK, so that wasn't true. It does trigger a build error, courtesy of
>>> buildtools/check-experimental-syms.sh.
>>>
>>> I can't see any obvious way around it. Ideas, anyone?
>>
>> Ignore the error, the build tool is not smart enough for this kind of
>> change.
>>
>
> It stops the build.
OK, so what was the way of a successful build was not the
check-experimental-syms.sh script, but my incompetence. I had listed
rte_rand in both the 19_05 section, and the EXPERIMENTAL section.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 5:15 7% ` Honnappa Nagarahalli
@ 2019-04-24 5:15 7% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:15 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd, nd
> On 18/04/2019 11:28, Bruce Richardson wrote:
> > On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >>>
> >>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> wrote:
> >>>> Hello,
> >>>> There was a conversation [1] in the context of RCU library. I
> >>>> thought it needs participation from broader audience. Summary for
> >>>> the context (please look at [1] for full details)
> >>>>
> >>>
> >>> Thanks for kicking off this discussion
> >>>
> >>>> 1) How do we provide ABI compatibility when the code base contains
> >>> inline functions? Unless we freeze development in these inline
> >>> functions and corresponding structures, it might not be possible to claim
> ABI compatibility.
> >>> Application has to be recompiled.
> >>>
> >>> I agree that in some cases the application "might" need to be
> >>> recompiled, but on the other hand I also think that there are many
> >>> cases where ABI function versioning can still be used to mitigate
> >>> things. For example, if we think of a couple of various scenarios:
> >>>
> >>> 1. If everything is inline and variables are allocated by app, e.g.
> >>> spinlock on stack, then there is no issue as everything is
> >>> application contained.
> >> If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >>
> >
> > If the application wants the bugfix, then yes. However, if the app is
> > unaffected by the bug, then it should have the option of updating DPDK
> > without a recompile.
>
> I would also imagine that should be an extremely rare case, that a bugfix
> would require a structure change ... perhaps for an alignment issues?
>
> >
> >>>
> >>> 2. If the situation is as in #1, but the structures in question are
> >>> passed to non-inline DPDK functions. In this case, any changes to
> >>> the structures require those functions taking the structures to be
> >>> versioned for old and new structures
> >> I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >>
> > No, there is never any need for two versions of the inline functions,
> > only the newest version is needed. This is because in the case of a
> > newly compiled application only the newest version of the non-inline
> > functions is ever used. The other older versions are only used at
> > runtime for compatilibity with pre-compiled apps with the older inlines.
> >
> >>>
> >>> 3. If instead we have the case, like in rte_ring, where the data
> >>> structures are allocated using functions, but they are used via
> >>> inlines in the app. In this case the creation functions (and any
> >>> other function using the structures) need to be versioned so that
> >>> the application gets the expected structure back from the creation.
> >> The new structure members have to be added such that the previous
> >> layout is not affected. Either add at the end or use the gaps that
> >> are left because of cache line alignment.
> >>
> > Not necessarily. There is nothing that requires the older and newer
> > versions of a function to use the same structure. We can rename the
> > original structure when versioning the old function, and then create a
> > new structure with the original name for later recompiled code using
> > the newest ABIs.
> >
> >>>
> >>> It might be useful to think of what other scenarios we have and what
> >>> ones are likely to be problematic, especially those that can't be
> >>> solved by having multiple function versions.
> >>>
> >>>> 2) Every function that is not in the direct datapath (fastpath?)
> >>>> should not be inline. Exceptions or things like rx/tx burst, ring
> >>>> enqueue/dequeue, and packet alloc/free - Stephen
> >>>
> >>> Agree with this. Anything not data path should not be inline. The
> >>> next
> >> Yes, very clear on this.
> >>
> >>> question then is for data path items how to determine whether they
> >>> need to be inline or not. In general my rule-of-thumb:
> >>> * anything dealing with bursts of packets should not be inline
> >>> * anything what works with single packet at a time should be inline
> >>>
> >>> The one exception to this rule is cases where we have to consider
> >>> "empty polling" as a likely use-case. For example,
> >>> rte_ring_dequeue_burst works with bursts of packets, but there is a
> >>> valid application use case where a thread could be polling a set of
> >>> rings where only a small number are actually busy. Right now,
> >>> polling an empty ring only costs a few cycles, meaning that it's
> >>> neglible to have a few polls of empty rings before you get to a busy
> >>> one. Having that function not-inline will cause that cost to jump
> >>> significantly, so could cause problems. (This leads to the interesting
> scenario where ring enqueue is safe to un-inline, while dequeue is not).
> >> A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >>
> >
> > Yes, I would tend to agree in general. The other thing is the
> > frequency of calls, and - as already stated - whether it takes a burst
> > of not. Because even if it's a trivial function that takes only 10
> > cycles and we want to uninline it, the cost may double; but if it
> > takes a burst of packets and is only used once/twice per burst the
> > cost per packet should still only be a fraction of a cycle.
> >
> >>>
> >>>> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
> >>>> rcu should be one of such exceptions - it is just another
> >>>> synchronization mechanism after all (just a bit more
> >>>> sophisticated). - Konstantin
> >>>>
> >>> In general I believe the synchronisation primitives should be inline.
> >>> However, it does come down to cost too - if a function takes 300
> >>> cycles, do we really care if it takes 305 or 310 instead to make it not
> inline?
> >>> Hopefully most synchronisation primitives are faster than this so
> >>> this situation should not occur.
> >>>
> >>>> 2) and 3) can be good guidelines to what functions/APIs can be
> >>>> inline. But,
> >>> I believe this guideline exists today too. Are there any thoughts to
> >>> change this?
> >>>>
> >>>> Coming to 1), I think DPDK cannot provide ABI compatibility unless
> >>>> all the
> >>> inline functions are converted to normal functions and symbol
> >>> versioning is done for those (not bothering about performance).
> >>>>
> >>> I disagree. I think even in the case of #1, we should be able to
> >>> manage some changes without breaking ABI.
> >> I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >>
> > Having multiple LTS's per distro would be nice, but it's putting a lot
> > more work on the distro folks, I think.
>
> I completely disagree with this approach.
> Anytime I have seen this done, most frequently with interpreted languages,
> think multiple versions of Java and Python concurrently on a system, it has
> always been a usability nightmare.
>
>
> >
> >>>
> >>>> In this context, does it make sense to say that we will maintain
> >>>> API compatibility rather than saying ABI compatibility? This will
> >>>> also send the right message to the end users.
> >>>>
> >>> I would value ABI compatibility much higher than API compatibility.
> >>> If someone is recompiling the application anyway, making a couple of
> >>> small changes (large rework is obviously a different issue) to the
> >>> code should not be a massive issue, I hope. On the other hand, ABI
> >>> compatibility is needed to allow seamless update from one version to
> >>> another, and it's that ABI compatiblity that allows distro's to pick up our
> latest and greatest versions.
> >>>
> >> I think it is also important to setup the right expectations to DPDK users.
> i.e. DPDK will police itself better to provide ABI compatibility but occasionally
> it might not be possible.
> >>
> > The trouble here is that a DPDK release, as a product is either
> > backward compatible or not. Either a user can take it as a drop-in
> > replacement for the previous version or not. Users do not want to have
> > to go through a checklist for each app to see if the app uses only
> > "compatible" APIs or not. Same for the distro folks, they are not
> > going to take some libs from a release but not others because the ABI is
> broken for some but not others.
>
> Agreed, a DPDK release is either backwards compatible or it isn't, and to
> Bruce's point if it isn't, it maters less if this is for a big API change or a small
> API change - the failure of the API stability guarantee is the significant piece.
>
> The reality is that most other system libraries provide strong guarantees ... to
> date we have provided very little.
It would be good to look libraries that provide inline functions and ABI compatibility to better understand the methods used.
>
> If we start saying "Yes, but except when", the exception case very quickly
> becomes the general case and then we are back to the beginning again.
>
> >
> > Regards,
> > /Bruce
> >
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
@ 2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 11:08 8% ` Burakov, Anatoly
2 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:15 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd, nd
> On 18/04/2019 11:28, Bruce Richardson wrote:
> > On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >>>
> >>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> wrote:
> >>>> Hello,
> >>>> There was a conversation [1] in the context of RCU library. I
> >>>> thought it needs participation from broader audience. Summary for
> >>>> the context (please look at [1] for full details)
> >>>>
> >>>
> >>> Thanks for kicking off this discussion
> >>>
> >>>> 1) How do we provide ABI compatibility when the code base contains
> >>> inline functions? Unless we freeze development in these inline
> >>> functions and corresponding structures, it might not be possible to claim
> ABI compatibility.
> >>> Application has to be recompiled.
> >>>
> >>> I agree that in some cases the application "might" need to be
> >>> recompiled, but on the other hand I also think that there are many
> >>> cases where ABI function versioning can still be used to mitigate
> >>> things. For example, if we think of a couple of various scenarios:
> >>>
> >>> 1. If everything is inline and variables are allocated by app, e.g.
> >>> spinlock on stack, then there is no issue as everything is
> >>> application contained.
> >> If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >>
> >
> > If the application wants the bugfix, then yes. However, if the app is
> > unaffected by the bug, then it should have the option of updating DPDK
> > without a recompile.
>
> I would also imagine that should be an extremely rare case, that a bugfix
> would require a structure change ... perhaps for an alignment issues?
>
> >
> >>>
> >>> 2. If the situation is as in #1, but the structures in question are
> >>> passed to non-inline DPDK functions. In this case, any changes to
> >>> the structures require those functions taking the structures to be
> >>> versioned for old and new structures
> >> I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >>
> > No, there is never any need for two versions of the inline functions,
> > only the newest version is needed. This is because in the case of a
> > newly compiled application only the newest version of the non-inline
> > functions is ever used. The other older versions are only used at
> > runtime for compatilibity with pre-compiled apps with the older inlines.
> >
> >>>
> >>> 3. If instead we have the case, like in rte_ring, where the data
> >>> structures are allocated using functions, but they are used via
> >>> inlines in the app. In this case the creation functions (and any
> >>> other function using the structures) need to be versioned so that
> >>> the application gets the expected structure back from the creation.
> >> The new structure members have to be added such that the previous
> >> layout is not affected. Either add at the end or use the gaps that
> >> are left because of cache line alignment.
> >>
> > Not necessarily. There is nothing that requires the older and newer
> > versions of a function to use the same structure. We can rename the
> > original structure when versioning the old function, and then create a
> > new structure with the original name for later recompiled code using
> > the newest ABIs.
> >
> >>>
> >>> It might be useful to think of what other scenarios we have and what
> >>> ones are likely to be problematic, especially those that can't be
> >>> solved by having multiple function versions.
> >>>
> >>>> 2) Every function that is not in the direct datapath (fastpath?)
> >>>> should not be inline. Exceptions or things like rx/tx burst, ring
> >>>> enqueue/dequeue, and packet alloc/free - Stephen
> >>>
> >>> Agree with this. Anything not data path should not be inline. The
> >>> next
> >> Yes, very clear on this.
> >>
> >>> question then is for data path items how to determine whether they
> >>> need to be inline or not. In general my rule-of-thumb:
> >>> * anything dealing with bursts of packets should not be inline
> >>> * anything what works with single packet at a time should be inline
> >>>
> >>> The one exception to this rule is cases where we have to consider
> >>> "empty polling" as a likely use-case. For example,
> >>> rte_ring_dequeue_burst works with bursts of packets, but there is a
> >>> valid application use case where a thread could be polling a set of
> >>> rings where only a small number are actually busy. Right now,
> >>> polling an empty ring only costs a few cycles, meaning that it's
> >>> neglible to have a few polls of empty rings before you get to a busy
> >>> one. Having that function not-inline will cause that cost to jump
> >>> significantly, so could cause problems. (This leads to the interesting
> scenario where ring enqueue is safe to un-inline, while dequeue is not).
> >> A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >>
> >
> > Yes, I would tend to agree in general. The other thing is the
> > frequency of calls, and - as already stated - whether it takes a burst
> > of not. Because even if it's a trivial function that takes only 10
> > cycles and we want to uninline it, the cost may double; but if it
> > takes a burst of packets and is only used once/twice per burst the
> > cost per packet should still only be a fraction of a cycle.
> >
> >>>
> >>>> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
> >>>> rcu should be one of such exceptions - it is just another
> >>>> synchronization mechanism after all (just a bit more
> >>>> sophisticated). - Konstantin
> >>>>
> >>> In general I believe the synchronisation primitives should be inline.
> >>> However, it does come down to cost too - if a function takes 300
> >>> cycles, do we really care if it takes 305 or 310 instead to make it not
> inline?
> >>> Hopefully most synchronisation primitives are faster than this so
> >>> this situation should not occur.
> >>>
> >>>> 2) and 3) can be good guidelines to what functions/APIs can be
> >>>> inline. But,
> >>> I believe this guideline exists today too. Are there any thoughts to
> >>> change this?
> >>>>
> >>>> Coming to 1), I think DPDK cannot provide ABI compatibility unless
> >>>> all the
> >>> inline functions are converted to normal functions and symbol
> >>> versioning is done for those (not bothering about performance).
> >>>>
> >>> I disagree. I think even in the case of #1, we should be able to
> >>> manage some changes without breaking ABI.
> >> I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >>
> > Having multiple LTS's per distro would be nice, but it's putting a lot
> > more work on the distro folks, I think.
>
> I completely disagree with this approach.
> Anytime I have seen this done, most frequently with interpreted languages,
> think multiple versions of Java and Python concurrently on a system, it has
> always been a usability nightmare.
>
>
> >
> >>>
> >>>> In this context, does it make sense to say that we will maintain
> >>>> API compatibility rather than saying ABI compatibility? This will
> >>>> also send the right message to the end users.
> >>>>
> >>> I would value ABI compatibility much higher than API compatibility.
> >>> If someone is recompiling the application anyway, making a couple of
> >>> small changes (large rework is obviously a different issue) to the
> >>> code should not be a massive issue, I hope. On the other hand, ABI
> >>> compatibility is needed to allow seamless update from one version to
> >>> another, and it's that ABI compatiblity that allows distro's to pick up our
> latest and greatest versions.
> >>>
> >> I think it is also important to setup the right expectations to DPDK users.
> i.e. DPDK will police itself better to provide ABI compatibility but occasionally
> it might not be possible.
> >>
> > The trouble here is that a DPDK release, as a product is either
> > backward compatible or not. Either a user can take it as a drop-in
> > replacement for the previous version or not. Users do not want to have
> > to go through a checklist for each app to see if the app uses only
> > "compatible" APIs or not. Same for the distro folks, they are not
> > going to take some libs from a release but not others because the ABI is
> broken for some but not others.
>
> Agreed, a DPDK release is either backwards compatible or it isn't, and to
> Bruce's point if it isn't, it maters less if this is for a big API change or a small
> API change - the failure of the API stability guarantee is the significant piece.
>
> The reality is that most other system libraries provide strong guarantees ... to
> date we have provided very little.
It would be good to look libraries that provide inline functions and ABI compatibility to better understand the methods used.
>
> If we start saying "Yes, but except when", the exception case very quickly
> becomes the general case and then we are back to the beginning again.
>
> >
> > Regards,
> > /Bruce
> >
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 5:08 7% ` Honnappa Nagarahalli
@ 2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 8:49 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:08 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, nd, nd
> > > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> wrote:
> > > > Hello,
> > > > There was a conversation [1] in the context of RCU library. I
> > > > thought it needs participation from broader audience. Summary for
> > > > the context (please look at [1] for full details)
> > > >
> > >
> > > Thanks for kicking off this discussion
> > >
> > > > 1) How do we provide ABI compatibility when the code base contains
> > > inline functions? Unless we freeze development in these inline
> > > functions and corresponding structures, it might not be possible to claim
> ABI compatibility.
> > > Application has to be recompiled.
> > >
> > > I agree that in some cases the application "might" need to be
> > > recompiled, but on the other hand I also think that there are many
> > > cases where ABI function versioning can still be used to mitigate
> > > things. For example, if we think of a couple of various scenarios:
> > >
> > > 1. If everything is inline and variables are allocated by app, e.g.
> > > spinlock on stack, then there is no issue as everything is
> > > application contained.
> > If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
>
Agree on the requirement.
> > >
> > > 2. If the situation is as in #1, but the structures in question are
> > > passed to non-inline DPDK functions. In this case, any changes to
> > > the structures require those functions taking the structures to be
> > > versioned for old and new structures
> > I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >
> No, there is never any need for two versions of the inline functions, only the
> newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever used.
> The other older versions are only used at runtime for compatilibity with pre-
> compiled apps with the older inlines.
>
Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
> > >
> > > 3. If instead we have the case, like in rte_ring, where the data
> > > structures are allocated using functions, but they are used via
> > > inlines in the app. In this case the creation functions (and any
> > > other function using the structures) need to be versioned so that
> > > the application gets the expected structure back from the creation.
> > The new structure members have to be added such that the previous
> > layout is not affected. Either add at the end or use the gaps that are
> > left because of cache line alignment.
> >
> Not necessarily. There is nothing that requires the older and newer versions
> of a function to use the same structure. We can rename the original structure
> when versioning the old function, and then create a new structure with the
> original name for later recompiled code using the newest ABIs.
>
Agree, assuming only the app is using the inline functions.
> > >
> > > It might be useful to think of what other scenarios we have and what
> > > ones are likely to be problematic, especially those that can't be
> > > solved by having multiple function versions.
> > >
> > > > 2) Every function that is not in the direct datapath (fastpath?)
> > > > should not be inline. Exceptions or things like rx/tx burst, ring
> > > > enqueue/dequeue, and packet alloc/free - Stephen
> > >
> > > Agree with this. Anything not data path should not be inline. The
> > > next
> > Yes, very clear on this.
> >
> > > question then is for data path items how to determine whether they
> > > need to be inline or not. In general my rule-of-thumb:
> > > * anything dealing with bursts of packets should not be inline
> > > * anything what works with single packet at a time should be inline
> > >
> > > The one exception to this rule is cases where we have to consider
> > > "empty polling" as a likely use-case. For example,
> > > rte_ring_dequeue_burst works with bursts of packets, but there is a
> > > valid application use case where a thread could be polling a set of
> > > rings where only a small number are actually busy. Right now,
> > > polling an empty ring only costs a few cycles, meaning that it's
> > > neglible to have a few polls of empty rings before you get to a busy
> > > one. Having that function not-inline will cause that cost to jump
> > > significantly, so could cause problems. (This leads to the interesting
> scenario where ring enqueue is safe to un-inline, while dequeue is not).
> > A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because even
> if it's a trivial function that takes only 10 cycles and we want to uninline it,
> the cost may double; but if it takes a burst of packets and is only used
> once/twice per burst the cost per packet should still only be a fraction of a
> cycle.
>
> > >
> > > > 3) Plus synchronization routines: spin/rwlock/barrier, etc. I
> > > > think rcu should be one of such exceptions - it is just another
> > > > synchronization mechanism after all (just a bit more
> > > > sophisticated). - Konstantin
> > > >
> > > In general I believe the synchronisation primitives should be inline.
> > > However, it does come down to cost too - if a function takes 300
> > > cycles, do we really care if it takes 305 or 310 instead to make it not
> inline?
> > > Hopefully most synchronisation primitives are faster than this so
> > > this situation should not occur.
> > >
> > > > 2) and 3) can be good guidelines to what functions/APIs can be
> > > > inline. But,
> > > I believe this guideline exists today too. Are there any thoughts to
> > > change this?
> > > >
> > > > Coming to 1), I think DPDK cannot provide ABI compatibility unless
> > > > all the
> > > inline functions are converted to normal functions and symbol
> > > versioning is done for those (not bothering about performance).
> > > >
> > > I disagree. I think even in the case of #1, we should be able to
> > > manage some changes without breaking ABI.
> > I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
>
> > >
> > > > In this context, does it make sense to say that we will maintain
> > > > API compatibility rather than saying ABI compatibility? This will
> > > > also send the right message to the end users.
> > > >
> > > I would value ABI compatibility much higher than API compatibility.
> > > If someone is recompiling the application anyway, making a couple of
> > > small changes (large rework is obviously a different issue) to the
> > > code should not be a massive issue, I hope. On the other hand, ABI
> > > compatibility is needed to allow seamless update from one version to
> > > another, and it's that ABI compatiblity that allows distro's to pick up our
> latest and greatest versions.
> > >
> > I think it is also important to setup the right expectations to DPDK users. i.e.
> DPDK will police itself better to provide ABI compatibility but occasionally it
> might not be possible.
> >
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for the
> previous version or not. Users do not want to have to go through a checklist
> for each app to see if the app uses only "compatible" APIs or not. Same for
For the releases where the ABI is broken, would not such a list help the users?
> the distro folks, they are not going to take some libs from a release but not
> others because the ABI is broken for some but not others.
Yes, this is not an option, it becomes a DPDK release of its own 😊.
>
> Regards,
> /Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-23 14:12 4% ` Ray Kinsella
@ 2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 8:49 4% ` Bruce Richardson
2 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:08 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, nd, nd
> > > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> wrote:
> > > > Hello,
> > > > There was a conversation [1] in the context of RCU library. I
> > > > thought it needs participation from broader audience. Summary for
> > > > the context (please look at [1] for full details)
> > > >
> > >
> > > Thanks for kicking off this discussion
> > >
> > > > 1) How do we provide ABI compatibility when the code base contains
> > > inline functions? Unless we freeze development in these inline
> > > functions and corresponding structures, it might not be possible to claim
> ABI compatibility.
> > > Application has to be recompiled.
> > >
> > > I agree that in some cases the application "might" need to be
> > > recompiled, but on the other hand I also think that there are many
> > > cases where ABI function versioning can still be used to mitigate
> > > things. For example, if we think of a couple of various scenarios:
> > >
> > > 1. If everything is inline and variables are allocated by app, e.g.
> > > spinlock on stack, then there is no issue as everything is
> > > application contained.
> > If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
>
Agree on the requirement.
> > >
> > > 2. If the situation is as in #1, but the structures in question are
> > > passed to non-inline DPDK functions. In this case, any changes to
> > > the structures require those functions taking the structures to be
> > > versioned for old and new structures
> > I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >
> No, there is never any need for two versions of the inline functions, only the
> newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever used.
> The other older versions are only used at runtime for compatilibity with pre-
> compiled apps with the older inlines.
>
Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
> > >
> > > 3. If instead we have the case, like in rte_ring, where the data
> > > structures are allocated using functions, but they are used via
> > > inlines in the app. In this case the creation functions (and any
> > > other function using the structures) need to be versioned so that
> > > the application gets the expected structure back from the creation.
> > The new structure members have to be added such that the previous
> > layout is not affected. Either add at the end or use the gaps that are
> > left because of cache line alignment.
> >
> Not necessarily. There is nothing that requires the older and newer versions
> of a function to use the same structure. We can rename the original structure
> when versioning the old function, and then create a new structure with the
> original name for later recompiled code using the newest ABIs.
>
Agree, assuming only the app is using the inline functions.
> > >
> > > It might be useful to think of what other scenarios we have and what
> > > ones are likely to be problematic, especially those that can't be
> > > solved by having multiple function versions.
> > >
> > > > 2) Every function that is not in the direct datapath (fastpath?)
> > > > should not be inline. Exceptions or things like rx/tx burst, ring
> > > > enqueue/dequeue, and packet alloc/free - Stephen
> > >
> > > Agree with this. Anything not data path should not be inline. The
> > > next
> > Yes, very clear on this.
> >
> > > question then is for data path items how to determine whether they
> > > need to be inline or not. In general my rule-of-thumb:
> > > * anything dealing with bursts of packets should not be inline
> > > * anything what works with single packet at a time should be inline
> > >
> > > The one exception to this rule is cases where we have to consider
> > > "empty polling" as a likely use-case. For example,
> > > rte_ring_dequeue_burst works with bursts of packets, but there is a
> > > valid application use case where a thread could be polling a set of
> > > rings where only a small number are actually busy. Right now,
> > > polling an empty ring only costs a few cycles, meaning that it's
> > > neglible to have a few polls of empty rings before you get to a busy
> > > one. Having that function not-inline will cause that cost to jump
> > > significantly, so could cause problems. (This leads to the interesting
> scenario where ring enqueue is safe to un-inline, while dequeue is not).
> > A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because even
> if it's a trivial function that takes only 10 cycles and we want to uninline it,
> the cost may double; but if it takes a burst of packets and is only used
> once/twice per burst the cost per packet should still only be a fraction of a
> cycle.
>
> > >
> > > > 3) Plus synchronization routines: spin/rwlock/barrier, etc. I
> > > > think rcu should be one of such exceptions - it is just another
> > > > synchronization mechanism after all (just a bit more
> > > > sophisticated). - Konstantin
> > > >
> > > In general I believe the synchronisation primitives should be inline.
> > > However, it does come down to cost too - if a function takes 300
> > > cycles, do we really care if it takes 305 or 310 instead to make it not
> inline?
> > > Hopefully most synchronisation primitives are faster than this so
> > > this situation should not occur.
> > >
> > > > 2) and 3) can be good guidelines to what functions/APIs can be
> > > > inline. But,
> > > I believe this guideline exists today too. Are there any thoughts to
> > > change this?
> > > >
> > > > Coming to 1), I think DPDK cannot provide ABI compatibility unless
> > > > all the
> > > inline functions are converted to normal functions and symbol
> > > versioning is done for those (not bothering about performance).
> > > >
> > > I disagree. I think even in the case of #1, we should be able to
> > > manage some changes without breaking ABI.
> > I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
>
> > >
> > > > In this context, does it make sense to say that we will maintain
> > > > API compatibility rather than saying ABI compatibility? This will
> > > > also send the right message to the end users.
> > > >
> > > I would value ABI compatibility much higher than API compatibility.
> > > If someone is recompiling the application anyway, making a couple of
> > > small changes (large rework is obviously a different issue) to the
> > > code should not be a massive issue, I hope. On the other hand, ABI
> > > compatibility is needed to allow seamless update from one version to
> > > another, and it's that ABI compatiblity that allows distro's to pick up our
> latest and greatest versions.
> > >
> > I think it is also important to setup the right expectations to DPDK users. i.e.
> DPDK will police itself better to provide ABI compatibility but occasionally it
> might not be possible.
> >
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for the
> previous version or not. Users do not want to have to go through a checklist
> for each app to see if the app uses only "compatible" APIs or not. Same for
For the releases where the ABI is broken, would not such a list help the users?
> the distro folks, they are not going to take some libs from a release but not
> others because the ABI is broken for some but not others.
Yes, this is not an option, it becomes a DPDK release of its own 😊.
>
> Regards,
> /Bruce
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
2019-04-24 8:18 20% [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh Peng Huang
@ 2019-04-24 8:18 20% ` Peng Huang
2019-04-24 8:56 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Peng Huang @ 2019-04-24 8:18 UTC (permalink / raw)
To: maintainer; +Cc: dev, peng.huang
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 20%]
* [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
@ 2019-04-24 8:18 20% Peng Huang
2019-04-24 8:18 20% ` Peng Huang
2019-04-24 8:56 4% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Peng Huang @ 2019-04-24 8:18 UTC (permalink / raw)
To: maintainer; +Cc: dev, peng.huang
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 20%]
* [dpdk-dev] DPDK Windows Community call - 18 April 2019
2019-04-23 23:16 3% [dpdk-dev] DPDK Windows Community call - 18 April 2019 Ranjit Menon
@ 2019-04-23 23:16 3% ` Ranjit Menon
0 siblings, 0 replies; 200+ results
From: Ranjit Menon @ 2019-04-23 23:16 UTC (permalink / raw)
To: dev
Attendees:
(Present)
Thomas (thomas@monjalon.net)
Harini (harini.ramakrishnan@microsoft.com)
Bruce (bruce.richardson@intel.com)
Cathal (cathal.ohare@intel.com)
Anand (anand.rawat@intel.com)
Pallavi (pallavi.kadam@intel.com)
Ranjit (ranjit.menon@intel.com)
Eilon (eilong@mellanox.com)
Raslan (rasland@mellanox.com)
(yohadt@mellanox.com)
Jeffrey (jeffrey.tippet@microsoft.com)
Omar (ocardona@microsoft.com)
Khoa (khot@microsoft.com)
New interested attendees added to meeting invite for next call:
Haseeb.Gani@cavium.com
shshaikh@marvell.com
nareshkumar.pbs@broadcom.com
Agenda:
------
Meeting for 1 hour as a place holder every 2 weeks.
Expect call to last 30-40 minutes or longer as needed.
Encourage other dpdk.org windows partners to join this call.
Minutes via public mailing list.
a. Current release
b. Improvements/Shared objectives - sync up on the bus/pci and general
status
- Mellanox agrees bus/pci port should be our next target
- Intel has latest bus/pci updates available in windows draft repo
c. Any other business
Minutes:
-------
- Removing rte_panic() calls in EAL (and other libraries)
- Some functions that call rte_panic() are defined as 'void' return.
- will need to modify these functions - which breaks ABI.
- If we're doing this it would require deprecation notice in 19.05.
- Group discussion on removal of rte panics void returns.
- Might need another definition for fatal error codes
- Why? The application layer will assess whether something is fatal
- Better to return what the error is and let the application take the
decision on whether or not it’s a fatal error.
- Advice is to use current error codes that is close enough to the error
seen.
- Use a matching a core id error – we should pass back an int-return and
allow the app to decide what action to take.
- Thomas says Arnon Warshavsky (arnon@qwilt.com) was working on removing
rte panics last year (eal: replace rte_panic instances to return an
error value).
- Check the list of what APIs need to change and get the list out now to
the community in 19.05.
- This woudl be a pre-announcement message to the mailing list – this is
sent as a patch in 19.05, explaining what will be changed in which files.
- Offline discussion with Arnon: see mailing list for detail.
- What other changes do we need to do in EAL to make upstreaming easier?
- Open source libraries to support common code (BSD licenses).
- May need a better wrapper on Linux files to use for windows.
- Some of them (eg: pthreads) not supported in windows
- so we did macro substitutions to use Windows threads.
- Wrappers could be used more widely.
- Need to work out how to do this more widely.
- Please send your ideas for a solution to the mailing list to seek
comments (RFC).
- We need to identify the blockers we’re aware of at the moment
- Perhaps, TSC is one.
- Send interesting topics for the community to work on.
- Is the bus/pci code available?
- Ask is to move the bus/pci code over to the latest branch (intel).
- Intel/Microsoft currently working to tidy up the branches & names on
windows draft repo.
- Any new code for the tree?
- Microsoft is trying to add new code to existing UIO driver
- This will be available on windows draft repo (18.08 branch)
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Windows Community call - 18 April 2019
@ 2019-04-23 23:16 3% Ranjit Menon
2019-04-23 23:16 3% ` Ranjit Menon
0 siblings, 1 reply; 200+ results
From: Ranjit Menon @ 2019-04-23 23:16 UTC (permalink / raw)
To: dev
Attendees:
(Present)
Thomas (thomas@monjalon.net)
Harini (harini.ramakrishnan@microsoft.com)
Bruce (bruce.richardson@intel.com)
Cathal (cathal.ohare@intel.com)
Anand (anand.rawat@intel.com)
Pallavi (pallavi.kadam@intel.com)
Ranjit (ranjit.menon@intel.com)
Eilon (eilong@mellanox.com)
Raslan (rasland@mellanox.com)
(yohadt@mellanox.com)
Jeffrey (jeffrey.tippet@microsoft.com)
Omar (ocardona@microsoft.com)
Khoa (khot@microsoft.com)
New interested attendees added to meeting invite for next call:
Haseeb.Gani@cavium.com
shshaikh@marvell.com
nareshkumar.pbs@broadcom.com
Agenda:
------
Meeting for 1 hour as a place holder every 2 weeks.
Expect call to last 30-40 minutes or longer as needed.
Encourage other dpdk.org windows partners to join this call.
Minutes via public mailing list.
a. Current release
b. Improvements/Shared objectives - sync up on the bus/pci and general
status
- Mellanox agrees bus/pci port should be our next target
- Intel has latest bus/pci updates available in windows draft repo
c. Any other business
Minutes:
-------
- Removing rte_panic() calls in EAL (and other libraries)
- Some functions that call rte_panic() are defined as 'void' return.
- will need to modify these functions - which breaks ABI.
- If we're doing this it would require deprecation notice in 19.05.
- Group discussion on removal of rte panics void returns.
- Might need another definition for fatal error codes
- Why? The application layer will assess whether something is fatal
- Better to return what the error is and let the application take the
decision on whether or not it’s a fatal error.
- Advice is to use current error codes that is close enough to the error
seen.
- Use a matching a core id error – we should pass back an int-return and
allow the app to decide what action to take.
- Thomas says Arnon Warshavsky (arnon@qwilt.com) was working on removing
rte panics last year (eal: replace rte_panic instances to return an
error value).
- Check the list of what APIs need to change and get the list out now to
the community in 19.05.
- This woudl be a pre-announcement message to the mailing list – this is
sent as a patch in 19.05, explaining what will be changed in which files.
- Offline discussion with Arnon: see mailing list for detail.
- What other changes do we need to do in EAL to make upstreaming easier?
- Open source libraries to support common code (BSD licenses).
- May need a better wrapper on Linux files to use for windows.
- Some of them (eg: pthreads) not supported in windows
- so we did macro substitutions to use Windows threads.
- Wrappers could be used more widely.
- Need to work out how to do this more widely.
- Please send your ideas for a solution to the mailing list to seek
comments (RFC).
- We need to identify the blockers we’re aware of at the moment
- Perhaps, TSC is one.
- Send interesting topics for the community to work on.
- Is the bus/pci code available?
- Ask is to move the bus/pci code over to the latest branch (intel).
- Intel/Microsoft currently working to tidy up the branches & names on
windows draft repo.
- Any new code for the tree?
- Microsoft is trying to add new code to existing UIO driver
- This will be available on windows draft repo (18.08 branch)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:17 0% ` Mattias Rönnblom
@ 2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 17:31, Stephen Hemminger wrote:
> On Mon, 22 Apr 2019 19:44:39 +0200
> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function already
>>>> existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>
> Ignore the error, the build tool is not smart enough for this kind of change.
>
It stops the build.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 15:31 0% ` Stephen Hemminger
@ 2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
1 sibling, 2 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 17:31, Stephen Hemminger wrote:
> On Mon, 22 Apr 2019 19:44:39 +0200
> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function already
>>>> existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>
> Ignore the error, the build tool is not smart enough for this kind of change.
>
It stops the build.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:13 0% ` Mattias Rönnblom
@ 2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-24 11:37 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:13 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-23 13:33, Neil Horman wrote:
> On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function
>>>> already existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>>
> No, we would have to waive it.
I don't understand. What do you mean?
> But its pretty clear that This function has been
> around forever, so I think it would be worse to demote it to an experimental
> symbol. The only thing you're doing here is moving it from an inline function
> (which is arguably part of the ABI, even if it never appeared as a symbol in the
> ELF file), to a fully fleged symbol with a new implementation.
>
I agree it shouldn't be marked experimental. The reason for doing so was
to avoid triggering a build error.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 11:33 3% ` Neil Horman
@ 2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-24 11:37 0% ` Neil Horman
1 sibling, 2 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:13 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-23 13:33, Neil Horman wrote:
> On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function
>>>> already existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>>
> No, we would have to waive it.
I don't understand. What do you mean?
> But its pretty clear that This function has been
> around forever, so I think it would be worse to demote it to an experimental
> symbol. The only thing you're doing here is moving it from an inline function
> (which is arguably part of the ABI, even if it never appeared as a symbol in the
> ELF file), to a fully fleged symbol with a new implementation.
>
I agree it shouldn't be marked experimental. The reason for doing so was
to avoid triggering a build error.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 15:31 0% ` Stephen Hemminger
@ 2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 17:17 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-23 15:31 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: Neil Horman, dev
On Mon, 22 Apr 2019 19:44:39 +0200
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> >>> +uint64_t __rte_experimental
> >>> +rte_rand(void)
> >> Do you really want to mark this as experimental? I know it will
> >> trigger the
> >> symbol checker with a warning if you don't, but this function already
> >> existed
> >> previously and was accepted as part of the ABI. Given that the
> >> prototype hasn't
> >> changed, I think you just need to accept it as a non-experimental
> >> function
> >>
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
Ignore the error, the build tool is not smart enough for this kind of change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-23 11:33 3% ` Neil Horman
@ 2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 17:17 0% ` Mattias Rönnblom
2 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-23 15:31 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: Neil Horman, dev
On Mon, 22 Apr 2019 19:44:39 +0200
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> >>> +uint64_t __rte_experimental
> >>> +rte_rand(void)
> >> Do you really want to mark this as experimental? I know it will
> >> trigger the
> >> symbol checker with a warning if you don't, but this function already
> >> existed
> >> previously and was accepted as part of the ABI. Given that the
> >> prototype hasn't
> >> changed, I think you just need to accept it as a non-experimental
> >> function
> >>
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
Ignore the error, the build tool is not smart enough for this kind of change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-23 14:23 4% ` Ray Kinsella
@ 2019-04-23 14:23 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:23 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote:
>
>> -----Original Message-----
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Sent: Thursday, April 18, 2019 12:21 AM
>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
>> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
>> <mdr@ashroe.eu>; nd <nd@arm.com>
>> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
>>> I would value ABI compatibility much higher than API compatibility.
>>>> If someone is recompiling the application anyway, making a couple of
>>>> small changes (large rework is obviously a different issue) to the
>>>> code should not be a massive issue, I hope. On the other hand, ABI
>>>> compatibility is needed to allow seamless update from one version to
>>>> another, and it's that ABI compatiblity that allows distro's to pick up our
>> latest and greatest versions.
>>>
>>> IMO, We have two primary use case for DPDK
>>>
>>> 1) NFV kind of use case where the application needs to run on multiple
>> platform
>>> without recompiling it.
>>> 2) Fixed appliance use case where embed SoC like Intel Denverton or
>>> ARM64 integrated Controller used. For fixed appliance use case, end
>>> user care more of performance than ABI compatibility as it easy to
>>> recompile the end user application vs the cost of hitting performance impact.
>>
>> Nobody cares about compatiablity until they have to the first security update.
>
> For fixed appliance case, The update(FW update) will be a single blob which
> Include all the components. So they can back port the security fix and recompile
> the sw as needed.
>
> The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
So is there a real versus a perceived compromise happen here - that we
are compromising optimal performance in order to make API stability
happen? Do we have specific an examples that this is actually the case?
Thanks,
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
@ 2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:23 4% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-23 14:23 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote:
>
>> -----Original Message-----
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Sent: Thursday, April 18, 2019 12:21 AM
>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
>> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
>> <mdr@ashroe.eu>; nd <nd@arm.com>
>> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
>>> I would value ABI compatibility much higher than API compatibility.
>>>> If someone is recompiling the application anyway, making a couple of
>>>> small changes (large rework is obviously a different issue) to the
>>>> code should not be a massive issue, I hope. On the other hand, ABI
>>>> compatibility is needed to allow seamless update from one version to
>>>> another, and it's that ABI compatiblity that allows distro's to pick up our
>> latest and greatest versions.
>>>
>>> IMO, We have two primary use case for DPDK
>>>
>>> 1) NFV kind of use case where the application needs to run on multiple
>> platform
>>> without recompiling it.
>>> 2) Fixed appliance use case where embed SoC like Intel Denverton or
>>> ARM64 integrated Controller used. For fixed appliance use case, end
>>> user care more of performance than ABI compatibility as it easy to
>>> recompile the end user application vs the cost of hitting performance impact.
>>
>> Nobody cares about compatiablity until they have to the first security update.
>
> For fixed appliance case, The update(FW update) will be a single blob which
> Include all the components. So they can back port the security fix and recompile
> the sw as needed.
>
> The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
So is there a real versus a perceived compromise happen here - that we
are compromising optimal performance in order to make API stability
happen? Do we have specific an examples that this is actually the case?
Thanks,
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
@ 2019-04-23 14:19 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:19 UTC (permalink / raw)
To: Stephen Hemminger, Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 17/04/2019 19:51, Stephen Hemminger wrote:
> On Wed, 17 Apr 2019 17:46:34 +0000
> Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
>
>>> -----Original Message-----
>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
>>> Sent: Wednesday, April 17, 2019 2:07 PM
>>> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
>>> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
>>> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
>>> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
>>> Subject: Re: [dpdk-dev] ABI and inline functions
>>>
>>>> 2) Every function that is not in the direct datapath (fastpath?)
>>>> should not be inline. Exceptions or things like rx/tx burst, ring
>>>> enqueue/dequeue, and packet alloc/free - Stephen
>>>
>>> Agree with this. Anything not data path should not be inline. The next question
>>> then is for data path items how to determine whether they need to be inline or
>>> not. In general my rule-of-thumb:
>>> * anything dealing with bursts of packets should not be inline
>>
>> # I think, we need consider the how fat is the function too,
>> If it is light weight, probably we need to make it inline
Well if it light weight however it is not dealing directly with packets,
probably does not matter if is not-inline?
>> # Except the forward case, In real world use case, it is not trivial make large
>> burst of packet to process it even though function prototype burst.
>> We may need to consider that
>> # For the given function if some argument is used with inline other function,
>> probably no point in making that function alone inline as the structure
>> is exposed in some other function.
>>
>>> * anything what works with single packet at a time should be inline
>>>
>>>> In this context, does it make sense to say that we will maintain API
>>>> compatibility rather than saying ABI compatibility? This will also
>>>> send the right message to the end users.
>>>>
>>> I would value ABI compatibility much higher than API compatibility. If someone
>>> is recompiling the application anyway, making a couple of small changes (large
>>> rework is obviously a different issue) to the code should not be a massive issue, I
>>> hope. On the other hand, ABI compatibility is needed to allow seamless update
>>> from one version to another, and it's that ABI compatiblity that allows distro's to
>>> pick up our latest and greatest versions.
>>
>> IMO, We have two primary use case for DPDK
>>
>> 1) NFV kind of use case where the application needs to run on multiple platform
>> without recompiling it.
>> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
>> Controller used. For fixed appliance use case, end user care more of performance
>> than ABI compatibility as it easy to recompile the end user application vs the cost of
>> hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
>
+1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-04-23 14:19 4% ` Ray Kinsella
2019-04-23 14:19 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-23 14:19 UTC (permalink / raw)
To: Stephen Hemminger, Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 17/04/2019 19:51, Stephen Hemminger wrote:
> On Wed, 17 Apr 2019 17:46:34 +0000
> Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
>
>>> -----Original Message-----
>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
>>> Sent: Wednesday, April 17, 2019 2:07 PM
>>> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
>>> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
>>> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
>>> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
>>> Subject: Re: [dpdk-dev] ABI and inline functions
>>>
>>>> 2) Every function that is not in the direct datapath (fastpath?)
>>>> should not be inline. Exceptions or things like rx/tx burst, ring
>>>> enqueue/dequeue, and packet alloc/free - Stephen
>>>
>>> Agree with this. Anything not data path should not be inline. The next question
>>> then is for data path items how to determine whether they need to be inline or
>>> not. In general my rule-of-thumb:
>>> * anything dealing with bursts of packets should not be inline
>>
>> # I think, we need consider the how fat is the function too,
>> If it is light weight, probably we need to make it inline
Well if it light weight however it is not dealing directly with packets,
probably does not matter if is not-inline?
>> # Except the forward case, In real world use case, it is not trivial make large
>> burst of packet to process it even though function prototype burst.
>> We may need to consider that
>> # For the given function if some argument is used with inline other function,
>> probably no point in making that function alone inline as the structure
>> is exposed in some other function.
>>
>>> * anything what works with single packet at a time should be inline
>>>
>>>> In this context, does it make sense to say that we will maintain API
>>>> compatibility rather than saying ABI compatibility? This will also
>>>> send the right message to the end users.
>>>>
>>> I would value ABI compatibility much higher than API compatibility. If someone
>>> is recompiling the application anyway, making a couple of small changes (large
>>> rework is obviously a different issue) to the code should not be a massive issue, I
>>> hope. On the other hand, ABI compatibility is needed to allow seamless update
>>> from one version to another, and it's that ABI compatiblity that allows distro's to
>>> pick up our latest and greatest versions.
>>
>> IMO, We have two primary use case for DPDK
>>
>> 1) NFV kind of use case where the application needs to run on multiple platform
>> without recompiling it.
>> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
>> Controller used. For fixed appliance use case, end user care more of performance
>> than ABI compatibility as it easy to recompile the end user application vs the cost of
>> hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
>
+1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:12 4% ` Ray Kinsella
@ 2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 11:08 8% ` Burakov, Anatoly
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:12 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 18/04/2019 11:28, Bruce Richardson wrote:
> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>
>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>> Hello,
>>>> There was a conversation [1] in the context of RCU library. I thought
>>>> it needs participation from broader audience. Summary for the context
>>>> (please look at [1] for full details)
>>>>
>>>
>>> Thanks for kicking off this discussion
>>>
>>>> 1) How do we provide ABI compatibility when the code base contains
>>> inline functions? Unless we freeze development in these inline functions and
>>> corresponding structures, it might not be possible to claim ABI compatibility.
>>> Application has to be recompiled.
>>>
>>> I agree that in some cases the application "might" need to be recompiled,
>>> but on the other hand I also think that there are many cases where ABI
>>> function versioning can still be used to mitigate things. For example, if we
>>> think of a couple of various scenarios:
>>>
>>> 1. If everything is inline and variables are allocated by app, e.g.
>>> spinlock on stack, then there is no issue as everything is application
>>> contained.
>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
I would also imagine that should be an extremely rare case, that a
bugfix would require a structure change ... perhaps for an alignment issues?
>
>>>
>>> 2. If the situation is as in #1, but the structures in question are passed to
>>> non-inline DPDK functions. In this case, any changes to the structures require
>>> those functions taking the structures to be versioned for old and new
>>> structures
>> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>>
> No, there is never any need for two versions of the inline functions, only
> the newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever
> used. The other older versions are only used at runtime for compatilibity
> with pre-compiled apps with the older inlines.
>
>>>
>>> 3. If instead we have the case, like in rte_ring, where the data
>>> structures are allocated using functions, but they are used via inlines
>>> in the app. In this case the creation functions (and any other function
>>> using the structures) need to be versioned so that the application gets
>>> the expected structure back from the creation.
>> The new structure members have to be added such that the previous layout
>> is not affected. Either add at the end or use the gaps that are left
>> because of cache line alignment.
>>
> Not necessarily. There is nothing that requires the older and newer
> versions of a function to use the same structure. We can rename the
> original structure when versioning the old function, and then create a new
> structure with the original name for later recompiled code using the newest
> ABIs.
>
>>>
>>> It might be useful to think of what other scenarios we have and what ones
>>> are likely to be problematic, especially those that can't be solved by having
>>> multiple function versions.
>>>
>>>> 2) Every function that is not in the direct datapath (fastpath?)
>>>> should not be inline. Exceptions or things like rx/tx burst, ring
>>>> enqueue/dequeue, and packet alloc/free - Stephen
>>>
>>> Agree with this. Anything not data path should not be inline. The next
>> Yes, very clear on this.
>>
>>> question then is for data path items how to determine whether they need to
>>> be inline or not. In general my rule-of-thumb:
>>> * anything dealing with bursts of packets should not be inline
>>> * anything what works with single packet at a time should be inline
>>>
>>> The one exception to this rule is cases where we have to consider "empty
>>> polling" as a likely use-case. For example, rte_ring_dequeue_burst works
>>> with bursts of packets, but there is a valid application use case where a
>>> thread could be polling a set of rings where only a small number are
>>> actually busy. Right now, polling an empty ring only costs a few cycles,
>>> meaning that it's neglible to have a few polls of empty rings before you get
>>> to a busy one. Having that function not-inline will cause that cost to jump
>>> significantly, so could cause problems. (This leads to the interesting scenario
>>> where ring enqueue is safe to un-inline, while dequeue is not).
>> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>>
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because
> even if it's a trivial function that takes only 10 cycles and we want to
> uninline it, the cost may double; but if it takes a burst of packets and is
> only used once/twice per burst the cost per packet should still only be a
> fraction of a cycle.
>
>>>
>>>> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
>>>> rcu should be one of such exceptions - it is just another
>>>> synchronization mechanism after all (just a bit more sophisticated). -
>>>> Konstantin
>>>>
>>> In general I believe the synchronisation primitives should be inline.
>>> However, it does come down to cost too - if a function takes 300 cycles, do
>>> we really care if it takes 305 or 310 instead to make it not inline?
>>> Hopefully most synchronisation primitives are faster than this so this
>>> situation should not occur.
>>>
>>>> 2) and 3) can be good guidelines to what functions/APIs can be inline. But,
>>> I believe this guideline exists today too. Are there any thoughts to change
>>> this?
>>>>
>>>> Coming to 1), I think DPDK cannot provide ABI compatibility unless all the
>>> inline functions are converted to normal functions and symbol versioning is
>>> done for those (not bothering about performance).
>>>>
>>> I disagree. I think even in the case of #1, we should be able to manage some
>>> changes without breaking ABI.
>> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>>
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
I completely disagree with this approach.
Anytime I have seen this done, most frequently with interpreted
languages, think multiple versions of Java and Python concurrently on a
system, it has always been a usability nightmare.
>
>>>
>>>> In this context, does it make sense to say that we will maintain API
>>>> compatibility rather than saying ABI compatibility? This will also
>>>> send the right message to the end users.
>>>>
>>> I would value ABI compatibility much higher than API compatibility. If
>>> someone is recompiling the application anyway, making a couple of small
>>> changes (large rework is obviously a different issue) to the code should not
>>> be a massive issue, I hope. On the other hand, ABI compatibility is needed to
>>> allow seamless update from one version to another, and it's that ABI
>>> compatiblity that allows distro's to pick up our latest and greatest versions.
>>>
>> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>>
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for
> the previous version or not. Users do not want to have to go through a
> checklist for each app to see if the app uses only "compatible" APIs or
> not. Same for the distro folks, they are not going to take some libs from a
> release but not others because the ABI is broken for some but not others.
Agreed, a DPDK release is either backwards compatible or it isn't, and
to Bruce's point if it isn't, it maters less if this is for a big API
change or a small API change - the failure of the API stability
guarantee is the significant piece.
The reality is that most other system libraries provide strong
guarantees ... to date we have provided very little.
If we start saying "Yes, but except when", the exception case very
quickly becomes the general case and then we are back to the beginning
again.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
@ 2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
` (2 more replies)
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2 siblings, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:12 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 18/04/2019 11:28, Bruce Richardson wrote:
> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>
>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>> Hello,
>>>> There was a conversation [1] in the context of RCU library. I thought
>>>> it needs participation from broader audience. Summary for the context
>>>> (please look at [1] for full details)
>>>>
>>>
>>> Thanks for kicking off this discussion
>>>
>>>> 1) How do we provide ABI compatibility when the code base contains
>>> inline functions? Unless we freeze development in these inline functions and
>>> corresponding structures, it might not be possible to claim ABI compatibility.
>>> Application has to be recompiled.
>>>
>>> I agree that in some cases the application "might" need to be recompiled,
>>> but on the other hand I also think that there are many cases where ABI
>>> function versioning can still be used to mitigate things. For example, if we
>>> think of a couple of various scenarios:
>>>
>>> 1. If everything is inline and variables are allocated by app, e.g.
>>> spinlock on stack, then there is no issue as everything is application
>>> contained.
>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
I would also imagine that should be an extremely rare case, that a
bugfix would require a structure change ... perhaps for an alignment issues?
>
>>>
>>> 2. If the situation is as in #1, but the structures in question are passed to
>>> non-inline DPDK functions. In this case, any changes to the structures require
>>> those functions taking the structures to be versioned for old and new
>>> structures
>> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>>
> No, there is never any need for two versions of the inline functions, only
> the newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever
> used. The other older versions are only used at runtime for compatilibity
> with pre-compiled apps with the older inlines.
>
>>>
>>> 3. If instead we have the case, like in rte_ring, where the data
>>> structures are allocated using functions, but they are used via inlines
>>> in the app. In this case the creation functions (and any other function
>>> using the structures) need to be versioned so that the application gets
>>> the expected structure back from the creation.
>> The new structure members have to be added such that the previous layout
>> is not affected. Either add at the end or use the gaps that are left
>> because of cache line alignment.
>>
> Not necessarily. There is nothing that requires the older and newer
> versions of a function to use the same structure. We can rename the
> original structure when versioning the old function, and then create a new
> structure with the original name for later recompiled code using the newest
> ABIs.
>
>>>
>>> It might be useful to think of what other scenarios we have and what ones
>>> are likely to be problematic, especially those that can't be solved by having
>>> multiple function versions.
>>>
>>>> 2) Every function that is not in the direct datapath (fastpath?)
>>>> should not be inline. Exceptions or things like rx/tx burst, ring
>>>> enqueue/dequeue, and packet alloc/free - Stephen
>>>
>>> Agree with this. Anything not data path should not be inline. The next
>> Yes, very clear on this.
>>
>>> question then is for data path items how to determine whether they need to
>>> be inline or not. In general my rule-of-thumb:
>>> * anything dealing with bursts of packets should not be inline
>>> * anything what works with single packet at a time should be inline
>>>
>>> The one exception to this rule is cases where we have to consider "empty
>>> polling" as a likely use-case. For example, rte_ring_dequeue_burst works
>>> with bursts of packets, but there is a valid application use case where a
>>> thread could be polling a set of rings where only a small number are
>>> actually busy. Right now, polling an empty ring only costs a few cycles,
>>> meaning that it's neglible to have a few polls of empty rings before you get
>>> to a busy one. Having that function not-inline will cause that cost to jump
>>> significantly, so could cause problems. (This leads to the interesting scenario
>>> where ring enqueue is safe to un-inline, while dequeue is not).
>> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>>
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because
> even if it's a trivial function that takes only 10 cycles and we want to
> uninline it, the cost may double; but if it takes a burst of packets and is
> only used once/twice per burst the cost per packet should still only be a
> fraction of a cycle.
>
>>>
>>>> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
>>>> rcu should be one of such exceptions - it is just another
>>>> synchronization mechanism after all (just a bit more sophisticated). -
>>>> Konstantin
>>>>
>>> In general I believe the synchronisation primitives should be inline.
>>> However, it does come down to cost too - if a function takes 300 cycles, do
>>> we really care if it takes 305 or 310 instead to make it not inline?
>>> Hopefully most synchronisation primitives are faster than this so this
>>> situation should not occur.
>>>
>>>> 2) and 3) can be good guidelines to what functions/APIs can be inline. But,
>>> I believe this guideline exists today too. Are there any thoughts to change
>>> this?
>>>>
>>>> Coming to 1), I think DPDK cannot provide ABI compatibility unless all the
>>> inline functions are converted to normal functions and symbol versioning is
>>> done for those (not bothering about performance).
>>>>
>>> I disagree. I think even in the case of #1, we should be able to manage some
>>> changes without breaking ABI.
>> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>>
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
I completely disagree with this approach.
Anytime I have seen this done, most frequently with interpreted
languages, think multiple versions of Java and Python concurrently on a
system, it has always been a usability nightmare.
>
>>>
>>>> In this context, does it make sense to say that we will maintain API
>>>> compatibility rather than saying ABI compatibility? This will also
>>>> send the right message to the end users.
>>>>
>>> I would value ABI compatibility much higher than API compatibility. If
>>> someone is recompiling the application anyway, making a couple of small
>>> changes (large rework is obviously a different issue) to the code should not
>>> be a massive issue, I hope. On the other hand, ABI compatibility is needed to
>>> allow seamless update from one version to another, and it's that ABI
>>> compatiblity that allows distro's to pick up our latest and greatest versions.
>>>
>> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>>
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for
> the previous version or not. Users do not want to have to go through a
> checklist for each app to see if the app uses only "compatible" APIs or
> not. Same for the distro folks, they are not going to take some libs from a
> release but not others because the ABI is broken for some but not others.
Agreed, a DPDK release is either backwards compatible or it isn't, and
to Bruce's point if it isn't, it maters less if this is for a big API
change or a small API change - the failure of the API stability
guarantee is the significant piece.
The reality is that most other system libraries provide strong
guarantees ... to date we have provided very little.
If we start saying "Yes, but except when", the exception case very
quickly becomes the general case and then we are back to the beginning
again.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 11:33 3% ` Neil Horman
@ 2019-04-23 11:33 3% ` Neil Horman
2019-04-23 17:13 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-23 11:33 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1351 bytes --]
On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> > > > +uint64_t __rte_experimental
> > > > +rte_rand(void)
> > > Do you really want to mark this as experimental? I know it will
> > > trigger the
> > > symbol checker with a warning if you don't, but this function
> > > already existed
> > > previously and was accepted as part of the ABI. Given that the
> > > prototype hasn't
> > > changed, I think you just need to accept it as a non-experimental
> > > function
> > >
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
>
No, we would have to waive it. But its pretty clear that This function has been
around forever, so I think it would be worse to demote it to an experimental
symbol. The only thing you're doing here is moving it from an inline function
(which is arguably part of the ABI, even if it never appeared as a symbol in the
ELF file), to a fully fleged symbol with a new implementation.
Neil
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
@ 2019-04-23 11:33 3% ` Neil Horman
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 15:31 0% ` Stephen Hemminger
2 siblings, 2 replies; 200+ results
From: Neil Horman @ 2019-04-23 11:33 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> > > > +uint64_t __rte_experimental
> > > > +rte_rand(void)
> > > Do you really want to mark this as experimental? I know it will
> > > trigger the
> > > symbol checker with a warning if you don't, but this function
> > > already existed
> > > previously and was accepted as part of the ABI. Given that the
> > > prototype hasn't
> > > changed, I think you just need to accept it as a non-experimental
> > > function
> > >
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
>
No, we would have to waive it. But its pretty clear that This function has been
around forever, so I think it would be worse to demote it to an experimental
symbol. The only thing you're doing here is moving it from an inline function
(which is arguably part of the ABI, even if it never appeared as a symbol in the
ELF file), to a fully fleged symbol with a new implementation.
Neil
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 17:44 0% ` Mattias Rönnblom
@ 2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 15:31 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 17:44 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 17:52, Mattias Rönnblom wrote:
> On 2019-04-22 13:34, Neil Horman wrote:
>
>>> +uint64_t __rte_experimental
>>> +rte_rand(void)
>> Do you really want to mark this as experimental? I know it will
>> trigger the
>> symbol checker with a warning if you don't, but this function already
>> existed
>> previously and was accepted as part of the ABI. Given that the
>> prototype hasn't
>> changed, I think you just need to accept it as a non-experimental
>> function
>>
>
> I'll remove the experimental tag and move it into the 19_05 section
> (without suggesting it should go into 19.05). That maneuver seems not to
> trigger any build warnings/errors.
>
OK, so that wasn't true. It does trigger a build error, courtesy of
buildtools/check-experimental-syms.sh.
I can't see any obvious way around it. Ideas, anyone?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 15:52 3% ` Mattias Rönnblom
@ 2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 17:44 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 17:52, Mattias Rönnblom wrote:
> On 2019-04-22 13:34, Neil Horman wrote:
>
>>> +uint64_t __rte_experimental
>>> +rte_rand(void)
>> Do you really want to mark this as experimental? I know it will
>> trigger the
>> symbol checker with a warning if you don't, but this function already
>> existed
>> previously and was accepted as part of the ABI. Given that the
>> prototype hasn't
>> changed, I think you just need to accept it as a non-experimental
>> function
>>
>
> I'll remove the experimental tag and move it into the 19_05 section
> (without suggesting it should go into 19.05). That maneuver seems not to
> trigger any build warnings/errors.
>
OK, so that wasn't true. It does trigger a build error, courtesy of
buildtools/check-experimental-syms.sh.
I can't see any obvious way around it. Ideas, anyone?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 15:52 3% ` Mattias Rönnblom
@ 2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 15:52 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 13:34, Neil Horman wrote:
>> +uint64_t __rte_experimental
>> +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
>
I'll remove the experimental tag and move it into the 19_05 section
(without suggesting it should go into 19.05). That maneuver seems not to
trigger any build warnings/errors.
It's been a part of the API since forever, but it was never a part of
the ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 14:49 0% ` Stephen Hemminger
@ 2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2 siblings, 2 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 15:52 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 13:34, Neil Horman wrote:
>> +uint64_t __rte_experimental
>> +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
>
I'll remove the experimental tag and move it into the 19_05 section
(without suggesting it should go into 19.05). That maneuver seems not to
trigger any build warnings/errors.
It's been a part of the API since forever, but it was never a part of
the ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 14:49 0% ` Stephen Hemminger
@ 2019-04-22 14:49 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-22 14:49 UTC (permalink / raw)
To: Neil Horman; +Cc: Mattias Rönnblom, dev
On Mon, 22 Apr 2019 07:34:20 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> > +
> > +uint64_t __rte_experimental
> > +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
Agree with Neil. Don't mark existing functions as experimental.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
@ 2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 15:52 3% ` Mattias Rönnblom
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-22 14:49 UTC (permalink / raw)
To: Neil Horman; +Cc: Mattias Rönnblom, dev
On Mon, 22 Apr 2019 07:34:20 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> > +
> > +uint64_t __rte_experimental
> > +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
Agree with Neil. Don't mark existing functions as experimental.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 11:34 3% ` Neil Horman
@ 2019-04-22 11:34 3% ` Neil Horman
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 15:52 3% ` Mattias Rönnblom
2 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-04-22 11:34 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Fri, Apr 19, 2019 at 11:21:37PM +0200, Mattias Rönnblom wrote:
> This commit replaces rte_rand()'s use of lrand48() with a DPDK-native
> combined Linear Feedback Shift Register (LFSR) (also known as
> Tausworthe) pseudo-number generator, with five sequences.
>
> This generator is faster and produces better quality random numbers
> than libc's lrand48() implementation. This implementation, as opposed
> to lrand48(), is multi-thread safe in regards to concurrent rte_rand()
> calls from different lcore threads. It is not cryptographically
> secure - just like lrand48().
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> ---
> lib/librte_eal/common/include/rte_random.h | 29 ++---
> lib/librte_eal/common/meson.build | 1 +
> lib/librte_eal/common/rte_random.c | 137 +++++++++++++++++++++
> lib/librte_eal/freebsd/eal/Makefile | 1 +
> lib/librte_eal/freebsd/eal/eal.c | 2 -
> lib/librte_eal/linux/eal/Makefile | 1 +
> lib/librte_eal/linux/eal/eal.c | 2 -
> lib/librte_eal/rte_eal_version.map | 2 +
> 8 files changed, 153 insertions(+), 22 deletions(-)
> create mode 100644 lib/librte_eal/common/rte_random.c
>
> diff --git a/lib/librte_eal/common/include/rte_random.h b/lib/librte_eal/common/include/rte_random.h
> index b2ca1c209..66dfe8ae7 100644
> --- a/lib/librte_eal/common/include/rte_random.h
> +++ b/lib/librte_eal/common/include/rte_random.h
> @@ -16,7 +16,6 @@ extern "C" {
> #endif
>
> #include <stdint.h>
> -#include <stdlib.h>
>
> /**
> * Seed the pseudo-random generator.
> @@ -25,34 +24,28 @@ extern "C" {
> * value. It may need to be re-seeded by the user with a real random
> * value.
> *
> + * This function is not multi-thread safe in regards to other
> + * rte_srand() calls, nor is it in relation to concurrent rte_rand()
> + * calls.
> + *
> * @param seedval
> * The value of the seed.
> */
> -static inline void
> -rte_srand(uint64_t seedval)
> -{
> - srand48((long)seedval);
> -}
> +void
> +rte_srand(uint64_t seedval);
>
> /**
> * Get a pseudo-random value.
> *
> - * This function generates pseudo-random numbers using the linear
> - * congruential algorithm and 48-bit integer arithmetic, called twice
> - * to generate a 64-bit value.
> + * The generator is not cryptographically secure.
> + *
> + * If called from lcore threads, this function is thread-safe.
> *
> * @return
> * A pseudo-random value between 0 and (1<<64)-1.
> */
> -static inline uint64_t
> -rte_rand(void)
> -{
> - uint64_t val;
> - val = (uint64_t)lrand48();
> - val <<= 32;
> - val += (uint64_t)lrand48();
> - return val;
> -}
> +uint64_t
> +rte_rand(void);
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
> index 0670e4102..bafd23207 100644
> --- a/lib/librte_eal/common/meson.build
> +++ b/lib/librte_eal/common/meson.build
> @@ -35,6 +35,7 @@ common_sources = files(
> 'rte_keepalive.c',
> 'rte_malloc.c',
> 'rte_option.c',
> + 'rte_random.c',
> 'rte_reciprocal.c',
> 'rte_service.c'
> )
> diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
> new file mode 100644
> index 000000000..288e7b8c5
> --- /dev/null
> +++ b/lib/librte_eal/common/rte_random.c
> @@ -0,0 +1,137 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2019 Ericsson AB
> + */
> +
> +#include <stdlib.h>
> +
> +#include <rte_cycles.h>
> +#include <rte_eal.h>
> +#include <rte_lcore.h>
> +#include <rte_random.h>
> +
> +struct rte_rand_state {
> + uint64_t z1;
> + uint64_t z2;
> + uint64_t z3;
> + uint64_t z4;
> + uint64_t z5;
> +} __rte_cache_aligned;
> +
> +static struct rte_rand_state rand_states[RTE_MAX_LCORE];
> +
> +static uint32_t
> +__rte_rand_lcg32(uint32_t *seed)
> +{
> + *seed = 1103515245U * *seed + 12345U;
> +
> + return *seed;
> +}
> +
> +static uint64_t
> +__rte_rand_lcg64(uint32_t *seed)
> +{
> + uint64_t low;
> + uint64_t high;
> +
> + /* A 64-bit LCG would have been much cleaner, but well-known
> + * good multiplier/increments seem hard to come by.
> + */
> +
> + low = __rte_rand_lcg32(seed);
> + high = __rte_rand_lcg32(seed);
> +
> + return low | (high << 32);
> +}
> +
> +static uint64_t
> +__rte_rand_lfsr258_gen_seed(uint32_t *seed, uint64_t min_value)
> +{
> + uint64_t res;
> +
> + res = __rte_rand_lcg64(seed);
> +
> + if (res < min_value)
> + res += min_value;
> +
> + return res;
> +}
> +
> +static void
> +__rte_srand_lfsr258(uint64_t seed, struct rte_rand_state *state)
> +{
> + uint32_t lcg_seed;
> +
> + lcg_seed = (uint32_t)(seed ^ (seed >> 32));
> +
> + state->z1 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 2UL);
> + state->z2 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 512UL);
> + state->z3 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 4096UL);
> + state->z4 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 131072UL);
> + state->z5 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 8388608UL);
> +}
> +
> +void __rte_experimental
> +rte_srand(uint64_t seed)
> +{
> + unsigned int lcore_id;
> +
> + /* add lcore_id to seed to avoid having the same sequence */
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
> + __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
> +}
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258_comp(uint64_t z, uint64_t a, uint64_t b, uint64_t c,
> + uint64_t d)
> +{
> + return ((z & c) << d) ^ (((z << a) ^ z) >> b);
> +}
> +
> +/* Based on L’Ecuyer, P.: Tables of maximally equidistributed combined
> + * LFSR generators.
> + */
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258(struct rte_rand_state *state)
> +{
> + state->z1 = __rte_rand_lfsr258_comp(state->z1, 1UL, 53UL,
> + 18446744073709551614UL, 10UL);
> + state->z2 = __rte_rand_lfsr258_comp(state->z2, 24UL, 50UL,
> + 18446744073709551104UL, 5UL);
> + state->z3 = __rte_rand_lfsr258_comp(state->z3, 3UL, 23UL,
> + 18446744073709547520UL, 29UL);
> + state->z4 = __rte_rand_lfsr258_comp(state->z4, 5UL, 24UL,
> + 18446744073709420544UL, 23UL);
> + state->z5 = __rte_rand_lfsr258_comp(state->z5, 3UL, 33UL,
> + 18446744073701163008UL, 8UL);
> +
> + return state->z1 ^ state->z2 ^ state->z3 ^ state->z4 ^ state->z5;
> +}
> +
> +static __rte_always_inline
> +struct rte_rand_state *__rte_rand_get_state(void)
> +{
> + unsigned int lcore_id;
> +
> + lcore_id = rte_lcore_id();
> +
> + if (unlikely(lcore_id == LCORE_ID_ANY))
> + lcore_id = rte_get_master_lcore();
> +
> + return &rand_states[lcore_id];
> +}
> +
> +uint64_t __rte_experimental
> +rte_rand(void)
Do you really want to mark this as experimental? I know it will trigger the
symbol checker with a warning if you don't, but this function already existed
previously and was accepted as part of the ABI. Given that the prototype hasn't
changed, I think you just need to accept it as a non-experimental function
> +{
> + struct rte_rand_state *state;
> +
> + state = __rte_rand_get_state();
> +
> + return __rte_rand_lfsr258(state);
> +}
> +
> +RTE_INIT(rte_rand_init)
> +{
> + rte_srand(rte_get_timer_cycles());
> +}
> diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
> index 19854ee2c..ca616c480 100644
> --- a/lib/librte_eal/freebsd/eal/Makefile
> +++ b/lib/librte_eal/freebsd/eal/Makefile
> @@ -69,6 +69,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/freebsd/eal/eal.c b/lib/librte_eal/freebsd/eal/eal.c
> index c6ac9028f..5d43310b3 100644
> --- a/lib/librte_eal/freebsd/eal/eal.c
> +++ b/lib/librte_eal/freebsd/eal/eal.c
> @@ -727,8 +727,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> /* in secondary processes, memory init may allocate additional fbarrays
> * not present in primary processes, so to avoid any potential issues,
> * initialize memzones first.
> diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
> index 6e5261152..729795a10 100644
> --- a/lib/librte_eal/linux/eal/Makefile
> +++ b/lib/librte_eal/linux/eal/Makefile
> @@ -77,6 +77,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
> index f7ae62d7b..c2bdf0a67 100644
> --- a/lib/librte_eal/linux/eal/eal.c
> +++ b/lib/librte_eal/linux/eal/eal.c
> @@ -1083,8 +1083,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0) {
> rte_eal_init_alert("Cannot init logging.");
> rte_errno = ENOMEM;
> diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
> index d6e375135..0d60668fa 100644
> --- a/lib/librte_eal/rte_eal_version.map
> +++ b/lib/librte_eal/rte_eal_version.map
> @@ -366,10 +366,12 @@ EXPERIMENTAL {
> rte_mp_request_async;
> rte_mp_sendmsg;
> rte_option_register;
> + rte_rand;
> rte_realloc_socket;
> rte_service_lcore_attr_get;
> rte_service_lcore_attr_reset_all;
> rte_service_may_be_active;
> rte_socket_count;
> rte_socket_id_by_idx;
> + rte_srand;
> };
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
@ 2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Neil Horman @ 2019-04-22 11:34 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Fri, Apr 19, 2019 at 11:21:37PM +0200, Mattias Rönnblom wrote:
> This commit replaces rte_rand()'s use of lrand48() with a DPDK-native
> combined Linear Feedback Shift Register (LFSR) (also known as
> Tausworthe) pseudo-number generator, with five sequences.
>
> This generator is faster and produces better quality random numbers
> than libc's lrand48() implementation. This implementation, as opposed
> to lrand48(), is multi-thread safe in regards to concurrent rte_rand()
> calls from different lcore threads. It is not cryptographically
> secure - just like lrand48().
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> ---
> lib/librte_eal/common/include/rte_random.h | 29 ++---
> lib/librte_eal/common/meson.build | 1 +
> lib/librte_eal/common/rte_random.c | 137 +++++++++++++++++++++
> lib/librte_eal/freebsd/eal/Makefile | 1 +
> lib/librte_eal/freebsd/eal/eal.c | 2 -
> lib/librte_eal/linux/eal/Makefile | 1 +
> lib/librte_eal/linux/eal/eal.c | 2 -
> lib/librte_eal/rte_eal_version.map | 2 +
> 8 files changed, 153 insertions(+), 22 deletions(-)
> create mode 100644 lib/librte_eal/common/rte_random.c
>
> diff --git a/lib/librte_eal/common/include/rte_random.h b/lib/librte_eal/common/include/rte_random.h
> index b2ca1c209..66dfe8ae7 100644
> --- a/lib/librte_eal/common/include/rte_random.h
> +++ b/lib/librte_eal/common/include/rte_random.h
> @@ -16,7 +16,6 @@ extern "C" {
> #endif
>
> #include <stdint.h>
> -#include <stdlib.h>
>
> /**
> * Seed the pseudo-random generator.
> @@ -25,34 +24,28 @@ extern "C" {
> * value. It may need to be re-seeded by the user with a real random
> * value.
> *
> + * This function is not multi-thread safe in regards to other
> + * rte_srand() calls, nor is it in relation to concurrent rte_rand()
> + * calls.
> + *
> * @param seedval
> * The value of the seed.
> */
> -static inline void
> -rte_srand(uint64_t seedval)
> -{
> - srand48((long)seedval);
> -}
> +void
> +rte_srand(uint64_t seedval);
>
> /**
> * Get a pseudo-random value.
> *
> - * This function generates pseudo-random numbers using the linear
> - * congruential algorithm and 48-bit integer arithmetic, called twice
> - * to generate a 64-bit value.
> + * The generator is not cryptographically secure.
> + *
> + * If called from lcore threads, this function is thread-safe.
> *
> * @return
> * A pseudo-random value between 0 and (1<<64)-1.
> */
> -static inline uint64_t
> -rte_rand(void)
> -{
> - uint64_t val;
> - val = (uint64_t)lrand48();
> - val <<= 32;
> - val += (uint64_t)lrand48();
> - return val;
> -}
> +uint64_t
> +rte_rand(void);
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
> index 0670e4102..bafd23207 100644
> --- a/lib/librte_eal/common/meson.build
> +++ b/lib/librte_eal/common/meson.build
> @@ -35,6 +35,7 @@ common_sources = files(
> 'rte_keepalive.c',
> 'rte_malloc.c',
> 'rte_option.c',
> + 'rte_random.c',
> 'rte_reciprocal.c',
> 'rte_service.c'
> )
> diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
> new file mode 100644
> index 000000000..288e7b8c5
> --- /dev/null
> +++ b/lib/librte_eal/common/rte_random.c
> @@ -0,0 +1,137 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2019 Ericsson AB
> + */
> +
> +#include <stdlib.h>
> +
> +#include <rte_cycles.h>
> +#include <rte_eal.h>
> +#include <rte_lcore.h>
> +#include <rte_random.h>
> +
> +struct rte_rand_state {
> + uint64_t z1;
> + uint64_t z2;
> + uint64_t z3;
> + uint64_t z4;
> + uint64_t z5;
> +} __rte_cache_aligned;
> +
> +static struct rte_rand_state rand_states[RTE_MAX_LCORE];
> +
> +static uint32_t
> +__rte_rand_lcg32(uint32_t *seed)
> +{
> + *seed = 1103515245U * *seed + 12345U;
> +
> + return *seed;
> +}
> +
> +static uint64_t
> +__rte_rand_lcg64(uint32_t *seed)
> +{
> + uint64_t low;
> + uint64_t high;
> +
> + /* A 64-bit LCG would have been much cleaner, but well-known
> + * good multiplier/increments seem hard to come by.
> + */
> +
> + low = __rte_rand_lcg32(seed);
> + high = __rte_rand_lcg32(seed);
> +
> + return low | (high << 32);
> +}
> +
> +static uint64_t
> +__rte_rand_lfsr258_gen_seed(uint32_t *seed, uint64_t min_value)
> +{
> + uint64_t res;
> +
> + res = __rte_rand_lcg64(seed);
> +
> + if (res < min_value)
> + res += min_value;
> +
> + return res;
> +}
> +
> +static void
> +__rte_srand_lfsr258(uint64_t seed, struct rte_rand_state *state)
> +{
> + uint32_t lcg_seed;
> +
> + lcg_seed = (uint32_t)(seed ^ (seed >> 32));
> +
> + state->z1 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 2UL);
> + state->z2 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 512UL);
> + state->z3 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 4096UL);
> + state->z4 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 131072UL);
> + state->z5 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 8388608UL);
> +}
> +
> +void __rte_experimental
> +rte_srand(uint64_t seed)
> +{
> + unsigned int lcore_id;
> +
> + /* add lcore_id to seed to avoid having the same sequence */
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
> + __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
> +}
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258_comp(uint64_t z, uint64_t a, uint64_t b, uint64_t c,
> + uint64_t d)
> +{
> + return ((z & c) << d) ^ (((z << a) ^ z) >> b);
> +}
> +
> +/* Based on L’Ecuyer, P.: Tables of maximally equidistributed combined
> + * LFSR generators.
> + */
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258(struct rte_rand_state *state)
> +{
> + state->z1 = __rte_rand_lfsr258_comp(state->z1, 1UL, 53UL,
> + 18446744073709551614UL, 10UL);
> + state->z2 = __rte_rand_lfsr258_comp(state->z2, 24UL, 50UL,
> + 18446744073709551104UL, 5UL);
> + state->z3 = __rte_rand_lfsr258_comp(state->z3, 3UL, 23UL,
> + 18446744073709547520UL, 29UL);
> + state->z4 = __rte_rand_lfsr258_comp(state->z4, 5UL, 24UL,
> + 18446744073709420544UL, 23UL);
> + state->z5 = __rte_rand_lfsr258_comp(state->z5, 3UL, 33UL,
> + 18446744073701163008UL, 8UL);
> +
> + return state->z1 ^ state->z2 ^ state->z3 ^ state->z4 ^ state->z5;
> +}
> +
> +static __rte_always_inline
> +struct rte_rand_state *__rte_rand_get_state(void)
> +{
> + unsigned int lcore_id;
> +
> + lcore_id = rte_lcore_id();
> +
> + if (unlikely(lcore_id == LCORE_ID_ANY))
> + lcore_id = rte_get_master_lcore();
> +
> + return &rand_states[lcore_id];
> +}
> +
> +uint64_t __rte_experimental
> +rte_rand(void)
Do you really want to mark this as experimental? I know it will trigger the
symbol checker with a warning if you don't, but this function already existed
previously and was accepted as part of the ABI. Given that the prototype hasn't
changed, I think you just need to accept it as a non-experimental function
> +{
> + struct rte_rand_state *state;
> +
> + state = __rte_rand_get_state();
> +
> + return __rte_rand_lfsr258(state);
> +}
> +
> +RTE_INIT(rte_rand_init)
> +{
> + rte_srand(rte_get_timer_cycles());
> +}
> diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
> index 19854ee2c..ca616c480 100644
> --- a/lib/librte_eal/freebsd/eal/Makefile
> +++ b/lib/librte_eal/freebsd/eal/Makefile
> @@ -69,6 +69,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/freebsd/eal/eal.c b/lib/librte_eal/freebsd/eal/eal.c
> index c6ac9028f..5d43310b3 100644
> --- a/lib/librte_eal/freebsd/eal/eal.c
> +++ b/lib/librte_eal/freebsd/eal/eal.c
> @@ -727,8 +727,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> /* in secondary processes, memory init may allocate additional fbarrays
> * not present in primary processes, so to avoid any potential issues,
> * initialize memzones first.
> diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
> index 6e5261152..729795a10 100644
> --- a/lib/librte_eal/linux/eal/Makefile
> +++ b/lib/librte_eal/linux/eal/Makefile
> @@ -77,6 +77,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
> index f7ae62d7b..c2bdf0a67 100644
> --- a/lib/librte_eal/linux/eal/eal.c
> +++ b/lib/librte_eal/linux/eal/eal.c
> @@ -1083,8 +1083,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0) {
> rte_eal_init_alert("Cannot init logging.");
> rte_errno = ENOMEM;
> diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
> index d6e375135..0d60668fa 100644
> --- a/lib/librte_eal/rte_eal_version.map
> +++ b/lib/librte_eal/rte_eal_version.map
> @@ -366,10 +366,12 @@ EXPERIMENTAL {
> rte_mp_request_async;
> rte_mp_sendmsg;
> rte_option_register;
> + rte_rand;
> rte_realloc_socket;
> rte_service_lcore_attr_get;
> rte_service_lcore_attr_reset_all;
> rte_service_may_be_active;
> rte_socket_count;
> rte_socket_id_by_idx;
> + rte_srand;
> };
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
2019-04-22 7:15 0% ` Dekel Peled
@ 2019-04-22 7:15 0% ` Dekel Peled
0 siblings, 0 replies; 200+ results
From: Dekel Peled @ 2019-04-22 7:15 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, Yongseok Koh,
Shahaf Shuler, arybchenko, dev, Ori Kam
Thanks, PSB.
> -----Original Message-----
> From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Sent: Thursday, April 18, 2019 3:31 PM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: wenzhuo.lu@intel.com; jingjing.wu@intel.com;
> bernard.iremonger@intel.com; Yongseok Koh <yskoh@mellanox.com>;
> Shahaf Shuler <shahafs@mellanox.com>; arybchenko@solarflare.com;
> dev@dpdk.org; Ori Kam <orika@mellanox.com>
> Subject: Re: [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
>
> On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> > Add actions:
> > - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> > - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP
> header.
> > - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> > header.
> > - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> > header.
> >
> > Original work by Xiaoyu Min.
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>
> Almost there... Some changes were not made as discussed, please see
> below.
>
> <snip>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 0203f4f..fc234de 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION
> error will be returned.
> > | ``mac_addr`` | MAC address |
> > +--------------+---------------+
> >
> > +Action: ``INC_TCP_SEQ``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Increase sequence number in the outermost TCP header.
> > +
> > +Using this action on non-matching traffic will result in undefined
> > +behavior, depending on PMD implementation.
>
> OK, "depending on PMD implementation" looks a bit redundant though.
Fine, will remove it.
>
> > +
> > +.. _table_rte_flow_action_inc_tcp_seq:
> > +
> > +.. table:: INC_TCP_SEQ
> > +
> > + +-----------+------------------------------------------+
> > + | Field | Value |
> > +
> +===========+==========================================+
> > + | ``value`` | Value to increase TCP sequence number by |
> > + +-----------+------------------------------------------+
>
> Configuration object documentation needs updating since you changed its
> type and fields.
>
> These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and
> DEC_TCP_ACK.
Will update.
>
> <snip>
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index c0fe879..e3f6210 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> > * See struct rte_flow_action_set_mac.
> > */
> > RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> > +
> > + /**
> > + * Increase sequence number in the outermost TCP header.
> > + *
> > + * Using this action on non-matching traffic will result in
> > + * undefined behavior, depending on PMD implementation.
>
> "depending on PMD implementation" also redundant here.
>
> <snip>
> > /*
> > + * @warning
> > + * @b EXPERIMENTAL: this union may change without prior notice
> > + *
> > + * General integer type, can be expanded as needed.
> > + */
> > +union rte_flow_integer {
> > + rte_be32_t be32;
> > +};
>
> You must include the extra fields you don't use (64/16/32/8 and
> le/be/host/signed variants as described in previous messages) to limit the
> risk of ABI breakage next time someone needs a field that isn't there yet.
>
> This object must be able to accommodate the largest supported integer and
> have the proper alignment constraints for any of these types, hence the
> union with all of them from the start.
I will add required fields for 8, 16 and 32 bits.
Adding 64 bit fields will inflate the union size, wasting memory.
It should be handled separately in specific cases.
>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * General struct, for use by actions that require a single integer value.
> > + */
> > +struct rte_flow_general_action {
> > + union rte_flow_integer integer;
> > +};
>
> Seriously, why can't actions take "union rte_flow_integer" directly? Besides
> "rte_flow_general_action" is vague as heck.
>
I prefer to follow the existing convention, where actions take struct even if it contains a single field.
I will define the union unnamed in the struct.
I will rename to rte_flow_integer_action.
> Seems like you made this structure so it could be extended later, but forgot
> that doing so is not an option since ABIs are set in stone. You must make new
> APIs as exhaustive and restrict their scope as much as possible from the start
> because of that.
>
> Note if you don't want to use union rte_flow_integer directly, it's also fine to
> document your actions as taking (const rte_be32_t *) directly through their
> conf pointer.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-18 12:30 3% ` Adrien Mazarguil
@ 2019-04-22 7:15 0% ` Dekel Peled
2019-04-22 7:15 0% ` Dekel Peled
1 sibling, 1 reply; 200+ results
From: Dekel Peled @ 2019-04-22 7:15 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, Yongseok Koh,
Shahaf Shuler, arybchenko, dev, Ori Kam
Thanks, PSB.
> -----Original Message-----
> From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Sent: Thursday, April 18, 2019 3:31 PM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: wenzhuo.lu@intel.com; jingjing.wu@intel.com;
> bernard.iremonger@intel.com; Yongseok Koh <yskoh@mellanox.com>;
> Shahaf Shuler <shahafs@mellanox.com>; arybchenko@solarflare.com;
> dev@dpdk.org; Ori Kam <orika@mellanox.com>
> Subject: Re: [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
>
> On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> > Add actions:
> > - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> > - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP
> header.
> > - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> > header.
> > - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> > header.
> >
> > Original work by Xiaoyu Min.
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>
> Almost there... Some changes were not made as discussed, please see
> below.
>
> <snip>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 0203f4f..fc234de 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION
> error will be returned.
> > | ``mac_addr`` | MAC address |
> > +--------------+---------------+
> >
> > +Action: ``INC_TCP_SEQ``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Increase sequence number in the outermost TCP header.
> > +
> > +Using this action on non-matching traffic will result in undefined
> > +behavior, depending on PMD implementation.
>
> OK, "depending on PMD implementation" looks a bit redundant though.
Fine, will remove it.
>
> > +
> > +.. _table_rte_flow_action_inc_tcp_seq:
> > +
> > +.. table:: INC_TCP_SEQ
> > +
> > + +-----------+------------------------------------------+
> > + | Field | Value |
> > +
> +===========+==========================================+
> > + | ``value`` | Value to increase TCP sequence number by |
> > + +-----------+------------------------------------------+
>
> Configuration object documentation needs updating since you changed its
> type and fields.
>
> These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and
> DEC_TCP_ACK.
Will update.
>
> <snip>
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index c0fe879..e3f6210 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> > * See struct rte_flow_action_set_mac.
> > */
> > RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> > +
> > + /**
> > + * Increase sequence number in the outermost TCP header.
> > + *
> > + * Using this action on non-matching traffic will result in
> > + * undefined behavior, depending on PMD implementation.
>
> "depending on PMD implementation" also redundant here.
>
> <snip>
> > /*
> > + * @warning
> > + * @b EXPERIMENTAL: this union may change without prior notice
> > + *
> > + * General integer type, can be expanded as needed.
> > + */
> > +union rte_flow_integer {
> > + rte_be32_t be32;
> > +};
>
> You must include the extra fields you don't use (64/16/32/8 and
> le/be/host/signed variants as described in previous messages) to limit the
> risk of ABI breakage next time someone needs a field that isn't there yet.
>
> This object must be able to accommodate the largest supported integer and
> have the proper alignment constraints for any of these types, hence the
> union with all of them from the start.
I will add required fields for 8, 16 and 32 bits.
Adding 64 bit fields will inflate the union size, wasting memory.
It should be handled separately in specific cases.
>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * General struct, for use by actions that require a single integer value.
> > + */
> > +struct rte_flow_general_action {
> > + union rte_flow_integer integer;
> > +};
>
> Seriously, why can't actions take "union rte_flow_integer" directly? Besides
> "rte_flow_general_action" is vague as heck.
>
I prefer to follow the existing convention, where actions take struct even if it contains a single field.
I will define the union unnamed in the struct.
I will rename to rte_flow_integer_action.
> Seems like you made this structure so it could be extended later, but forgot
> that doing so is not an option since ABIs are set in stone. You must make new
> APIs as exhaustive and restrict their scope as much as possible from the start
> because of that.
>
> Note if you don't want to use union rte_flow_integer directly, it's also fine to
> document your actions as taking (const rte_be32_t *) directly through their
> conf pointer.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK techboard minutes (2019-04-10)
2019-04-18 20:41 5% [dpdk-dev] DPDK techboard minutes (2019-04-10) Olivier Matz
@ 2019-04-18 20:41 5% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-04-18 20:41 UTC (permalink / raw)
To: dev; +Cc: DPDK Techboard
Hi,
Here are the meeting notes of the DPDK technical board meeting held on
2019-04-10.
Attendees:
- Bruce Richardson
- Ferruh Yigit
- Hemant Agrawal
- Jerin Jacob
- Konstantin Ananyev
- Olivier Matz
- Stephen Hemminger
- Thomas Monjalon
1) DPDK development process and tools survey
============================================
Reference: https://mails.dpdk.org/archives/dev/2019-March/126114.html
The objective of the survey is to detect problems (if any) in our
current process.
- The survey is now closed.
- Unfortunately the number of received responses is low compared to the
number of active DPDK developers.
- The answers and feedback will be gathered and summarized by mail.
- There will be a Q&A session on this topic at next Europe DPDK summit.
2) DPDK API Stability discussion
================================
Reference: https://mails.dpdk.org/archives/dev/2019-April/128969.html
- Following the discussion on the ML, there is a consensus that API/ABI
stability is a direction where the DPDK project should head for.
- Adding automated tools to check API/ABI stability is a good first step.
Here is a list of ABI checker tools:
- ABI Laboratory: https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
- https://sourceware.org/libabigail
- https://lvc.github.io/abi-compliance-checker
- The current dpdk tool, validate-abi.sh, is based on abi-compliance-checker.
- Patches like this one proposed by Stephen Hemminger should be generalized
to other parts of DPDK (everything that is not rx/tx path):
http://patches.dpdk.org/project/dpdk/list/?series=4248
- An "ABI/API stability" item will be added to techboard recurring topics.
- The documentation (guides/contributing/versioning,
guides/contributing/design) and website (including roadmap) should be
updated to highlight and explain the intent (Ray proposed himself).
- No calendar/deadlines was decided, let's discuss it again at next
techboard meeting.
3) SPDX licenses
================
There are still some old license headers in Intel driver base code, they
will be replaced by new shared code drops.
^ permalink raw reply [relevance 5%]
* [dpdk-dev] DPDK techboard minutes (2019-04-10)
@ 2019-04-18 20:41 5% Olivier Matz
2019-04-18 20:41 5% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-04-18 20:41 UTC (permalink / raw)
To: dev; +Cc: DPDK Techboard
Hi,
Here are the meeting notes of the DPDK technical board meeting held on
2019-04-10.
Attendees:
- Bruce Richardson
- Ferruh Yigit
- Hemant Agrawal
- Jerin Jacob
- Konstantin Ananyev
- Olivier Matz
- Stephen Hemminger
- Thomas Monjalon
1) DPDK development process and tools survey
============================================
Reference: https://mails.dpdk.org/archives/dev/2019-March/126114.html
The objective of the survey is to detect problems (if any) in our
current process.
- The survey is now closed.
- Unfortunately the number of received responses is low compared to the
number of active DPDK developers.
- The answers and feedback will be gathered and summarized by mail.
- There will be a Q&A session on this topic at next Europe DPDK summit.
2) DPDK API Stability discussion
================================
Reference: https://mails.dpdk.org/archives/dev/2019-April/128969.html
- Following the discussion on the ML, there is a consensus that API/ABI
stability is a direction where the DPDK project should head for.
- Adding automated tools to check API/ABI stability is a good first step.
Here is a list of ABI checker tools:
- ABI Laboratory: https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
- https://sourceware.org/libabigail
- https://lvc.github.io/abi-compliance-checker
- The current dpdk tool, validate-abi.sh, is based on abi-compliance-checker.
- Patches like this one proposed by Stephen Hemminger should be generalized
to other parts of DPDK (everything that is not rx/tx path):
http://patches.dpdk.org/project/dpdk/list/?series=4248
- An "ABI/API stability" item will be added to techboard recurring topics.
- The documentation (guides/contributing/versioning,
guides/contributing/design) and website (including roadmap) should be
updated to highlight and explain the intent (Ray proposed himself).
- No calendar/deadlines was decided, let's discuss it again at next
techboard meeting.
3) SPDX licenses
================
There are still some old license headers in Intel driver base code, they
will be replaced by new shared code drops.
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
2019-04-18 12:30 3% ` Adrien Mazarguil
@ 2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-22 7:15 0% ` Dekel Peled
1 sibling, 0 replies; 200+ results
From: Adrien Mazarguil @ 2019-04-18 12:30 UTC (permalink / raw)
To: Dekel Peled
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, yskoh, shahafs,
arybchenko, dev, orika
On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> Add actions:
> - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP header.
> - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> header.
> - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> header.
>
> Original work by Xiaoyu Min.
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Almost there... Some changes were not made as discussed, please see below.
<snip>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 0203f4f..fc234de 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned.
> | ``mac_addr`` | MAC address |
> +--------------+---------------+
>
> +Action: ``INC_TCP_SEQ``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Increase sequence number in the outermost TCP header.
> +
> +Using this action on non-matching traffic will result in undefined behavior,
> +depending on PMD implementation.
OK, "depending on PMD implementation" looks a bit redundant though.
> +
> +.. _table_rte_flow_action_inc_tcp_seq:
> +
> +.. table:: INC_TCP_SEQ
> +
> + +-----------+------------------------------------------+
> + | Field | Value |
> + +===========+==========================================+
> + | ``value`` | Value to increase TCP sequence number by |
> + +-----------+------------------------------------------+
Configuration object documentation needs updating since you changed its type
and fields.
These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and DEC_TCP_ACK.
<snip>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index c0fe879..e3f6210 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> * See struct rte_flow_action_set_mac.
> */
> RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> +
> + /**
> + * Increase sequence number in the outermost TCP header.
> + *
> + * Using this action on non-matching traffic will result in
> + * undefined behavior, depending on PMD implementation.
"depending on PMD implementation" also redundant here.
<snip>
> /*
> + * @warning
> + * @b EXPERIMENTAL: this union may change without prior notice
> + *
> + * General integer type, can be expanded as needed.
> + */
> +union rte_flow_integer {
> + rte_be32_t be32;
> +};
You must include the extra fields you don't use (64/16/32/8 and
le/be/host/signed variants as described in previous messages) to limit the
risk of ABI breakage next time someone needs a field that isn't there yet.
This object must be able to accommodate the largest supported integer and
have the proper alignment constraints for any of these types, hence the
union with all of them from the start.
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * General struct, for use by actions that require a single integer value.
> + */
> +struct rte_flow_general_action {
> + union rte_flow_integer integer;
> +};
Seriously, why can't actions take "union rte_flow_integer" directly? Besides
"rte_flow_general_action" is vague as heck.
Seems like you made this structure so it could be extended later, but forgot
that doing so is not an option since ABIs are set in stone. You must make
new APIs as exhaustive and restrict their scope as much as possible from the
start because of that.
Note if you don't want to use union rte_flow_integer directly, it's also
fine to document your actions as taking (const rte_be32_t *) directly
through their conf pointer.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
@ 2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-22 7:15 0% ` Dekel Peled
0 siblings, 2 replies; 200+ results
From: Adrien Mazarguil @ 2019-04-18 12:30 UTC (permalink / raw)
To: Dekel Peled
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, yskoh, shahafs,
arybchenko, dev, orika
On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> Add actions:
> - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP header.
> - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> header.
> - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> header.
>
> Original work by Xiaoyu Min.
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Almost there... Some changes were not made as discussed, please see below.
<snip>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 0203f4f..fc234de 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned.
> | ``mac_addr`` | MAC address |
> +--------------+---------------+
>
> +Action: ``INC_TCP_SEQ``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Increase sequence number in the outermost TCP header.
> +
> +Using this action on non-matching traffic will result in undefined behavior,
> +depending on PMD implementation.
OK, "depending on PMD implementation" looks a bit redundant though.
> +
> +.. _table_rte_flow_action_inc_tcp_seq:
> +
> +.. table:: INC_TCP_SEQ
> +
> + +-----------+------------------------------------------+
> + | Field | Value |
> + +===========+==========================================+
> + | ``value`` | Value to increase TCP sequence number by |
> + +-----------+------------------------------------------+
Configuration object documentation needs updating since you changed its type
and fields.
These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and DEC_TCP_ACK.
<snip>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index c0fe879..e3f6210 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> * See struct rte_flow_action_set_mac.
> */
> RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> +
> + /**
> + * Increase sequence number in the outermost TCP header.
> + *
> + * Using this action on non-matching traffic will result in
> + * undefined behavior, depending on PMD implementation.
"depending on PMD implementation" also redundant here.
<snip>
> /*
> + * @warning
> + * @b EXPERIMENTAL: this union may change without prior notice
> + *
> + * General integer type, can be expanded as needed.
> + */
> +union rte_flow_integer {
> + rte_be32_t be32;
> +};
You must include the extra fields you don't use (64/16/32/8 and
le/be/host/signed variants as described in previous messages) to limit the
risk of ABI breakage next time someone needs a field that isn't there yet.
This object must be able to accommodate the largest supported integer and
have the proper alignment constraints for any of these types, hence the
union with all of them from the start.
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * General struct, for use by actions that require a single integer value.
> + */
> +struct rte_flow_general_action {
> + union rte_flow_integer integer;
> +};
Seriously, why can't actions take "union rte_flow_integer" directly? Besides
"rte_flow_general_action" is vague as heck.
Seems like you made this structure so it could be extended later, but forgot
that doing so is not an option since ABIs are set in stone. You must make
new APIs as exhaustive and restrict their scope as much as possible from the
start because of that.
Note if you don't want to use union rte_flow_integer directly, it's also
fine to document your actions as taking (const rte_be32_t *) directly
through their conf pointer.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Release Status Meeting 18/4/2019
2019-04-18 10:58 3% [dpdk-dev] DPDK Release Status Meeting 18/4/2019 Ferruh Yigit
@ 2019-04-18 10:58 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-18 10:58 UTC (permalink / raw)
To: dpdk-dev
Cc: John McNamara, Stokes, Ian, Thomas Monjalon, Jerin Jacob, Akhil,
Goyal, Cristian Dumitrescu, Qian Xu, Yongseok Koh,
Maxime Coquelin, Qi Zhang, Shahaf Shuler, Pablo de Lara
Minutes 18 April 2019
---------------------
Agenda:
* Release Dates
* RC1 status
* Subtrees
* OvS
* Opens
Participants:
* Arm
* Debian
* Intel
* Mellanox
* RedHat
Release Dates
-------------
* v19.05 dates, RC2 date pushed to Friday:
* RC2: *Friday, 19 April*
* RC3: Monday , 29 April
* Release: Friday, 10 May
* v19.08 dates:
* Proposal/V1 Monday 03 June 2019
* Integration/Merge/RC1 Monday 01 July 2019
* Release Thurs 01 August 2019
* Schedule updated on roadmap page:
https://core.dpdk.org/roadmap/
* v19.11 proposed dates, please comment.
* Proposal/V1 Friday 06 September 2019
* Integration/Merge/RC1 Friday 11 October 2019
* Release Friday 08 November 2019
* Constrains:
* PRC holidays on October 1-7 inclusive, rc1 shouldn't overlap with it
* US DPDK Summit on mid November, better to have release before summit
* Some historical .11 release dates data:
17.08: Tue Aug 8
17.11-rc1: Sat Oct 14 (9 weeks and 4 days)
17.11: Wed Nov 15 (4 weeks and 4 days)
Overall 17.11 release took: 14 weeks and 1 day
18.08: Thu Aug 9
18.11-rc1: Mon Oct 29 (11 weeks and 4 days)
18.11: Mon Nov 26 (4 weeks)
Overall 18.11 release took: 15 weeks and 4 days
RC1 status
----------
* RC1 Intel test results looks good, no major issue detected
Subtrees
--------
* main
* Merged timer library
* For RCU there are questions around API/ABI stability (inline functions)
Leaning to merge as it is
* next-net
* Ready for rc2, some waiting fixes can go in after rc2
* If atlantic macsec patches makes on time, can go in rc2
* Remaining patches won't be able to make the release
* next-virtio
* Tree prepared for rc2 and merged into next-net
* next-crypto
* Akhil get some patches today/tomorrow
* Will be ready for rc2
* next-eventdev
* next-pipeline
* next-qos
* No update, we need attendance from maintainers
* Stable trees
* No update
OvS
---
* OvS master/2.11.x release agreed to move 18.11.1
* For DPDK 17.11, OvS decided to skip 17.11.5 and use 17.11.6 since it
is close to be released
* OvS testing on DPDK Community Lab is up now,
The discussion is which version of OvS and DPDK to use, using top of
development branch for both right now, should stick a fixed version for
OvS?
* af_xdp support on OvS proposed, there were some patches for it
Opens
-----
* Akhil is looking for co-maintainer for crypto sub-tree
* Coverity is up and there are already some fixes hit the mail list,
this is good progress, as a reminder, coverity dpdk project link:
https://scan.coverity.com/projects/dpdk-data-plane-development-kit?tab=overview
* A patch to fix all document spelling errors has been sent by John,
there will be new version of it
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Release Status Meeting 18/4/2019
@ 2019-04-18 10:58 3% Ferruh Yigit
2019-04-18 10:58 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-18 10:58 UTC (permalink / raw)
To: dpdk-dev
Cc: John McNamara, Stokes, Ian, Thomas Monjalon, Jerin Jacob, Akhil,
Goyal, Cristian Dumitrescu, Qian Xu, Yongseok Koh,
Maxime Coquelin, Qi Zhang, Shahaf Shuler, Pablo de Lara
Minutes 18 April 2019
---------------------
Agenda:
* Release Dates
* RC1 status
* Subtrees
* OvS
* Opens
Participants:
* Arm
* Debian
* Intel
* Mellanox
* RedHat
Release Dates
-------------
* v19.05 dates, RC2 date pushed to Friday:
* RC2: *Friday, 19 April*
* RC3: Monday , 29 April
* Release: Friday, 10 May
* v19.08 dates:
* Proposal/V1 Monday 03 June 2019
* Integration/Merge/RC1 Monday 01 July 2019
* Release Thurs 01 August 2019
* Schedule updated on roadmap page:
https://core.dpdk.org/roadmap/
* v19.11 proposed dates, please comment.
* Proposal/V1 Friday 06 September 2019
* Integration/Merge/RC1 Friday 11 October 2019
* Release Friday 08 November 2019
* Constrains:
* PRC holidays on October 1-7 inclusive, rc1 shouldn't overlap with it
* US DPDK Summit on mid November, better to have release before summit
* Some historical .11 release dates data:
17.08: Tue Aug 8
17.11-rc1: Sat Oct 14 (9 weeks and 4 days)
17.11: Wed Nov 15 (4 weeks and 4 days)
Overall 17.11 release took: 14 weeks and 1 day
18.08: Thu Aug 9
18.11-rc1: Mon Oct 29 (11 weeks and 4 days)
18.11: Mon Nov 26 (4 weeks)
Overall 18.11 release took: 15 weeks and 4 days
RC1 status
----------
* RC1 Intel test results looks good, no major issue detected
Subtrees
--------
* main
* Merged timer library
* For RCU there are questions around API/ABI stability (inline functions)
Leaning to merge as it is
* next-net
* Ready for rc2, some waiting fixes can go in after rc2
* If atlantic macsec patches makes on time, can go in rc2
* Remaining patches won't be able to make the release
* next-virtio
* Tree prepared for rc2 and merged into next-net
* next-crypto
* Akhil get some patches today/tomorrow
* Will be ready for rc2
* next-eventdev
* next-pipeline
* next-qos
* No update, we need attendance from maintainers
* Stable trees
* No update
OvS
---
* OvS master/2.11.x release agreed to move 18.11.1
* For DPDK 17.11, OvS decided to skip 17.11.5 and use 17.11.6 since it
is close to be released
* OvS testing on DPDK Community Lab is up now,
The discussion is which version of OvS and DPDK to use, using top of
development branch for both right now, should stick a fixed version for
OvS?
* af_xdp support on OvS proposed, there were some patches for it
Opens
-----
* Akhil is looking for co-maintainer for crypto sub-tree
* Coverity is up and there are already some fixes hit the mail list,
this is good progress, as a reminder, coverity dpdk project link:
https://scan.coverity.com/projects/dpdk-data-plane-development-kit?tab=overview
* A patch to fix all document spelling errors has been sent by John,
there will be new version of it
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 10:28 7% ` Bruce Richardson
@ 2019-04-18 10:28 7% ` Bruce Richardson
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-18 10:28 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >
> > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> > > Hello,
> > > There was a conversation [1] in the context of RCU library. I thought
> > > it needs participation from broader audience. Summary for the context
> > > (please look at [1] for full details)
> > >
> >
> > Thanks for kicking off this discussion
> >
> > > 1) How do we provide ABI compatibility when the code base contains
> > inline functions? Unless we freeze development in these inline functions and
> > corresponding structures, it might not be possible to claim ABI compatibility.
> > Application has to be recompiled.
> >
> > I agree that in some cases the application "might" need to be recompiled,
> > but on the other hand I also think that there are many cases where ABI
> > function versioning can still be used to mitigate things. For example, if we
> > think of a couple of various scenarios:
> >
> > 1. If everything is inline and variables are allocated by app, e.g.
> > spinlock on stack, then there is no issue as everything is application
> > contained.
> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
If the application wants the bugfix, then yes. However, if the app is
unaffected by the bug, then it should have the option of updating DPDK
without a recompile.
> >
> > 2. If the situation is as in #1, but the structures in question are passed to
> > non-inline DPDK functions. In this case, any changes to the structures require
> > those functions taking the structures to be versioned for old and new
> > structures
> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
No, there is never any need for two versions of the inline functions, only
the newest version is needed. This is because in the case of a newly compiled
application only the newest version of the non-inline functions is ever
used. The other older versions are only used at runtime for compatilibity
with pre-compiled apps with the older inlines.
> >
> > 3. If instead we have the case, like in rte_ring, where the data
> > structures are allocated using functions, but they are used via inlines
> > in the app. In this case the creation functions (and any other function
> > using the structures) need to be versioned so that the application gets
> > the expected structure back from the creation.
> The new structure members have to be added such that the previous layout
> is not affected. Either add at the end or use the gaps that are left
> because of cache line alignment.
>
Not necessarily. There is nothing that requires the older and newer
versions of a function to use the same structure. We can rename the
original structure when versioning the old function, and then create a new
structure with the original name for later recompiled code using the newest
ABIs.
> >
> > It might be useful to think of what other scenarios we have and what ones
> > are likely to be problematic, especially those that can't be solved by having
> > multiple function versions.
> >
> > > 2) Every function that is not in the direct datapath (fastpath?)
> > > should not be inline. Exceptions or things like rx/tx burst, ring
> > > enqueue/dequeue, and packet alloc/free - Stephen
> >
> > Agree with this. Anything not data path should not be inline. The next
> Yes, very clear on this.
>
> > question then is for data path items how to determine whether they need to
> > be inline or not. In general my rule-of-thumb:
> > * anything dealing with bursts of packets should not be inline
> > * anything what works with single packet at a time should be inline
> >
> > The one exception to this rule is cases where we have to consider "empty
> > polling" as a likely use-case. For example, rte_ring_dequeue_burst works
> > with bursts of packets, but there is a valid application use case where a
> > thread could be polling a set of rings where only a small number are
> > actually busy. Right now, polling an empty ring only costs a few cycles,
> > meaning that it's neglible to have a few polls of empty rings before you get
> > to a busy one. Having that function not-inline will cause that cost to jump
> > significantly, so could cause problems. (This leads to the interesting scenario
> > where ring enqueue is safe to un-inline, while dequeue is not).
> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
Yes, I would tend to agree in general. The other thing is the frequency of
calls, and - as already stated - whether it takes a burst of not. Because
even if it's a trivial function that takes only 10 cycles and we want to
uninline it, the cost may double; but if it takes a burst of packets and is
only used once/twice per burst the cost per packet should still only be a
fraction of a cycle.
> >
> > > 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
> > > rcu should be one of such exceptions - it is just another
> > > synchronization mechanism after all (just a bit more sophisticated). -
> > > Konstantin
> > >
> > In general I believe the synchronisation primitives should be inline.
> > However, it does come down to cost too - if a function takes 300 cycles, do
> > we really care if it takes 305 or 310 instead to make it not inline?
> > Hopefully most synchronisation primitives are faster than this so this
> > situation should not occur.
> >
> > > 2) and 3) can be good guidelines to what functions/APIs can be inline. But,
> > I believe this guideline exists today too. Are there any thoughts to change
> > this?
> > >
> > > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the
> > inline functions are converted to normal functions and symbol versioning is
> > done for those (not bothering about performance).
> > >
> > I disagree. I think even in the case of #1, we should be able to manage some
> > changes without breaking ABI.
> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
Having multiple LTS's per distro would be nice, but it's putting a lot more
work on the distro folks, I think.
> >
> > > In this context, does it make sense to say that we will maintain API
> > > compatibility rather than saying ABI compatibility? This will also
> > > send the right message to the end users.
> > >
> > I would value ABI compatibility much higher than API compatibility. If
> > someone is recompiling the application anyway, making a couple of small
> > changes (large rework is obviously a different issue) to the code should not
> > be a massive issue, I hope. On the other hand, ABI compatibility is needed to
> > allow seamless update from one version to another, and it's that ABI
> > compatiblity that allows distro's to pick up our latest and greatest versions.
> >
> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>
The trouble here is that a DPDK release, as a product is either backward
compatible or not. Either a user can take it as a drop-in replacement for
the previous version or not. Users do not want to have to go through a
checklist for each app to see if the app uses only "compatible" APIs or
not. Same for the distro folks, they are not going to take some libs from a
release but not others because the ABI is broken for some but not others.
Regards,
/Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 4:34 9% ` Honnappa Nagarahalli
@ 2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Bruce Richardson @ 2019-04-18 10:28 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >
> > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> > > Hello,
> > > There was a conversation [1] in the context of RCU library. I thought
> > > it needs participation from broader audience. Summary for the context
> > > (please look at [1] for full details)
> > >
> >
> > Thanks for kicking off this discussion
> >
> > > 1) How do we provide ABI compatibility when the code base contains
> > inline functions? Unless we freeze development in these inline functions and
> > corresponding structures, it might not be possible to claim ABI compatibility.
> > Application has to be recompiled.
> >
> > I agree that in some cases the application "might" need to be recompiled,
> > but on the other hand I also think that there are many cases where ABI
> > function versioning can still be used to mitigate things. For example, if we
> > think of a couple of various scenarios:
> >
> > 1. If everything is inline and variables are allocated by app, e.g.
> > spinlock on stack, then there is no issue as everything is application
> > contained.
> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
If the application wants the bugfix, then yes. However, if the app is
unaffected by the bug, then it should have the option of updating DPDK
without a recompile.
> >
> > 2. If the situation is as in #1, but the structures in question are passed to
> > non-inline DPDK functions. In this case, any changes to the structures require
> > those functions taking the structures to be versioned for old and new
> > structures
> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
No, there is never any need for two versions of the inline functions, only
the newest version is needed. This is because in the case of a newly compiled
application only the newest version of the non-inline functions is ever
used. The other older versions are only used at runtime for compatilibity
with pre-compiled apps with the older inlines.
> >
> > 3. If instead we have the case, like in rte_ring, where the data
> > structures are allocated using functions, but they are used via inlines
> > in the app. In this case the creation functions (and any other function
> > using the structures) need to be versioned so that the application gets
> > the expected structure back from the creation.
> The new structure members have to be added such that the previous layout
> is not affected. Either add at the end or use the gaps that are left
> because of cache line alignment.
>
Not necessarily. There is nothing that requires the older and newer
versions of a function to use the same structure. We can rename the
original structure when versioning the old function, and then create a new
structure with the original name for later recompiled code using the newest
ABIs.
> >
> > It might be useful to think of what other scenarios we have and what ones
> > are likely to be problematic, especially those that can't be solved by having
> > multiple function versions.
> >
> > > 2) Every function that is not in the direct datapath (fastpath?)
> > > should not be inline. Exceptions or things like rx/tx burst, ring
> > > enqueue/dequeue, and packet alloc/free - Stephen
> >
> > Agree with this. Anything not data path should not be inline. The next
> Yes, very clear on this.
>
> > question then is for data path items how to determine whether they need to
> > be inline or not. In general my rule-of-thumb:
> > * anything dealing with bursts of packets should not be inline
> > * anything what works with single packet at a time should be inline
> >
> > The one exception to this rule is cases where we have to consider "empty
> > polling" as a likely use-case. For example, rte_ring_dequeue_burst works
> > with bursts of packets, but there is a valid application use case where a
> > thread could be polling a set of rings where only a small number are
> > actually busy. Right now, polling an empty ring only costs a few cycles,
> > meaning that it's neglible to have a few polls of empty rings before you get
> > to a busy one. Having that function not-inline will cause that cost to jump
> > significantly, so could cause problems. (This leads to the interesting scenario
> > where ring enqueue is safe to un-inline, while dequeue is not).
> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
Yes, I would tend to agree in general. The other thing is the frequency of
calls, and - as already stated - whether it takes a burst of not. Because
even if it's a trivial function that takes only 10 cycles and we want to
uninline it, the cost may double; but if it takes a burst of packets and is
only used once/twice per burst the cost per packet should still only be a
fraction of a cycle.
> >
> > > 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
> > > rcu should be one of such exceptions - it is just another
> > > synchronization mechanism after all (just a bit more sophisticated). -
> > > Konstantin
> > >
> > In general I believe the synchronisation primitives should be inline.
> > However, it does come down to cost too - if a function takes 300 cycles, do
> > we really care if it takes 305 or 310 instead to make it not inline?
> > Hopefully most synchronisation primitives are faster than this so this
> > situation should not occur.
> >
> > > 2) and 3) can be good guidelines to what functions/APIs can be inline. But,
> > I believe this guideline exists today too. Are there any thoughts to change
> > this?
> > >
> > > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the
> > inline functions are converted to normal functions and symbol versioning is
> > done for those (not bothering about performance).
> > >
> > I disagree. I think even in the case of #1, we should be able to manage some
> > changes without breaking ABI.
> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
Having multiple LTS's per distro would be nice, but it's putting a lot more
work on the distro folks, I think.
> >
> > > In this context, does it make sense to say that we will maintain API
> > > compatibility rather than saying ABI compatibility? This will also
> > > send the right message to the end users.
> > >
> > I would value ABI compatibility much higher than API compatibility. If
> > someone is recompiling the application anyway, making a couple of small
> > changes (large rework is obviously a different issue) to the code should not
> > be a massive issue, I hope. On the other hand, ABI compatibility is needed to
> > allow seamless update from one version to another, and it's that ABI
> > compatiblity that allows distro's to pick up our latest and greatest versions.
> >
> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>
The trouble here is that a DPDK release, as a product is either backward
compatible or not. Either a user can take it as a drop-in replacement for
the previous version or not. Users do not want to have to go through a
checklist for each app to see if the app uses only "compatible" APIs or
not. Same for the distro folks, they are not going to take some libs from a
release but not others because the ABI is broken for some but not others.
Regards,
/Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:23 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-18 5:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, April 18, 2019 12:21 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
> <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> > I would value ABI compatibility much higher than API compatibility.
> > > If someone is recompiling the application anyway, making a couple of
> > > small changes (large rework is obviously a different issue) to the
> > > code should not be a massive issue, I hope. On the other hand, ABI
> > > compatibility is needed to allow seamless update from one version to
> > > another, and it's that ABI compatiblity that allows distro's to pick up our
> latest and greatest versions.
> >
> > IMO, We have two primary use case for DPDK
> >
> > 1) NFV kind of use case where the application needs to run on multiple
> platform
> > without recompiling it.
> > 2) Fixed appliance use case where embed SoC like Intel Denverton or
> > ARM64 integrated Controller used. For fixed appliance use case, end
> > user care more of performance than ABI compatibility as it easy to
> > recompile the end user application vs the cost of hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
For fixed appliance case, The update(FW update) will be a single blob which
Include all the components. So they can back port the security fix and recompile
the sw as needed.
The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
@ 2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
2 siblings, 2 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-18 5:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, April 18, 2019 12:21 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
> <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> > I would value ABI compatibility much higher than API compatibility.
> > > If someone is recompiling the application anyway, making a couple of
> > > small changes (large rework is obviously a different issue) to the
> > > code should not be a massive issue, I hope. On the other hand, ABI
> > > compatibility is needed to allow seamless update from one version to
> > > another, and it's that ABI compatiblity that allows distro's to pick up our
> latest and greatest versions.
> >
> > IMO, We have two primary use case for DPDK
> >
> > 1) NFV kind of use case where the application needs to run on multiple
> platform
> > without recompiling it.
> > 2) Fixed appliance use case where embed SoC like Intel Denverton or
> > ARM64 integrated Controller used. For fixed appliance use case, end
> > user care more of performance than ABI compatibility as it easy to
> > recompile the end user application vs the cost of hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
For fixed appliance case, The update(FW update) will be a single blob which
Include all the components. So they can back port the security fix and recompile
the sw as needed.
The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 4:34 9% ` Honnappa Nagarahalli
@ 2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 10:28 7% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-18 4:34 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, Honnappa Nagarahalli, nd, nd
>
> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> > Hello,
> > There was a conversation [1] in the context of RCU library. I thought
> > it needs participation from broader audience. Summary for the context
> > (please look at [1] for full details)
> >
>
> Thanks for kicking off this discussion
>
> > 1) How do we provide ABI compatibility when the code base contains
> inline functions? Unless we freeze development in these inline functions and
> corresponding structures, it might not be possible to claim ABI compatibility.
> Application has to be recompiled.
>
> I agree that in some cases the application "might" need to be recompiled,
> but on the other hand I also think that there are many cases where ABI
> function versioning can still be used to mitigate things. For example, if we
> think of a couple of various scenarios:
>
> 1. If everything is inline and variables are allocated by app, e.g.
> spinlock on stack, then there is no issue as everything is application
> contained.
If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
> 2. If the situation is as in #1, but the structures in question are passed to
> non-inline DPDK functions. In this case, any changes to the structures require
> those functions taking the structures to be versioned for old and new
> structures
I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
> 3. If instead we have the case, like in rte_ring, where the data structures are
> allocated using functions, but they are used via inlines in the app. In this
> case the creation functions (and any other function using the
> structures) need to be versioned so that the application gets the expected
> structure back from the creation.
The new structure members have to be added such that the previous layout is not affected. Either add at the end or use the gaps that are left because of cache line alignment.
>
> It might be useful to think of what other scenarios we have and what ones
> are likely to be problematic, especially those that can't be solved by having
> multiple function versions.
>
> > 2) Every function that is not in the direct datapath (fastpath?)
> > should not be inline. Exceptions or things like rx/tx burst, ring
> > enqueue/dequeue, and packet alloc/free - Stephen
>
> Agree with this. Anything not data path should not be inline. The next
Yes, very clear on this.
> question then is for data path items how to determine whether they need to
> be inline or not. In general my rule-of-thumb:
> * anything dealing with bursts of packets should not be inline
> * anything what works with single packet at a time should be inline
>
> The one exception to this rule is cases where we have to consider "empty
> polling" as a likely use-case. For example, rte_ring_dequeue_burst works
> with bursts of packets, but there is a valid application use case where a
> thread could be polling a set of rings where only a small number are
> actually busy. Right now, polling an empty ring only costs a few cycles,
> meaning that it's neglible to have a few polls of empty rings before you get
> to a busy one. Having that function not-inline will cause that cost to jump
> significantly, so could cause problems. (This leads to the interesting scenario
> where ring enqueue is safe to un-inline, while dequeue is not).
A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
> > 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
> > rcu should be one of such exceptions - it is just another
> > synchronization mechanism after all (just a bit more sophisticated). -
> > Konstantin
> >
> In general I believe the synchronisation primitives should be inline.
> However, it does come down to cost too - if a function takes 300 cycles, do
> we really care if it takes 305 or 310 instead to make it not inline?
> Hopefully most synchronisation primitives are faster than this so this
> situation should not occur.
>
> > 2) and 3) can be good guidelines to what functions/APIs can be inline. But,
> I believe this guideline exists today too. Are there any thoughts to change
> this?
> >
> > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the
> inline functions are converted to normal functions and symbol versioning is
> done for those (not bothering about performance).
> >
> I disagree. I think even in the case of #1, we should be able to manage some
> changes without breaking ABI.
I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also
> > send the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If
> someone is recompiling the application anyway, making a couple of small
> changes (large rework is obviously a different issue) to the code should not
> be a massive issue, I hope. On the other hand, ABI compatibility is needed to
> allow seamless update from one version to another, and it's that ABI
> compatiblity that allows distro's to pick up our latest and greatest versions.
>
I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
> Personally, I'd be happy enough to allow API changes at any point without
> deprecation notice, so long as function versioning is used to ensure ABI
> compatibility is kept.
>
> My 2c.
> /Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 9% ` Bruce Richardson
` (2 preceding siblings ...)
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
@ 2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 10:28 7% ` Bruce Richardson
3 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-18 4:34 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, Honnappa Nagarahalli, nd, nd
>
> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> > Hello,
> > There was a conversation [1] in the context of RCU library. I thought
> > it needs participation from broader audience. Summary for the context
> > (please look at [1] for full details)
> >
>
> Thanks for kicking off this discussion
>
> > 1) How do we provide ABI compatibility when the code base contains
> inline functions? Unless we freeze development in these inline functions and
> corresponding structures, it might not be possible to claim ABI compatibility.
> Application has to be recompiled.
>
> I agree that in some cases the application "might" need to be recompiled,
> but on the other hand I also think that there are many cases where ABI
> function versioning can still be used to mitigate things. For example, if we
> think of a couple of various scenarios:
>
> 1. If everything is inline and variables are allocated by app, e.g.
> spinlock on stack, then there is no issue as everything is application
> contained.
If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
> 2. If the situation is as in #1, but the structures in question are passed to
> non-inline DPDK functions. In this case, any changes to the structures require
> those functions taking the structures to be versioned for old and new
> structures
I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
> 3. If instead we have the case, like in rte_ring, where the data structures are
> allocated using functions, but they are used via inlines in the app. In this
> case the creation functions (and any other function using the
> structures) need to be versioned so that the application gets the expected
> structure back from the creation.
The new structure members have to be added such that the previous layout is not affected. Either add at the end or use the gaps that are left because of cache line alignment.
>
> It might be useful to think of what other scenarios we have and what ones
> are likely to be problematic, especially those that can't be solved by having
> multiple function versions.
>
> > 2) Every function that is not in the direct datapath (fastpath?)
> > should not be inline. Exceptions or things like rx/tx burst, ring
> > enqueue/dequeue, and packet alloc/free - Stephen
>
> Agree with this. Anything not data path should not be inline. The next
Yes, very clear on this.
> question then is for data path items how to determine whether they need to
> be inline or not. In general my rule-of-thumb:
> * anything dealing with bursts of packets should not be inline
> * anything what works with single packet at a time should be inline
>
> The one exception to this rule is cases where we have to consider "empty
> polling" as a likely use-case. For example, rte_ring_dequeue_burst works
> with bursts of packets, but there is a valid application use case where a
> thread could be polling a set of rings where only a small number are
> actually busy. Right now, polling an empty ring only costs a few cycles,
> meaning that it's neglible to have a few polls of empty rings before you get
> to a busy one. Having that function not-inline will cause that cost to jump
> significantly, so could cause problems. (This leads to the interesting scenario
> where ring enqueue is safe to un-inline, while dequeue is not).
A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
> > 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think
> > rcu should be one of such exceptions - it is just another
> > synchronization mechanism after all (just a bit more sophisticated). -
> > Konstantin
> >
> In general I believe the synchronisation primitives should be inline.
> However, it does come down to cost too - if a function takes 300 cycles, do
> we really care if it takes 305 or 310 instead to make it not inline?
> Hopefully most synchronisation primitives are faster than this so this
> situation should not occur.
>
> > 2) and 3) can be good guidelines to what functions/APIs can be inline. But,
> I believe this guideline exists today too. Are there any thoughts to change
> this?
> >
> > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the
> inline functions are converted to normal functions and symbol versioning is
> done for those (not bothering about performance).
> >
> I disagree. I think even in the case of #1, we should be able to manage some
> changes without breaking ABI.
I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also
> > send the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If
> someone is recompiling the application anyway, making a couple of small
> changes (large rework is obviously a different issue) to the code should not
> be a massive issue, I hope. On the other hand, ABI compatibility is needed to
> allow seamless update from one version to another, and it's that ABI
> compatiblity that allows distro's to pick up our latest and greatest versions.
>
I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
> Personally, I'd be happy enough to allow API changes at any point without
> deprecation notice, so long as function versioning is used to ensure ABI
> compatibility is kept.
>
> My 2c.
> /Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 18:51 4% ` Stephen Hemminger
@ 2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-17 18:51 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 17:46:34 +0000
Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> > Sent: Wednesday, April 17, 2019 2:07 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> > Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> > Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> > Subject: Re: [dpdk-dev] ABI and inline functions
> >
> > > 2) Every function that is not in the direct datapath (fastpath?)
> > > should not be inline. Exceptions or things like rx/tx burst, ring
> > > enqueue/dequeue, and packet alloc/free - Stephen
> >
> > Agree with this. Anything not data path should not be inline. The next question
> > then is for data path items how to determine whether they need to be inline or
> > not. In general my rule-of-thumb:
> > * anything dealing with bursts of packets should not be inline
>
> # I think, we need consider the how fat is the function too,
> If it is light weight, probably we need to make it inline
> # Except the forward case, In real world use case, it is not trivial make large
> burst of packet to process it even though function prototype burst.
> We may need to consider that
> # For the given function if some argument is used with inline other function,
> probably no point in making that function alone inline as the structure
> is exposed in some other function.
>
> > * anything what works with single packet at a time should be inline
> >
> > > In this context, does it make sense to say that we will maintain API
> > > compatibility rather than saying ABI compatibility? This will also
> > > send the right message to the end users.
> > >
> > I would value ABI compatibility much higher than API compatibility. If someone
> > is recompiling the application anyway, making a couple of small changes (large
> > rework is obviously a different issue) to the code should not be a massive issue, I
> > hope. On the other hand, ABI compatibility is needed to allow seamless update
> > from one version to another, and it's that ABI compatiblity that allows distro's to
> > pick up our latest and greatest versions.
>
> IMO, We have two primary use case for DPDK
>
> 1) NFV kind of use case where the application needs to run on multiple platform
> without recompiling it.
> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
> Controller used. For fixed appliance use case, end user care more of performance
> than ABI compatibility as it easy to recompile the end user application vs the cost of
> hitting performance impact.
Nobody cares about compatiablity until they have to the first security update.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
@ 2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Stephen Hemminger @ 2019-04-17 18:51 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 17:46:34 +0000
Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> > Sent: Wednesday, April 17, 2019 2:07 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> > Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> > Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> > Subject: Re: [dpdk-dev] ABI and inline functions
> >
> > > 2) Every function that is not in the direct datapath (fastpath?)
> > > should not be inline. Exceptions or things like rx/tx burst, ring
> > > enqueue/dequeue, and packet alloc/free - Stephen
> >
> > Agree with this. Anything not data path should not be inline. The next question
> > then is for data path items how to determine whether they need to be inline or
> > not. In general my rule-of-thumb:
> > * anything dealing with bursts of packets should not be inline
>
> # I think, we need consider the how fat is the function too,
> If it is light weight, probably we need to make it inline
> # Except the forward case, In real world use case, it is not trivial make large
> burst of packet to process it even though function prototype burst.
> We may need to consider that
> # For the given function if some argument is used with inline other function,
> probably no point in making that function alone inline as the structure
> is exposed in some other function.
>
> > * anything what works with single packet at a time should be inline
> >
> > > In this context, does it make sense to say that we will maintain API
> > > compatibility rather than saying ABI compatibility? This will also
> > > send the right message to the end users.
> > >
> > I would value ABI compatibility much higher than API compatibility. If someone
> > is recompiling the application anyway, making a couple of small changes (large
> > rework is obviously a different issue) to the code should not be a massive issue, I
> > hope. On the other hand, ABI compatibility is needed to allow seamless update
> > from one version to another, and it's that ABI compatiblity that allows distro's to
> > pick up our latest and greatest versions.
>
> IMO, We have two primary use case for DPDK
>
> 1) NFV kind of use case where the application needs to run on multiple platform
> without recompiling it.
> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
> Controller used. For fixed appliance use case, end user care more of performance
> than ABI compatibility as it easy to recompile the end user application vs the cost of
> hitting performance impact.
Nobody cares about compatiablity until they have to the first security update.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
@ 2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 18:51 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-17 17:46 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Wednesday, April 17, 2019 2:07 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] ABI and inline functions
>
> > 2) Every function that is not in the direct datapath (fastpath?)
> > should not be inline. Exceptions or things like rx/tx burst, ring
> > enqueue/dequeue, and packet alloc/free - Stephen
>
> Agree with this. Anything not data path should not be inline. The next question
> then is for data path items how to determine whether they need to be inline or
> not. In general my rule-of-thumb:
> * anything dealing with bursts of packets should not be inline
# I think, we need consider the how fat is the function too,
If it is light weight, probably we need to make it inline
# Except the forward case, In real world use case, it is not trivial make large
burst of packet to process it even though function prototype burst.
We may need to consider that
# For the given function if some argument is used with inline other function,
probably no point in making that function alone inline as the structure
is exposed in some other function.
> * anything what works with single packet at a time should be inline
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also
> > send the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If someone
> is recompiling the application anyway, making a couple of small changes (large
> rework is obviously a different issue) to the code should not be a massive issue, I
> hope. On the other hand, ABI compatibility is needed to allow seamless update
> from one version to another, and it's that ABI compatiblity that allows distro's to
> pick up our latest and greatest versions.
IMO, We have two primary use case for DPDK
1) NFV kind of use case where the application needs to run on multiple platform
without recompiling it.
2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
Controller used. For fixed appliance use case, end user care more of performance
than ABI compatibility as it easy to recompile the end user application vs the cost of
hitting performance impact.
IMO, DPDK needs to cater to both category.
My 2c.
>
> Personally, I'd be happy enough to allow API changes at any point without
> deprecation notice, so long as function versioning is used to ensure ABI
> compatibility is kept.
>
> My 2c.
> /Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
@ 2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 4:34 9% ` Honnappa Nagarahalli
3 siblings, 2 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-17 17:46 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Wednesday, April 17, 2019 2:07 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] ABI and inline functions
>
> > 2) Every function that is not in the direct datapath (fastpath?)
> > should not be inline. Exceptions or things like rx/tx burst, ring
> > enqueue/dequeue, and packet alloc/free - Stephen
>
> Agree with this. Anything not data path should not be inline. The next question
> then is for data path items how to determine whether they need to be inline or
> not. In general my rule-of-thumb:
> * anything dealing with bursts of packets should not be inline
# I think, we need consider the how fat is the function too,
If it is light weight, probably we need to make it inline
# Except the forward case, In real world use case, it is not trivial make large
burst of packet to process it even though function prototype burst.
We may need to consider that
# For the given function if some argument is used with inline other function,
probably no point in making that function alone inline as the structure
is exposed in some other function.
> * anything what works with single packet at a time should be inline
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also
> > send the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If someone
> is recompiling the application anyway, making a couple of small changes (large
> rework is obviously a different issue) to the code should not be a massive issue, I
> hope. On the other hand, ABI compatibility is needed to allow seamless update
> from one version to another, and it's that ABI compatiblity that allows distro's to
> pick up our latest and greatest versions.
IMO, We have two primary use case for DPDK
1) NFV kind of use case where the application needs to run on multiple platform
without recompiling it.
2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
Controller used. For fixed appliance use case, end user care more of performance
than ABI compatibility as it easy to recompile the end user application vs the cost of
hitting performance impact.
IMO, DPDK needs to cater to both category.
My 2c.
>
> Personally, I'd be happy enough to allow API changes at any point without
> deprecation notice, so long as function versioning is used to ensure ABI
> compatibility is kept.
>
> My 2c.
> /Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 16:52 4% ` Stephen Hemminger
@ 2019-04-17 16:52 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-17 16:52 UTC (permalink / raw)
To: Bruce Richardson
Cc: Honnappa Nagarahalli, dev, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 09:36:38 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
> >
> I disagree. I think even in the case of #1, we should be able to manage
> some changes without breaking ABI.
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also send
> > the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If
> someone is recompiling the application anyway, making a couple of small
> changes (large rework is obviously a different issue) to the code should
> not be a massive issue, I hope. On the other hand, ABI compatibility is
> needed to allow seamless update from one version to another, and it's that
> ABI compatiblity that allows distro's to pick up our latest and greatest
> versions.
Agree with Bruce. What is most important about API is that the function
should change signature if behavior changes. I.e catch API changes at
compile time (not runtime).
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
@ 2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-18 4:34 9% ` Honnappa Nagarahalli
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-17 16:52 UTC (permalink / raw)
To: Bruce Richardson
Cc: Honnappa Nagarahalli, dev, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 09:36:38 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
> >
> I disagree. I think even in the case of #1, we should be able to manage
> some changes without breaking ABI.
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also send
> > the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If
> someone is recompiling the application anyway, making a couple of small
> changes (large rework is obviously a different issue) to the code should
> not be a massive issue, I hope. On the other hand, ABI compatibility is
> needed to allow seamless update from one version to another, and it's that
> ABI compatiblity that allows distro's to pick up our latest and greatest
> versions.
Agree with Bruce. What is most important about API is that the function
should change signature if behavior changes. I.e catch API changes at
compile time (not runtime).
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 14:18 0% ` Thomas Monjalon
@ 2019-04-17 14:18 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-17 14:18 UTC (permalink / raw)
To: Ananyev, Konstantin, Honnappa Nagarahalli, Stephen Hemminger
Cc: dev, paulmck, Kovacevic, Marko, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
17/04/2019 15:39, Ananyev, Konstantin:
> In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
> and then figure out that no-one using them because they are too slow.
> Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
> (as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
> If we'll find there is no real difference - move it to not-inlined version in 19.08.
> It is experimental for now - so could be changed without formal ABI breakage.
I agree, it looks reasonnable to take v6 of RCU patches
as an experimental implementation.
Then we can run some tests and discuss about inlining or not
before promoting it as a stable API.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 14:02 0% ` Honnappa Nagarahalli
@ 2019-04-17 14:18 0% ` Thomas Monjalon
2019-04-17 14:18 0% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-17 14:18 UTC (permalink / raw)
To: Ananyev, Konstantin, Honnappa Nagarahalli, Stephen Hemminger
Cc: dev, paulmck, Kovacevic, Marko, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
17/04/2019 15:39, Ananyev, Konstantin:
> In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
> and then figure out that no-one using them because they are too slow.
> Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
> (as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
> If we'll find there is no real difference - move it to not-inlined version in 19.08.
> It is experimental for now - so could be changed without formal ABI breakage.
I agree, it looks reasonnable to take v6 of RCU patches
as an experimental implementation.
Then we can run some tests and discuss about inlining or not
before promoting it as a stable API.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 14:02 0% ` Honnappa Nagarahalli
@ 2019-04-17 14:02 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 14:02 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > > > >
> > > > > > > > > > > > > After evaluating long term API/ABI issues, I
> > > > > > > > > > > > > think you need to get rid of almost all use of
> > > > > > > > > > > > > inline and visible structures. Yes it might be
> > > > > > > > > > > > > marginally slower, but you thank me
> > > > > > > the first time you have to fix something.
> > > > > > > > > > > > >
> > > > > > > > > > > > Agree, I was planning on another version to
> > > > > > > > > > > > address this (I am yet
> > > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > > The structure visibility definitely needs to be
> addressed.
> > > > > > > > > > > > For the inline functions, is the plan to convert
> > > > > > > > > > > > all the inline functions in DPDK? If yes, I think
> > > > > > > > > > > > we need to consider the performance
> > > > > > > > > > > difference. May be consider L3-fwd application,
> > > > > > > > > > > change all the
> > > > > > > inline functions in its path and run a test?
> > > > > > > > > > >
> > > > > > > > > > > Every function that is not in the direct datapath
> > > > > > > > > > > should not be
> > > > > > > inline.
> > > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > > have
> > > > > inline functions (unless we freeze any development in these
> > > > > inline functions forever).
> > > > > >
> > > > > > > > > >
> > > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > > I think rcu should be one of such exceptions - it is
> > > > > > > > > > just another synchronization mechanism after all (just
> > > > > > > > > > a bit more
> > > > > sophisticated).
> > > > > > > > > > Konstantin
> > > > > > > > >
> > > > > > > > > If you look at the other userspace RCU, you wil see that
> > > > > > > > > the only inlines are the rcu_read_lock,rcu_read_unlock
> > > > > > > > > and
> > > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > > >
> > > > > > > > > The synchronization logic is all real functions.
> > > > > > > >
> > > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > > https://github.com/urcu/userspace-
> > > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > > urcu-qsbr.h I still don't understand why we have to treat
> > > > > > > > it differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > > If we gone all the way to create our own version of rcu,
> > > > > > > > we probably want it to be as fast as possible (I know that
> > > > > > > > main speedup should come from the fact that readers don't
> > > > > > > > have to wait for writer to finish, but still...)
> > > > > > > >
> > > > > > > > Konstantin
> > > > > > > >
> > > > > > >
> > > > > > > Having locking functions inline is already a problem in
> > > > > > > current
> > > releases.
> > > > > > > The implementation can not be improved without breaking ABI
> > > > > > > (or doing special workarounds like lock v2)
> > > > > > I think ABI and inline function discussion needs to be taken
> > > > > > up in a
> > > > > different thread.
> > > > > >
> > > > > > Currently, I am looking to hide the structure visibility. I
> > > > > > looked at your
> > > > > patch [1], it is a different case than what I have in this
> > > > > patch. It is a pretty generic use case as well (similar
> > > > > situation exists in other libraries). I think a generic solution should
> be agreed upon.
> > > > > >
> > > > > > If we have to hide the structure content, the handle to QS
> > > > > > variable
> > > > > returned to the application needs to be opaque. I suggest using
> 'void *'
> > > > > behind which any structure can be used.
> > > > > >
> > > > > > typedef void * rte_rcu_qsbr_t; typedef void * rte_hash_t;
> > > > > >
> > > > > > But it requires typecasting.
> > > > > >
> > > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > > >
> > > > > C allows structure to be defined without knowing what is in it
> > > therefore.
> > > > >
> > > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > > >
> > > > > is preferred (or do it without typedef)
> > > > >
> > > > > struct rte_rcu_qsbr;
> > > >
> > > > I see that rte_hash library uses the same approach (struct
> > > > rte_hash in
> > > rte_hash.h, though it is marking as internal). But the ABI
> > > Laboratory tool [1] seems to be reporting incorrect numbers for this
> > > library even though the internal structure is changed.
> > > >
> > > > [1]
> > > > https://abi-
> > > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > > 2&v2=current&obj=66794&kind=abi
> > >
> > > The problem is rte_hash structure is exposed as part of ABI in
> > > rte_cuckoo_hash.h This was a mistake.
> > Do you mean, due to the use of structure with the same name? I am
> > wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
> >
> > For the RCU library, we either need to go all functions or leave it
> > the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
> >
> > I converted the inline functions to function calls.
> >
> > Testing on Arm platform (results *are* repeatable) shows very minimal
> > drop (0.1% to 0.2%) in performance while using lock-free rte_hash data
> structure. But one of the test cases which is just spinning shows good
> amount of drop (41%).
> >
> > Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty
> > repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning
> show significant drop (14%, 155%, 231%).
> > Konstantin, any thoughts on the results?
>
> The fact that function show better result than inline (even for hash) is sort
> of surprise to me.
It was a surprise to me too and counter-intuitive to my understanding.
> Don't have any good explanation off-hand, but the actual numbers for
> hash test are huge by itself...
>
> In general, I still think that sync primitives better to stay inlined - there is
> no much point to create ones and then figure out that no-one using them
> because they are too slow.
> Though if there is no real perf difference between inlined and normal - no
> point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do
> further perf testing with it (as I remember there were suggestions about
> using it in l3fwd for guarding routing table or so).
Yes, there is more work planned to integrate the library better which might provide more insight.
> If we'll find there is no real difference - move it to not-inlined version in
> 19.08.
+1.
> It is experimental for now - so could be changed without formal ABI
> breakage.
>
> Konstantin
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
@ 2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:18 0% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 14:02 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > > > >
> > > > > > > > > > > > > After evaluating long term API/ABI issues, I
> > > > > > > > > > > > > think you need to get rid of almost all use of
> > > > > > > > > > > > > inline and visible structures. Yes it might be
> > > > > > > > > > > > > marginally slower, but you thank me
> > > > > > > the first time you have to fix something.
> > > > > > > > > > > > >
> > > > > > > > > > > > Agree, I was planning on another version to
> > > > > > > > > > > > address this (I am yet
> > > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > > The structure visibility definitely needs to be
> addressed.
> > > > > > > > > > > > For the inline functions, is the plan to convert
> > > > > > > > > > > > all the inline functions in DPDK? If yes, I think
> > > > > > > > > > > > we need to consider the performance
> > > > > > > > > > > difference. May be consider L3-fwd application,
> > > > > > > > > > > change all the
> > > > > > > inline functions in its path and run a test?
> > > > > > > > > > >
> > > > > > > > > > > Every function that is not in the direct datapath
> > > > > > > > > > > should not be
> > > > > > > inline.
> > > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > > have
> > > > > inline functions (unless we freeze any development in these
> > > > > inline functions forever).
> > > > > >
> > > > > > > > > >
> > > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > > I think rcu should be one of such exceptions - it is
> > > > > > > > > > just another synchronization mechanism after all (just
> > > > > > > > > > a bit more
> > > > > sophisticated).
> > > > > > > > > > Konstantin
> > > > > > > > >
> > > > > > > > > If you look at the other userspace RCU, you wil see that
> > > > > > > > > the only inlines are the rcu_read_lock,rcu_read_unlock
> > > > > > > > > and
> > > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > > >
> > > > > > > > > The synchronization logic is all real functions.
> > > > > > > >
> > > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > > https://github.com/urcu/userspace-
> > > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > > urcu-qsbr.h I still don't understand why we have to treat
> > > > > > > > it differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > > If we gone all the way to create our own version of rcu,
> > > > > > > > we probably want it to be as fast as possible (I know that
> > > > > > > > main speedup should come from the fact that readers don't
> > > > > > > > have to wait for writer to finish, but still...)
> > > > > > > >
> > > > > > > > Konstantin
> > > > > > > >
> > > > > > >
> > > > > > > Having locking functions inline is already a problem in
> > > > > > > current
> > > releases.
> > > > > > > The implementation can not be improved without breaking ABI
> > > > > > > (or doing special workarounds like lock v2)
> > > > > > I think ABI and inline function discussion needs to be taken
> > > > > > up in a
> > > > > different thread.
> > > > > >
> > > > > > Currently, I am looking to hide the structure visibility. I
> > > > > > looked at your
> > > > > patch [1], it is a different case than what I have in this
> > > > > patch. It is a pretty generic use case as well (similar
> > > > > situation exists in other libraries). I think a generic solution should
> be agreed upon.
> > > > > >
> > > > > > If we have to hide the structure content, the handle to QS
> > > > > > variable
> > > > > returned to the application needs to be opaque. I suggest using
> 'void *'
> > > > > behind which any structure can be used.
> > > > > >
> > > > > > typedef void * rte_rcu_qsbr_t; typedef void * rte_hash_t;
> > > > > >
> > > > > > But it requires typecasting.
> > > > > >
> > > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > > >
> > > > > C allows structure to be defined without knowing what is in it
> > > therefore.
> > > > >
> > > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > > >
> > > > > is preferred (or do it without typedef)
> > > > >
> > > > > struct rte_rcu_qsbr;
> > > >
> > > > I see that rte_hash library uses the same approach (struct
> > > > rte_hash in
> > > rte_hash.h, though it is marking as internal). But the ABI
> > > Laboratory tool [1] seems to be reporting incorrect numbers for this
> > > library even though the internal structure is changed.
> > > >
> > > > [1]
> > > > https://abi-
> > > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > > 2&v2=current&obj=66794&kind=abi
> > >
> > > The problem is rte_hash structure is exposed as part of ABI in
> > > rte_cuckoo_hash.h This was a mistake.
> > Do you mean, due to the use of structure with the same name? I am
> > wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
> >
> > For the RCU library, we either need to go all functions or leave it
> > the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
> >
> > I converted the inline functions to function calls.
> >
> > Testing on Arm platform (results *are* repeatable) shows very minimal
> > drop (0.1% to 0.2%) in performance while using lock-free rte_hash data
> structure. But one of the test cases which is just spinning shows good
> amount of drop (41%).
> >
> > Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty
> > repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning
> show significant drop (14%, 155%, 231%).
> > Konstantin, any thoughts on the results?
>
> The fact that function show better result than inline (even for hash) is sort
> of surprise to me.
It was a surprise to me too and counter-intuitive to my understanding.
> Don't have any good explanation off-hand, but the actual numbers for
> hash test are huge by itself...
>
> In general, I still think that sync primitives better to stay inlined - there is
> no much point to create ones and then figure out that no-one using them
> because they are too slow.
> Though if there is no real perf difference between inlined and normal - no
> point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do
> further perf testing with it (as I remember there were suggestions about
> using it in l3fwd for guarding routing table or so).
Yes, there is more work planned to integrate the library better which might provide more insight.
> If we'll find there is no real difference - move it to not-inlined version in
> 19.08.
+1.
> It is experimental for now - so could be changed without formal ABI
> breakage.
>
> Konstantin
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 13:39 3% ` Ananyev, Konstantin
@ 2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:18 0% ` Thomas Monjalon
2 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-17 13:39 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
> > > > > > > > > > > >
> > > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > > slower, but you thank me
> > > > > > the first time you have to fix something.
> > > > > > > > > > > >
> > > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > > this (I am yet
> > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > > to consider the performance
> > > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > > all the
> > > > > > inline functions in its path and run a test?
> > > > > > > > > >
> > > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > > not be
> > > > > > inline.
> > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > have
> > > > inline functions (unless we freeze any development in these inline
> > > > functions forever).
> > > > >
> > > > > > > > >
> > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > > more
> > > > sophisticated).
> > > > > > > > > Konstantin
> > > > > > > >
> > > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > >
> > > > > > > > The synchronization logic is all real functions.
> > > > > > >
> > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > https://github.com/urcu/userspace-
> > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > > probably want it to be as fast as possible (I know that main
> > > > > > > speedup should come from the fact that readers don't have to
> > > > > > > wait for writer to finish, but still...)
> > > > > > >
> > > > > > > Konstantin
> > > > > > >
> > > > > >
> > > > > > Having locking functions inline is already a problem in current
> > releases.
> > > > > > The implementation can not be improved without breaking ABI (or
> > > > > > doing special workarounds like lock v2)
> > > > > I think ABI and inline function discussion needs to be taken up in
> > > > > a
> > > > different thread.
> > > > >
> > > > > Currently, I am looking to hide the structure visibility. I looked
> > > > > at your
> > > > patch [1], it is a different case than what I have in this patch. It
> > > > is a pretty generic use case as well (similar situation exists in
> > > > other libraries). I think a generic solution should be agreed upon.
> > > > >
> > > > > If we have to hide the structure content, the handle to QS
> > > > > variable
> > > > returned to the application needs to be opaque. I suggest using 'void *'
> > > > behind which any structure can be used.
> > > > >
> > > > > typedef void * rte_rcu_qsbr_t;
> > > > > typedef void * rte_hash_t;
> > > > >
> > > > > But it requires typecasting.
> > > > >
> > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > >
> > > > C allows structure to be defined without knowing what is in it
> > therefore.
> > > >
> > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > >
> > > > is preferred (or do it without typedef)
> > > >
> > > > struct rte_rcu_qsbr;
> > >
> > > I see that rte_hash library uses the same approach (struct rte_hash in
> > rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> > [1] seems to be reporting incorrect numbers for this library even though
> > the internal structure is changed.
> > >
> > > [1]
> > > https://abi-
> > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > 2&v2=current&obj=66794&kind=abi
> >
> > The problem is rte_hash structure is exposed as part of ABI in
> > rte_cuckoo_hash.h This was a mistake.
> Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
>
> For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
>
> I converted the inline functions to function calls.
>
> Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash
> data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
>
> Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
> Konstantin, any thoughts on the results?
The fact that function show better result than inline (even for hash) is sort of surprise to me.
Don't have any good explanation off-hand, but the actual numbers for hash test are huge by itself...
In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
and then figure out that no-one using them because they are too slow.
Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
(as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
If we'll find there is no real difference - move it to not-inlined version in 19.08.
It is experimental for now - so could be changed without formal ABI breakage.
Konstantin
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 1:45 0% ` Honnappa Nagarahalli
@ 2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-17 13:39 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
> > > > > > > > > > > >
> > > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > > slower, but you thank me
> > > > > > the first time you have to fix something.
> > > > > > > > > > > >
> > > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > > this (I am yet
> > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > > to consider the performance
> > > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > > all the
> > > > > > inline functions in its path and run a test?
> > > > > > > > > >
> > > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > > not be
> > > > > > inline.
> > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > have
> > > > inline functions (unless we freeze any development in these inline
> > > > functions forever).
> > > > >
> > > > > > > > >
> > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > > more
> > > > sophisticated).
> > > > > > > > > Konstantin
> > > > > > > >
> > > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > >
> > > > > > > > The synchronization logic is all real functions.
> > > > > > >
> > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > https://github.com/urcu/userspace-
> > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > > probably want it to be as fast as possible (I know that main
> > > > > > > speedup should come from the fact that readers don't have to
> > > > > > > wait for writer to finish, but still...)
> > > > > > >
> > > > > > > Konstantin
> > > > > > >
> > > > > >
> > > > > > Having locking functions inline is already a problem in current
> > releases.
> > > > > > The implementation can not be improved without breaking ABI (or
> > > > > > doing special workarounds like lock v2)
> > > > > I think ABI and inline function discussion needs to be taken up in
> > > > > a
> > > > different thread.
> > > > >
> > > > > Currently, I am looking to hide the structure visibility. I looked
> > > > > at your
> > > > patch [1], it is a different case than what I have in this patch. It
> > > > is a pretty generic use case as well (similar situation exists in
> > > > other libraries). I think a generic solution should be agreed upon.
> > > > >
> > > > > If we have to hide the structure content, the handle to QS
> > > > > variable
> > > > returned to the application needs to be opaque. I suggest using 'void *'
> > > > behind which any structure can be used.
> > > > >
> > > > > typedef void * rte_rcu_qsbr_t;
> > > > > typedef void * rte_hash_t;
> > > > >
> > > > > But it requires typecasting.
> > > > >
> > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > >
> > > > C allows structure to be defined without knowing what is in it
> > therefore.
> > > >
> > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > >
> > > > is preferred (or do it without typedef)
> > > >
> > > > struct rte_rcu_qsbr;
> > >
> > > I see that rte_hash library uses the same approach (struct rte_hash in
> > rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> > [1] seems to be reporting incorrect numbers for this library even though
> > the internal structure is changed.
> > >
> > > [1]
> > > https://abi-
> > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > 2&v2=current&obj=66794&kind=abi
> >
> > The problem is rte_hash structure is exposed as part of ABI in
> > rte_cuckoo_hash.h This was a mistake.
> Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
>
> For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
>
> I converted the inline functions to function calls.
>
> Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash
> data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
>
> Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
> Konstantin, any thoughts on the results?
The fact that function show better result than inline (even for hash) is sort of surprise to me.
Don't have any good explanation off-hand, but the actual numbers for hash test are huge by itself...
In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
and then figure out that no-one using them because they are too slow.
Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
(as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
If we'll find there is no real difference - move it to not-inlined version in 19.08.
It is experimental for now - so could be changed without formal ABI breakage.
Konstantin
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 9% ` Bruce Richardson
@ 2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-17 8:36 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> Hello,
> There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
>
Thanks for kicking off this discussion
> 1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
I agree that in some cases the application "might" need to be recompiled,
but on the other hand I also think that there are many cases where ABI
function versioning can still be used to mitigate things. For example, if
we think of a couple of various scenarios:
1. If everything is inline and variables are allocated by app, e.g.
spinlock on stack, then there is no issue as everything is application
contained.
2. If the situation is as in #1, but the structures in question are passed
to non-inline DPDK functions. In this case, any changes to the structures
require those functions taking the structures to be versioned for old and
new structures
3. If instead we have the case, like in rte_ring, where the data structures
are allocated using functions, but they are used via inlines in the app. In
this case the creation functions (and any other function using the
structures) need to be versioned so that the application gets the expected
structure back from the creation.
It might be useful to think of what other scenarios we have and what ones
are likely to be problematic, especially those that can't be solved by
having multiple function versions.
> 2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
Agree with this. Anything not data path should not be inline. The next
question then is for data path items how to determine whether they need to
be inline or not. In general my rule-of-thumb:
* anything dealing with bursts of packets should not be inline
* anything what works with single packet at a time should be inline
The one exception to this rule is cases where we have to consider "empty
polling" as a likely use-case. For example, rte_ring_dequeue_burst works
with bursts of packets, but there is a valid application use case where a
thread could be polling a set of rings where only a small number are
actually busy. Right now, polling an empty ring only costs a few cycles,
meaning that it's neglible to have a few polls of empty rings before you
get to a busy one. Having that function not-inline will cause that cost to
jump significantly, so could cause problems. (This leads to the interesting
scenario where ring enqueue is safe to un-inline, while dequeue is not).
> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
>
In general I believe the synchronisation primitives should be inline.
However, it does come down to cost too - if a function takes 300 cycles, do
we really care if it takes 305 or 310 instead to make it not inline?
Hopefully most synchronisation primitives are faster than this so this
situation should not occur.
> 2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
>
> Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
>
I disagree. I think even in the case of #1, we should be able to manage
some changes without breaking ABI.
> In this context, does it make sense to say that we will maintain API
> compatibility rather than saying ABI compatibility? This will also send
> the right message to the end users.
>
I would value ABI compatibility much higher than API compatibility. If
someone is recompiling the application anyway, making a couple of small
changes (large rework is obviously a different issue) to the code should
not be a massive issue, I hope. On the other hand, ABI compatibility is
needed to allow seamless update from one version to another, and it's that
ABI compatiblity that allows distro's to pick up our latest and greatest
versions.
Personally, I'd be happy enough to allow API changes at any point without
deprecation notice, so long as function versioning is used to ensure ABI
compatibility is kept.
My 2c.
/Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 5:12 9% [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
@ 2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: Bruce Richardson @ 2019-04-17 8:36 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> Hello,
> There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
>
Thanks for kicking off this discussion
> 1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
I agree that in some cases the application "might" need to be recompiled,
but on the other hand I also think that there are many cases where ABI
function versioning can still be used to mitigate things. For example, if
we think of a couple of various scenarios:
1. If everything is inline and variables are allocated by app, e.g.
spinlock on stack, then there is no issue as everything is application
contained.
2. If the situation is as in #1, but the structures in question are passed
to non-inline DPDK functions. In this case, any changes to the structures
require those functions taking the structures to be versioned for old and
new structures
3. If instead we have the case, like in rte_ring, where the data structures
are allocated using functions, but they are used via inlines in the app. In
this case the creation functions (and any other function using the
structures) need to be versioned so that the application gets the expected
structure back from the creation.
It might be useful to think of what other scenarios we have and what ones
are likely to be problematic, especially those that can't be solved by
having multiple function versions.
> 2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
Agree with this. Anything not data path should not be inline. The next
question then is for data path items how to determine whether they need to
be inline or not. In general my rule-of-thumb:
* anything dealing with bursts of packets should not be inline
* anything what works with single packet at a time should be inline
The one exception to this rule is cases where we have to consider "empty
polling" as a likely use-case. For example, rte_ring_dequeue_burst works
with bursts of packets, but there is a valid application use case where a
thread could be polling a set of rings where only a small number are
actually busy. Right now, polling an empty ring only costs a few cycles,
meaning that it's neglible to have a few polls of empty rings before you
get to a busy one. Having that function not-inline will cause that cost to
jump significantly, so could cause problems. (This leads to the interesting
scenario where ring enqueue is safe to un-inline, while dequeue is not).
> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
>
In general I believe the synchronisation primitives should be inline.
However, it does come down to cost too - if a function takes 300 cycles, do
we really care if it takes 305 or 310 instead to make it not inline?
Hopefully most synchronisation primitives are faster than this so this
situation should not occur.
> 2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
>
> Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
>
I disagree. I think even in the case of #1, we should be able to manage
some changes without breaking ABI.
> In this context, does it make sense to say that we will maintain API
> compatibility rather than saying ABI compatibility? This will also send
> the right message to the end users.
>
I would value ABI compatibility much higher than API compatibility. If
someone is recompiling the application anyway, making a couple of small
changes (large rework is obviously a different issue) to the code should
not be a massive issue, I hope. On the other hand, ABI compatibility is
needed to allow seamless update from one version to another, and it's that
ABI compatiblity that allows distro's to pick up our latest and greatest
versions.
Personally, I'd be happy enough to allow API changes at any point without
deprecation notice, so long as function versioning is used to ensure ABI
compatibility is kept.
My 2c.
/Bruce
^ permalink raw reply [relevance 9%]
* [dpdk-dev] ABI and inline functions
2019-04-17 5:12 9% [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
@ 2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 9% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 5:12 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ananyev, Konstantin; +Cc: thomas, Ray Kinsella, nd, nd
Hello,
There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
In this context, does it make sense to say that we will maintain API compatibility rather than saying ABI compatibility? This will also send the right message to the end users.
Thank you,
Honnappa
[1] http://mails.dpdk.org/archives/dev/2019-April/130151.html
^ permalink raw reply [relevance 9%]
* [dpdk-dev] ABI and inline functions
@ 2019-04-17 5:12 9% Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 9% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 5:12 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ananyev, Konstantin; +Cc: thomas, Ray Kinsella, nd, nd
Hello,
There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
In this context, does it make sense to say that we will maintain API compatibility rather than saying ABI compatibility? This will also send the right message to the end users.
Thank you,
Honnappa
[1] http://mails.dpdk.org/archives/dev/2019-April/130151.html
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 1:45 0% ` Honnappa Nagarahalli
@ 2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 13:39 3% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 1:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > >
> > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > slower, but you thank me
> > > > > the first time you have to fix something.
> > > > > > > > > > >
> > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > this (I am yet
> > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > to consider the performance
> > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > all the
> > > > > inline functions in its path and run a test?
> > > > > > > > >
> > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > not be
> > > > > inline.
> > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > have
> > > inline functions (unless we freeze any development in these inline
> > > functions forever).
> > > >
> > > > > > > >
> > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > more
> > > sophisticated).
> > > > > > > > Konstantin
> > > > > > >
> > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > rcu_reference/rcu_assign_pointer.
> > > > > > >
> > > > > > > The synchronization logic is all real functions.
> > > > > >
> > > > > > In fact, I think urcu provides both flavors:
> > > > > > https://github.com/urcu/userspace-
> > > > > rcu/blob/master/include/urcu/static/
> > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > probably want it to be as fast as possible (I know that main
> > > > > > speedup should come from the fact that readers don't have to
> > > > > > wait for writer to finish, but still...)
> > > > > >
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > Having locking functions inline is already a problem in current
> releases.
> > > > > The implementation can not be improved without breaking ABI (or
> > > > > doing special workarounds like lock v2)
> > > > I think ABI and inline function discussion needs to be taken up in
> > > > a
> > > different thread.
> > > >
> > > > Currently, I am looking to hide the structure visibility. I looked
> > > > at your
> > > patch [1], it is a different case than what I have in this patch. It
> > > is a pretty generic use case as well (similar situation exists in
> > > other libraries). I think a generic solution should be agreed upon.
> > > >
> > > > If we have to hide the structure content, the handle to QS
> > > > variable
> > > returned to the application needs to be opaque. I suggest using 'void *'
> > > behind which any structure can be used.
> > > >
> > > > typedef void * rte_rcu_qsbr_t;
> > > > typedef void * rte_hash_t;
> > > >
> > > > But it requires typecasting.
> > > >
> > > > [1] http://patchwork.dpdk.org/cover/52609/
> > >
> > > C allows structure to be defined without knowing what is in it
> therefore.
> > >
> > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > >
> > > is preferred (or do it without typedef)
> > >
> > > struct rte_rcu_qsbr;
> >
> > I see that rte_hash library uses the same approach (struct rte_hash in
> rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> [1] seems to be reporting incorrect numbers for this library even though
> the internal structure is changed.
> >
> > [1]
> > https://abi-
> laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > 2&v2=current&obj=66794&kind=abi
>
> The problem is rte_hash structure is exposed as part of ABI in
> rte_cuckoo_hash.h This was a mistake.
Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to include rte_cuckoo_hash.h.
For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure while having inline functions.
I converted the inline functions to function calls.
Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
Konstantin, any thoughts on the results?
I will send out V6 which will fix issues reported so far. The function vs inline part is still open, need to close it soon.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-16 21:22 3% ` Stephen Hemminger
@ 2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 13:39 3% ` Ananyev, Konstantin
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 1:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > >
> > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > slower, but you thank me
> > > > > the first time you have to fix something.
> > > > > > > > > > >
> > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > this (I am yet
> > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > to consider the performance
> > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > all the
> > > > > inline functions in its path and run a test?
> > > > > > > > >
> > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > not be
> > > > > inline.
> > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > have
> > > inline functions (unless we freeze any development in these inline
> > > functions forever).
> > > >
> > > > > > > >
> > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > more
> > > sophisticated).
> > > > > > > > Konstantin
> > > > > > >
> > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > rcu_reference/rcu_assign_pointer.
> > > > > > >
> > > > > > > The synchronization logic is all real functions.
> > > > > >
> > > > > > In fact, I think urcu provides both flavors:
> > > > > > https://github.com/urcu/userspace-
> > > > > rcu/blob/master/include/urcu/static/
> > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > probably want it to be as fast as possible (I know that main
> > > > > > speedup should come from the fact that readers don't have to
> > > > > > wait for writer to finish, but still...)
> > > > > >
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > Having locking functions inline is already a problem in current
> releases.
> > > > > The implementation can not be improved without breaking ABI (or
> > > > > doing special workarounds like lock v2)
> > > > I think ABI and inline function discussion needs to be taken up in
> > > > a
> > > different thread.
> > > >
> > > > Currently, I am looking to hide the structure visibility. I looked
> > > > at your
> > > patch [1], it is a different case than what I have in this patch. It
> > > is a pretty generic use case as well (similar situation exists in
> > > other libraries). I think a generic solution should be agreed upon.
> > > >
> > > > If we have to hide the structure content, the handle to QS
> > > > variable
> > > returned to the application needs to be opaque. I suggest using 'void *'
> > > behind which any structure can be used.
> > > >
> > > > typedef void * rte_rcu_qsbr_t;
> > > > typedef void * rte_hash_t;
> > > >
> > > > But it requires typecasting.
> > > >
> > > > [1] http://patchwork.dpdk.org/cover/52609/
> > >
> > > C allows structure to be defined without knowing what is in it
> therefore.
> > >
> > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > >
> > > is preferred (or do it without typedef)
> > >
> > > struct rte_rcu_qsbr;
> >
> > I see that rte_hash library uses the same approach (struct rte_hash in
> rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> [1] seems to be reporting incorrect numbers for this library even though
> the internal structure is changed.
> >
> > [1]
> > https://abi-
> laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > 2&v2=current&obj=66794&kind=abi
>
> The problem is rte_hash structure is exposed as part of ABI in
> rte_cuckoo_hash.h This was a mistake.
Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to include rte_cuckoo_hash.h.
For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure while having inline functions.
I converted the inline functions to function calls.
Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
Konstantin, any thoughts on the results?
I will send out V6 which will fix issues reported so far. The function vs inline part is still open, need to close it soon.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 21:22 3% ` Stephen Hemminger
@ 2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-17 1:45 0% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 21:22 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 16:56:32 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > > memory reclamation
> > > > > > > > > > method.
> > > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > > >
> > > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > > thank me
> > > > the first time you have to fix something.
> > > > > > > > > >
> > > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > > (I am yet
> > > > to take a look at your patch addressing the ABI).
> > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > > consider the performance
> > > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > > the
> > > > inline functions in its path and run a test?
> > > > > > > >
> > > > > > > > Every function that is not in the direct datapath should not
> > > > > > > > be
> > > > inline.
> > > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > > and packet alloc/free
> > > I do not understand how DPDK can claim ABI compatibility if we have
> > inline functions (unless we freeze any development in these inline functions
> > forever).
> > >
> > > > > > >
> > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > another synchronization mechanism after all (just a bit more
> > sophisticated).
> > > > > > > Konstantin
> > > > > >
> > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > rcu_reference/rcu_assign_pointer.
> > > > > >
> > > > > > The synchronization logic is all real functions.
> > > > >
> > > > > In fact, I think urcu provides both flavors:
> > > > > https://github.com/urcu/userspace-
> > > > rcu/blob/master/include/urcu/static/
> > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > If we gone all the way to create our own version of rcu, we
> > > > > probably want it to be as fast as possible (I know that main
> > > > > speedup should come from the fact that readers don't have to wait
> > > > > for writer to finish, but still...)
> > > > >
> > > > > Konstantin
> > > > >
> > > >
> > > > Having locking functions inline is already a problem in current releases.
> > > > The implementation can not be improved without breaking ABI (or
> > > > doing special workarounds like lock v2)
> > > I think ABI and inline function discussion needs to be taken up in a
> > different thread.
> > >
> > > Currently, I am looking to hide the structure visibility. I looked at your
> > patch [1], it is a different case than what I have in this patch. It is a pretty
> > generic use case as well (similar situation exists in other libraries). I think a
> > generic solution should be agreed upon.
> > >
> > > If we have to hide the structure content, the handle to QS variable
> > returned to the application needs to be opaque. I suggest using 'void *'
> > behind which any structure can be used.
> > >
> > > typedef void * rte_rcu_qsbr_t;
> > > typedef void * rte_hash_t;
> > >
> > > But it requires typecasting.
> > >
> > > [1] http://patchwork.dpdk.org/cover/52609/
> >
> > C allows structure to be defined without knowing what is in it therefore.
> >
> > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> >
> > is preferred (or do it without typedef)
> >
> > struct rte_rcu_qsbr;
>
> I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
>
> [1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
The problem is rte_hash structure is exposed as part of ABI in rte_cuckoo_hash.h
This was a mistake.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 16:56 4% ` Honnappa Nagarahalli
@ 2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-17 1:45 0% ` Honnappa Nagarahalli
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 21:22 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 16:56:32 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > > memory reclamation
> > > > > > > > > > method.
> > > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > > >
> > > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > > thank me
> > > > the first time you have to fix something.
> > > > > > > > > >
> > > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > > (I am yet
> > > > to take a look at your patch addressing the ABI).
> > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > > consider the performance
> > > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > > the
> > > > inline functions in its path and run a test?
> > > > > > > >
> > > > > > > > Every function that is not in the direct datapath should not
> > > > > > > > be
> > > > inline.
> > > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > > and packet alloc/free
> > > I do not understand how DPDK can claim ABI compatibility if we have
> > inline functions (unless we freeze any development in these inline functions
> > forever).
> > >
> > > > > > >
> > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > another synchronization mechanism after all (just a bit more
> > sophisticated).
> > > > > > > Konstantin
> > > > > >
> > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > rcu_reference/rcu_assign_pointer.
> > > > > >
> > > > > > The synchronization logic is all real functions.
> > > > >
> > > > > In fact, I think urcu provides both flavors:
> > > > > https://github.com/urcu/userspace-
> > > > rcu/blob/master/include/urcu/static/
> > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > If we gone all the way to create our own version of rcu, we
> > > > > probably want it to be as fast as possible (I know that main
> > > > > speedup should come from the fact that readers don't have to wait
> > > > > for writer to finish, but still...)
> > > > >
> > > > > Konstantin
> > > > >
> > > >
> > > > Having locking functions inline is already a problem in current releases.
> > > > The implementation can not be improved without breaking ABI (or
> > > > doing special workarounds like lock v2)
> > > I think ABI and inline function discussion needs to be taken up in a
> > different thread.
> > >
> > > Currently, I am looking to hide the structure visibility. I looked at your
> > patch [1], it is a different case than what I have in this patch. It is a pretty
> > generic use case as well (similar situation exists in other libraries). I think a
> > generic solution should be agreed upon.
> > >
> > > If we have to hide the structure content, the handle to QS variable
> > returned to the application needs to be opaque. I suggest using 'void *'
> > behind which any structure can be used.
> > >
> > > typedef void * rte_rcu_qsbr_t;
> > > typedef void * rte_hash_t;
> > >
> > > But it requires typecasting.
> > >
> > > [1] http://patchwork.dpdk.org/cover/52609/
> >
> > C allows structure to be defined without knowing what is in it therefore.
> >
> > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> >
> > is preferred (or do it without typedef)
> >
> > struct rte_rcu_qsbr;
>
> I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
>
> [1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
The problem is rte_hash structure is exposed as part of ABI in rte_cuckoo_hash.h
This was a mistake.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 16:56 4% ` Honnappa Nagarahalli
@ 2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 21:22 3% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 16:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
>
> > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > >
> > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > memory reclamation
> > > > > > > > > method.
> > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > >
> > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > thank me
> > > the first time you have to fix something.
> > > > > > > > >
> > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > (I am yet
> > > to take a look at your patch addressing the ABI).
> > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > consider the performance
> > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > the
> > > inline functions in its path and run a test?
> > > > > > >
> > > > > > > Every function that is not in the direct datapath should not
> > > > > > > be
> > > inline.
> > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > and packet alloc/free
> > I do not understand how DPDK can claim ABI compatibility if we have
> inline functions (unless we freeze any development in these inline functions
> forever).
> >
> > > > > >
> > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > another synchronization mechanism after all (just a bit more
> sophisticated).
> > > > > > Konstantin
> > > > >
> > > > > If you look at the other userspace RCU, you wil see that the
> > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > rcu_reference/rcu_assign_pointer.
> > > > >
> > > > > The synchronization logic is all real functions.
> > > >
> > > > In fact, I think urcu provides both flavors:
> > > > https://github.com/urcu/userspace-
> > > rcu/blob/master/include/urcu/static/
> > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > If we gone all the way to create our own version of rcu, we
> > > > probably want it to be as fast as possible (I know that main
> > > > speedup should come from the fact that readers don't have to wait
> > > > for writer to finish, but still...)
> > > >
> > > > Konstantin
> > > >
> > >
> > > Having locking functions inline is already a problem in current releases.
> > > The implementation can not be improved without breaking ABI (or
> > > doing special workarounds like lock v2)
> > I think ABI and inline function discussion needs to be taken up in a
> different thread.
> >
> > Currently, I am looking to hide the structure visibility. I looked at your
> patch [1], it is a different case than what I have in this patch. It is a pretty
> generic use case as well (similar situation exists in other libraries). I think a
> generic solution should be agreed upon.
> >
> > If we have to hide the structure content, the handle to QS variable
> returned to the application needs to be opaque. I suggest using 'void *'
> behind which any structure can be used.
> >
> > typedef void * rte_rcu_qsbr_t;
> > typedef void * rte_hash_t;
> >
> > But it requires typecasting.
> >
> > [1] http://patchwork.dpdk.org/cover/52609/
>
> C allows structure to be defined without knowing what is in it therefore.
>
> typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
>
> is preferred (or do it without typedef)
>
> struct rte_rcu_qsbr;
I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
[1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 14:54 0% ` Stephen Hemminger
@ 2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 21:22 3% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 16:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
>
> > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > >
> > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > memory reclamation
> > > > > > > > > method.
> > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > >
> > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > thank me
> > > the first time you have to fix something.
> > > > > > > > >
> > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > (I am yet
> > > to take a look at your patch addressing the ABI).
> > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > consider the performance
> > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > the
> > > inline functions in its path and run a test?
> > > > > > >
> > > > > > > Every function that is not in the direct datapath should not
> > > > > > > be
> > > inline.
> > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > and packet alloc/free
> > I do not understand how DPDK can claim ABI compatibility if we have
> inline functions (unless we freeze any development in these inline functions
> forever).
> >
> > > > > >
> > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > another synchronization mechanism after all (just a bit more
> sophisticated).
> > > > > > Konstantin
> > > > >
> > > > > If you look at the other userspace RCU, you wil see that the
> > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > rcu_reference/rcu_assign_pointer.
> > > > >
> > > > > The synchronization logic is all real functions.
> > > >
> > > > In fact, I think urcu provides both flavors:
> > > > https://github.com/urcu/userspace-
> > > rcu/blob/master/include/urcu/static/
> > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > If we gone all the way to create our own version of rcu, we
> > > > probably want it to be as fast as possible (I know that main
> > > > speedup should come from the fact that readers don't have to wait
> > > > for writer to finish, but still...)
> > > >
> > > > Konstantin
> > > >
> > >
> > > Having locking functions inline is already a problem in current releases.
> > > The implementation can not be improved without breaking ABI (or
> > > doing special workarounds like lock v2)
> > I think ABI and inline function discussion needs to be taken up in a
> different thread.
> >
> > Currently, I am looking to hide the structure visibility. I looked at your
> patch [1], it is a different case than what I have in this patch. It is a pretty
> generic use case as well (similar situation exists in other libraries). I think a
> generic solution should be agreed upon.
> >
> > If we have to hide the structure content, the handle to QS variable
> returned to the application needs to be opaque. I suggest using 'void *'
> behind which any structure can be used.
> >
> > typedef void * rte_rcu_qsbr_t;
> > typedef void * rte_hash_t;
> >
> > But it requires typecasting.
> >
> > [1] http://patchwork.dpdk.org/cover/52609/
>
> C allows structure to be defined without knowing what is in it therefore.
>
> typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
>
> is preferred (or do it without typedef)
>
> struct rte_rcu_qsbr;
I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
[1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 14:54 0% ` Stephen Hemminger
@ 2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 16:56 4% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 14:54 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 05:29:21 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > >
> > > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > > reclamation
> > > > > > > > method.
> > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > associated with the lock less data structures.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > >
> > > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > > to get rid of almost all use of inline and visible
> > > > > > > > structures. Yes it might be marginally slower, but you thank me
> > the first time you have to fix something.
> > > > > > > >
> > > > > > > Agree, I was planning on another version to address this (I am yet
> > to take a look at your patch addressing the ABI).
> > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > > the performance
> > > > > > difference. May be consider L3-fwd application, change all the
> > inline functions in its path and run a test?
> > > > > >
> > > > > > Every function that is not in the direct datapath should not be
> > inline.
> > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > > packet alloc/free
> I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
>
> > > > >
> > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > I think rcu should be one of such exceptions - it is just another
> > > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > > Konstantin
> > > >
> > > > If you look at the other userspace RCU, you wil see that the only
> > > > inlines are the rcu_read_lock,rcu_read_unlock and
> > rcu_reference/rcu_assign_pointer.
> > > >
> > > > The synchronization logic is all real functions.
> > >
> > > In fact, I think urcu provides both flavors:
> > > https://github.com/urcu/userspace-
> > rcu/blob/master/include/urcu/static/
> > > urcu-qsbr.h I still don't understand why we have to treat it
> > > differently then let say spin-lock/ticket-lock or rwlock.
> > > If we gone all the way to create our own version of rcu, we probably
> > > want it to be as fast as possible (I know that main speedup should
> > > come from the fact that readers don't have to wait for writer to
> > > finish, but still...)
> > >
> > > Konstantin
> > >
> >
> > Having locking functions inline is already a problem in current releases.
> > The implementation can not be improved without breaking ABI (or doing
> > special workarounds like lock v2)
> I think ABI and inline function discussion needs to be taken up in a different thread.
>
> Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
>
> If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
>
> typedef void * rte_rcu_qsbr_t;
> typedef void * rte_hash_t;
>
> But it requires typecasting.
>
> [1] http://patchwork.dpdk.org/cover/52609/
C allows structure to be defined without knowing what is in it
therefore.
typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
is preferred (or do it without typedef)
struct rte_rcu_qsbr;
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 5:29 4% ` Honnappa Nagarahalli
@ 2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 16:56 4% ` Honnappa Nagarahalli
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 14:54 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 05:29:21 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > >
> > > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > > reclamation
> > > > > > > > method.
> > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > associated with the lock less data structures.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > >
> > > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > > to get rid of almost all use of inline and visible
> > > > > > > > structures. Yes it might be marginally slower, but you thank me
> > the first time you have to fix something.
> > > > > > > >
> > > > > > > Agree, I was planning on another version to address this (I am yet
> > to take a look at your patch addressing the ABI).
> > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > > the performance
> > > > > > difference. May be consider L3-fwd application, change all the
> > inline functions in its path and run a test?
> > > > > >
> > > > > > Every function that is not in the direct datapath should not be
> > inline.
> > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > > packet alloc/free
> I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
>
> > > > >
> > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > I think rcu should be one of such exceptions - it is just another
> > > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > > Konstantin
> > > >
> > > > If you look at the other userspace RCU, you wil see that the only
> > > > inlines are the rcu_read_lock,rcu_read_unlock and
> > rcu_reference/rcu_assign_pointer.
> > > >
> > > > The synchronization logic is all real functions.
> > >
> > > In fact, I think urcu provides both flavors:
> > > https://github.com/urcu/userspace-
> > rcu/blob/master/include/urcu/static/
> > > urcu-qsbr.h I still don't understand why we have to treat it
> > > differently then let say spin-lock/ticket-lock or rwlock.
> > > If we gone all the way to create our own version of rcu, we probably
> > > want it to be as fast as possible (I know that main speedup should
> > > come from the fact that readers don't have to wait for writer to
> > > finish, but still...)
> > >
> > > Konstantin
> > >
> >
> > Having locking functions inline is already a problem in current releases.
> > The implementation can not be improved without breaking ABI (or doing
> > special workarounds like lock v2)
> I think ABI and inline function discussion needs to be taken up in a different thread.
>
> Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
>
> If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
>
> typedef void * rte_rcu_qsbr_t;
> typedef void * rte_hash_t;
>
> But it requires typecasting.
>
> [1] http://patchwork.dpdk.org/cover/52609/
C allows structure to be defined without knowing what is in it
therefore.
typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
is preferred (or do it without typedef)
struct rte_rcu_qsbr;
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 10:19 0% ` Igor Russkikh
@ 2019-04-16 10:19 0% ` Igor Russkikh
0 siblings, 0 replies; 200+ results
From: Igor Russkikh @ 2019-04-16 10:19 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko
Cc: Ferruh Yigit, dev, Pavel Belous, Wenzhuo Lu, Jingjing Wu,
Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
>>>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>>>> other possible driver can use it, I am for postponing the series to next release.
>>>>>
>>>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>>>> to late in release cycle without proper review.
>>>> I see, that's reasonable.
>>>>
>>>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>>>> Two points here:
>>>>
>>>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>>>> through the rte_security set of APIs. This obviously could be done, but with proper design
>>>> of rte_security structures and ops.
>>>>
>>>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>>>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>>>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>>>
>>> If there is a commitment to work on a generic solution for 19.08, involving
>>> other users too, I would be OK to get the support as PMD API for this release.
>>>
>>> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
>>> even add to release notes about intention and that the PMD specific APIs are
>>> temporary. And if ABI breakage required, put any necessary deprecation notice
>>> withing this release scope so that the development is not blocked for next release.
>>>
>>> Thomas, Andrew, what do you think?
>>
>> I agree.
>
> +1
Great, I'll prepare v2 patchset then. Will also start on prototyping possible
rte_security macsec API.
Regards,
Igor
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
@ 2019-04-16 10:19 0% ` Igor Russkikh
2019-04-16 10:19 0% ` Igor Russkikh
1 sibling, 1 reply; 200+ results
From: Igor Russkikh @ 2019-04-16 10:19 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko
Cc: Ferruh Yigit, dev, Pavel Belous, Wenzhuo Lu, Jingjing Wu,
Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
>>>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>>>> other possible driver can use it, I am for postponing the series to next release.
>>>>>
>>>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>>>> to late in release cycle without proper review.
>>>> I see, that's reasonable.
>>>>
>>>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>>>> Two points here:
>>>>
>>>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>>>> through the rte_security set of APIs. This obviously could be done, but with proper design
>>>> of rte_security structures and ops.
>>>>
>>>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>>>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>>>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>>>
>>> If there is a commitment to work on a generic solution for 19.08, involving
>>> other users too, I would be OK to get the support as PMD API for this release.
>>>
>>> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
>>> even add to release notes about intention and that the PMD specific APIs are
>>> temporary. And if ABI breakage required, put any necessary deprecation notice
>>> withing this release scope so that the development is not blocked for next release.
>>>
>>> Thomas, Andrew, what do you think?
>>
>> I agree.
>
> +1
Great, I'll prepare v2 patchset then. Will also start on prototyping possible
rte_security macsec API.
Regards,
Igor
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 10:11 0% ` Thomas Monjalon
@ 2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-16 10:11 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Ferruh Yigit, Igor Russkikh, dev, Pavel Belous, Wenzhuo Lu,
Jingjing Wu, Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
16/04/2019 11:58, Andrew Rybchenko:
> On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> > On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> >> Hi Ferruh,
> >>
> >>>> +int
> >>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
> >>>> + uint8_t idx, uint8_t an,
> >>>> + uint32_t pn, uint8_t *key);
> >>>> +
> >>>>
> >>>> #include <rte_ethdev_core.h>
> >>>>
> >>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
> >>> these didn't go through a proper review cycle, we didn't get any comment on any
> >>> other possible driver can use it, I am for postponing the series to next release.
> >>>
> >>> Also there are some mechanical issues [1] but main thing is adding a set of API
> >>> to late in release cycle without proper review.
> >> I see, that's reasonable.
> >>
> >> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> >> Two points here:
> >>
> >> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> >> through the rte_security set of APIs. This obviously could be done, but with proper design
> >> of rte_security structures and ops.
> >>
> >> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> >> of private driver API as it runs in ixgbe now. This code is functional and will not be
> >> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
> >>
> > If there is a commitment to work on a generic solution for 19.08, involving
> > other users too, I would be OK to get the support as PMD API for this release.
> >
> > If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> > even add to release notes about intention and that the PMD specific APIs are
> > temporary. And if ABI breakage required, put any necessary deprecation notice
> > withing this release scope so that the development is not blocked for next release.
> >
> > Thomas, Andrew, what do you think?
>
> I agree.
+1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
@ 2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-16 10:11 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Ferruh Yigit, Igor Russkikh, dev, Pavel Belous, Wenzhuo Lu,
Jingjing Wu, Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
16/04/2019 11:58, Andrew Rybchenko:
> On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> > On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> >> Hi Ferruh,
> >>
> >>>> +int
> >>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
> >>>> + uint8_t idx, uint8_t an,
> >>>> + uint32_t pn, uint8_t *key);
> >>>> +
> >>>>
> >>>> #include <rte_ethdev_core.h>
> >>>>
> >>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
> >>> these didn't go through a proper review cycle, we didn't get any comment on any
> >>> other possible driver can use it, I am for postponing the series to next release.
> >>>
> >>> Also there are some mechanical issues [1] but main thing is adding a set of API
> >>> to late in release cycle without proper review.
> >> I see, that's reasonable.
> >>
> >> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> >> Two points here:
> >>
> >> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> >> through the rte_security set of APIs. This obviously could be done, but with proper design
> >> of rte_security structures and ops.
> >>
> >> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> >> of private driver API as it runs in ixgbe now. This code is functional and will not be
> >> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
> >>
> > If there is a commitment to work on a generic solution for 19.08, involving
> > other users too, I would be OK to get the support as PMD API for this release.
> >
> > If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> > even add to release notes about intention and that the PMD specific APIs are
> > temporary. And if ABI breakage required, put any necessary deprecation notice
> > withing this release scope so that the development is not blocked for next release.
> >
> > Thomas, Andrew, what do you think?
>
> I agree.
+1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:58 0% ` Andrew Rybchenko
@ 2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-04-16 9:58 UTC (permalink / raw)
To: Ferruh Yigit, Igor Russkikh, dev, Thomas Monjalon
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> On 4/13/2019 8:24 AM, Igor Russkikh wrote:
>> Hi Ferruh,
>>
>>>> +int
>>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>>> + uint8_t idx, uint8_t an,
>>>> + uint32_t pn, uint8_t *key);
>>>> +
>>>>
>>>> #include <rte_ethdev_core.h>
>>>>
>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>> other possible driver can use it, I am for postponing the series to next release.
>>>
>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>> to late in release cycle without proper review.
>> I see, that's reasonable.
>>
>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>> Two points here:
>>
>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>> through the rte_security set of APIs. This obviously could be done, but with proper design
>> of rte_security structures and ops.
>>
>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>
> If there is a commitment to work on a generic solution for 19.08, involving
> other users too, I would be OK to get the support as PMD API for this release.
>
> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> even add to release notes about intention and that the PMD specific APIs are
> temporary. And if ABI breakage required, put any necessary deprecation notice
> withing this release scope so that the development is not blocked for next release.
>
> Thomas, Andrew, what do you think?
I agree.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
@ 2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Andrew Rybchenko @ 2019-04-16 9:58 UTC (permalink / raw)
To: Ferruh Yigit, Igor Russkikh, dev, Thomas Monjalon
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> On 4/13/2019 8:24 AM, Igor Russkikh wrote:
>> Hi Ferruh,
>>
>>>> +int
>>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>>> + uint8_t idx, uint8_t an,
>>>> + uint32_t pn, uint8_t *key);
>>>> +
>>>>
>>>> #include <rte_ethdev_core.h>
>>>>
>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>> other possible driver can use it, I am for postponing the series to next release.
>>>
>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>> to late in release cycle without proper review.
>> I see, that's reasonable.
>>
>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>> Two points here:
>>
>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>> through the rte_security set of APIs. This obviously could be done, but with proper design
>> of rte_security structures and ops.
>>
>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>
> If there is a commitment to work on a generic solution for 19.08, involving
> other users too, I would be OK to get the support as PMD API for this release.
>
> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> even add to release notes about intention and that the PMD specific APIs are
> temporary. And if ABI breakage required, put any necessary deprecation notice
> withing this release scope so that the development is not blocked for next release.
>
> Thomas, Andrew, what do you think?
I agree.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:43 3% ` Ferruh Yigit
@ 2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-16 9:43 UTC (permalink / raw)
To: Igor Russkikh, dev, Thomas Monjalon, Andrew Rybchenko
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> Hi Ferruh,
>
>>> +int
>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>> + uint8_t idx, uint8_t an,
>>> + uint32_t pn, uint8_t *key);
>>> +
>>>
>>> #include <rte_ethdev_core.h>
>>>
>>
>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>> these didn't go through a proper review cycle, we didn't get any comment on any
>> other possible driver can use it, I am for postponing the series to next release.
>>
>> Also there are some mechanical issues [1] but main thing is adding a set of API
>> to late in release cycle without proper review.
>
> I see, that's reasonable.
>
> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> Two points here:
>
> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> through the rte_security set of APIs. This obviously could be done, but with proper design
> of rte_security structures and ops.
>
> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> of private driver API as it runs in ixgbe now. This code is functional and will not be
> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>
If there is a commitment to work on a generic solution for 19.08, involving
other users too, I would be OK to get the support as PMD API for this release.
If that is accepted, please bu sure too add experimental tag to new PMD APIs and
even add to release notes about intention and that the PMD specific APIs are
temporary. And if ABI breakage required, put any necessary deprecation notice
withing this release scope so that the development is not blocked for next release.
Thomas, Andrew, what do you think?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
@ 2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-16 9:43 UTC (permalink / raw)
To: Igor Russkikh, dev, Thomas Monjalon, Andrew Rybchenko
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> Hi Ferruh,
>
>>> +int
>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>> + uint8_t idx, uint8_t an,
>>> + uint32_t pn, uint8_t *key);
>>> +
>>>
>>> #include <rte_ethdev_core.h>
>>>
>>
>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>> these didn't go through a proper review cycle, we didn't get any comment on any
>> other possible driver can use it, I am for postponing the series to next release.
>>
>> Also there are some mechanical issues [1] but main thing is adding a set of API
>> to late in release cycle without proper review.
>
> I see, that's reasonable.
>
> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> Two points here:
>
> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> through the rte_security set of APIs. This obviously could be done, but with proper design
> of rte_security structures and ops.
>
> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> of private driver API as it runs in ixgbe now. This code is functional and will not be
> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>
If there is a commitment to work on a generic solution for 19.08, involving
other users too, I would be OK to get the support as PMD API for this release.
If that is accepted, please bu sure too add experimental tag to new PMD APIs and
even add to release notes about intention and that the PMD specific APIs are
temporary. And if ABI breakage required, put any necessary deprecation notice
withing this release scope so that the development is not blocked for next release.
Thomas, Andrew, what do you think?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 5:29 4% ` Honnappa Nagarahalli
@ 2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 14:54 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 5:29 UTC (permalink / raw)
To: Stephen Hemminger, Ananyev, Konstantin
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > >
> > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > reclamation
> > > > > > > method.
> > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > associated with the lock less data structures.
> > > > > > > >
> > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > >
> > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > to get rid of almost all use of inline and visible
> > > > > > > structures. Yes it might be marginally slower, but you thank me
> the first time you have to fix something.
> > > > > > >
> > > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > > The structure visibility definitely needs to be addressed.
> > > > > > For the inline functions, is the plan to convert all the
> > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > the performance
> > > > > difference. May be consider L3-fwd application, change all the
> inline functions in its path and run a test?
> > > > >
> > > > > Every function that is not in the direct datapath should not be
> inline.
> > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > packet alloc/free
I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
> > > >
> > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > I think rcu should be one of such exceptions - it is just another
> > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > Konstantin
> > >
> > > If you look at the other userspace RCU, you wil see that the only
> > > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> > >
> > > The synchronization logic is all real functions.
> >
> > In fact, I think urcu provides both flavors:
> > https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/
> > urcu-qsbr.h I still don't understand why we have to treat it
> > differently then let say spin-lock/ticket-lock or rwlock.
> > If we gone all the way to create our own version of rcu, we probably
> > want it to be as fast as possible (I know that main speedup should
> > come from the fact that readers don't have to wait for writer to
> > finish, but still...)
> >
> > Konstantin
> >
>
> Having locking functions inline is already a problem in current releases.
> The implementation can not be improved without breaking ABI (or doing
> special workarounds like lock v2)
I think ABI and inline function discussion needs to be taken up in a different thread.
Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
typedef void * rte_rcu_qsbr_t;
typedef void * rte_hash_t;
But it requires typecasting.
[1] http://patchwork.dpdk.org/cover/52609/
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-15 21:26 3% ` Stephen Hemminger
@ 2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 14:54 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 5:29 UTC (permalink / raw)
To: Stephen Hemminger, Ananyev, Konstantin
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > >
> > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > reclamation
> > > > > > > method.
> > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > associated with the lock less data structures.
> > > > > > > >
> > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > >
> > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > to get rid of almost all use of inline and visible
> > > > > > > structures. Yes it might be marginally slower, but you thank me
> the first time you have to fix something.
> > > > > > >
> > > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > > The structure visibility definitely needs to be addressed.
> > > > > > For the inline functions, is the plan to convert all the
> > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > the performance
> > > > > difference. May be consider L3-fwd application, change all the
> inline functions in its path and run a test?
> > > > >
> > > > > Every function that is not in the direct datapath should not be
> inline.
> > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > packet alloc/free
I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
> > > >
> > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > I think rcu should be one of such exceptions - it is just another
> > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > Konstantin
> > >
> > > If you look at the other userspace RCU, you wil see that the only
> > > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> > >
> > > The synchronization logic is all real functions.
> >
> > In fact, I think urcu provides both flavors:
> > https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/
> > urcu-qsbr.h I still don't understand why we have to treat it
> > differently then let say spin-lock/ticket-lock or rwlock.
> > If we gone all the way to create our own version of rcu, we probably
> > want it to be as fast as possible (I know that main speedup should
> > come from the fact that readers don't have to wait for writer to
> > finish, but still...)
> >
> > Konstantin
> >
>
> Having locking functions inline is already a problem in current releases.
> The implementation can not be improved without breaking ABI (or doing
> special workarounds like lock v2)
I think ABI and inline function discussion needs to be taken up in a different thread.
Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
typedef void * rte_rcu_qsbr_t;
typedef void * rte_hash_t;
But it requires typecasting.
[1] http://patchwork.dpdk.org/cover/52609/
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-15 22:14 0% ` Thomas Monjalon
@ 2019-04-15 22:14 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-15 22:14 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable
05/04/2019 13:22, Neil Horman:
> On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> > Currently, when symbols get promoted from the EXPERIMENTAL section to a
> > stable ABI section, the script complains they should go to the
> > EXPERIMENTAL section.
> >
> > Example:
> > ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> > expected to be added in the EXPERIMENTAL section of the version map
> >
> > This is legit.
> > Moving from a stable ABI to another is also allowed, but must have gone
> > through the proper process.
> >
> > Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
@ 2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-15 22:14 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-15 22:14 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable
05/04/2019 13:22, Neil Horman:
> On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> > Currently, when symbols get promoted from the EXPERIMENTAL section to a
> > stable ABI section, the script complains they should go to the
> > EXPERIMENTAL section.
> >
> > Example:
> > ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> > expected to be added in the EXPERIMENTAL section of the version map
> >
> > This is legit.
> > Moving from a stable ABI to another is also allowed, but must have gone
> > through the proper process.
> >
> > Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 0/2] Timer library changes
2019-04-15 21:41 5% ` [dpdk-dev] [PATCH v5 " Erik Gabriel Carrillo
@ 2019-04-15 21:41 5% ` Erik Gabriel Carrillo
0 siblings, 0 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-04-15 21:41 UTC (permalink / raw)
To: rsanford, thomas; +Cc: dev
This patch series modifies the timer library in such a way that
structures that used to be statically allocated in a process's data
segment are now allocated in shared memory. As these structures contain
lists of timers, new APIs are introduced that allow a caller to specify
the particular structure instance into which a timer should be inserted
or from which a timer should be removed. This enables primary and
secondary processes to modify the same timer list, which enables some
multi-process use cases that were not previously possible; e.g. a
secondary process can start a timer whose expiration is detected in a
primary process running a new flavor of timer_manage().
The original library API is mostly unchanged, though implementations are
updated to call into newly added functions with a default structure
instance ID that provides the original behavior. New functions are
introduced to enable applications to allocate structure instances to
house timer lists, and to reference them with an identifier when
starting and stopping timers, and finally, to manage the timer lists
referenced with an identifier.
My initial performance testing with the "timer_perf_autotest" test shows
no performance regression or improvement, and inspection of the
generated optimized code shows that the extra function call gets inlined
in the functions that now have an extra function call.
Changes in v5:
- define default_data_id as const (Robert)
- modify for-loop control in rte_timer_alt_manage and
rte_timer_stop_all (Robert)
- change parameter type in rte_timer_alt_manage_cb_t from "void *" to
"struct rte_timer *" (Robert)
Changes in v4:
- Updated versioned symbols so that they correspond to the next
release. Checked ABI compatibility again with validate-abi.sh.
Changes in v3:
- remove C++ style comment in first patch in series (Stephen)
Changes in v2:
- split these changes out into their own series
- version the symbols where the existing ABI was updated, and
provide alternate implementation with behavior equivalent to original
behavior. Validated ABI compatibility with validate-abi.sh
- refactor changes to simplify patches
Erik Gabriel Carrillo (2):
timer: allow timer management in shared memory
timer: add function to stop all timers in a list
lib/librte_timer/Makefile | 1 +
lib/librte_timer/rte_timer.c | 557 ++++++++++++++++++++++++++++++---
lib/librte_timer/rte_timer.h | 258 ++++++++++++++-
lib/librte_timer/rte_timer_version.map | 23 ++
4 files changed, 794 insertions(+), 45 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v5 0/2] Timer library changes
@ 2019-04-15 21:41 5% ` Erik Gabriel Carrillo
2019-04-15 21:41 5% ` Erik Gabriel Carrillo
0 siblings, 1 reply; 200+ results
From: Erik Gabriel Carrillo @ 2019-04-15 21:41 UTC (permalink / raw)
To: rsanford, thomas; +Cc: dev
This patch series modifies the timer library in such a way that
structures that used to be statically allocated in a process's data
segment are now allocated in shared memory. As these structures contain
lists of timers, new APIs are introduced that allow a caller to specify
the particular structure instance into which a timer should be inserted
or from which a timer should be removed. This enables primary and
secondary processes to modify the same timer list, which enables some
multi-process use cases that were not previously possible; e.g. a
secondary process can start a timer whose expiration is detected in a
primary process running a new flavor of timer_manage().
The original library API is mostly unchanged, though implementations are
updated to call into newly added functions with a default structure
instance ID that provides the original behavior. New functions are
introduced to enable applications to allocate structure instances to
house timer lists, and to reference them with an identifier when
starting and stopping timers, and finally, to manage the timer lists
referenced with an identifier.
My initial performance testing with the "timer_perf_autotest" test shows
no performance regression or improvement, and inspection of the
generated optimized code shows that the extra function call gets inlined
in the functions that now have an extra function call.
Changes in v5:
- define default_data_id as const (Robert)
- modify for-loop control in rte_timer_alt_manage and
rte_timer_stop_all (Robert)
- change parameter type in rte_timer_alt_manage_cb_t from "void *" to
"struct rte_timer *" (Robert)
Changes in v4:
- Updated versioned symbols so that they correspond to the next
release. Checked ABI compatibility again with validate-abi.sh.
Changes in v3:
- remove C++ style comment in first patch in series (Stephen)
Changes in v2:
- split these changes out into their own series
- version the symbols where the existing ABI was updated, and
provide alternate implementation with behavior equivalent to original
behavior. Validated ABI compatibility with validate-abi.sh
- refactor changes to simplify patches
Erik Gabriel Carrillo (2):
timer: allow timer management in shared memory
timer: add function to stop all timers in a list
lib/librte_timer/Makefile | 1 +
lib/librte_timer/rte_timer.c | 557 ++++++++++++++++++++++++++++++---
lib/librte_timer/rte_timer.h | 258 ++++++++++++++-
lib/librte_timer/rte_timer_version.map | 23 ++
4 files changed, 794 insertions(+), 45 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 21:26 3% ` Stephen Hemminger
@ 2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-16 5:29 4% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 21:26 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 17:39:07 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, April 15, 2019 4:39 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> > <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> > <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Mon, 15 Apr 2019 12:24:47 +0000
> > "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Saturday, April 13, 2019 12:06 AM
> > > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> > Gupta
> > > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > > >
> > > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > >
> > > > > >
> > > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > > >
> > > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > > method.
> > > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > > so that the writers can free the memory associated with the lock less
> > > > > > > data structures.
> > > > > > >
> > > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > > you thank me the first time you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > > (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only inlines
> > are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
> (I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
>
> Konstantin
>
Having locking functions inline is already a problem in current releases.
The implementation can not be improved without breaking ABI (or doing special
workarounds like lock v2)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 18:56 0% ` Honnappa Nagarahalli
@ 2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 21:26 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 17:39:07 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, April 15, 2019 4:39 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> > <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> > <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Mon, 15 Apr 2019 12:24:47 +0000
> > "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Saturday, April 13, 2019 12:06 AM
> > > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> > Gupta
> > > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > > >
> > > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > >
> > > > > >
> > > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > > >
> > > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > > method.
> > > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > > so that the writers can free the memory associated with the lock less
> > > > > > > data structures.
> > > > > > >
> > > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > > you thank me the first time you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > > (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only inlines
> > are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
> (I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
>
> Konstantin
>
Having locking functions inline is already a problem in current releases.
The implementation can not be improved without breaking ABI (or doing special
workarounds like lock v2)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 18:56 0% ` Honnappa Nagarahalli
@ 2019-04-15 18:56 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-15 18:56 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to
> > > > > > get rid of almost all use of inline and visible structures.
> > > > > > Yes it might be marginally slower, but you thank me the first time
> you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline
> > > > > functions in DPDK? If yes, I think we need to consider the
> > > > > performance
> > > > difference. May be consider L3-fwd application, change all the inline
> functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another
> > > synchronization mechanism after all (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only
> > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say
> spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want
> it to be as fast as possible (I know that main speedup should come from
> the fact that readers don't have to wait for writer to finish, but still...)
>
Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), we have the correct APIs marked as inline. They all are part of the fast path.
> Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
@ 2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 21:26 3% ` Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-04-15 18:56 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to
> > > > > > get rid of almost all use of inline and visible structures.
> > > > > > Yes it might be marginally slower, but you thank me the first time
> you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline
> > > > > functions in DPDK? If yes, I think we need to consider the
> > > > > performance
> > > > difference. May be consider L3-fwd application, change all the inline
> functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another
> > > synchronization mechanism after all (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only
> > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say
> spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want
> it to be as fast as possible (I know that main speedup should come from
> the fact that readers don't have to wait for writer to finish, but still...)
>
Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), we have the correct APIs marked as inline. They all are part of the fast path.
> Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 17:39 0% ` Ananyev, Konstantin
@ 2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 21:26 3% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 17:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, April 15, 2019 4:39 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Mon, 15 Apr 2019 12:24:47 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Saturday, April 13, 2019 12:06 AM
> > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> Gupta
> > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > >
> > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > >
> > > > >
> > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > >
> > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > method.
> > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > so that the writers can free the memory associated with the lock less
> > > > > > data structures.
> > > > > >
> > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > >
> > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > you thank me the first time you have to fix something.
> > > > >
> > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > The structure visibility definitely needs to be addressed.
> > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > >
> > > Every function that is not in the direct datapath should not be inline.
> > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> >
> > Plus synchronization routines: spin/rwlock/barrier, etc.
> > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > (just a bit more sophisticated).
> > Konstantin
>
> If you look at the other userspace RCU, you wil see that the only inlines
> are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
>
> The synchronization logic is all real functions.
In fact, I think urcu provides both flavors:
https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
(I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 15:38 0% ` Stephen Hemminger
@ 2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 17:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, April 15, 2019 4:39 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Mon, 15 Apr 2019 12:24:47 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Saturday, April 13, 2019 12:06 AM
> > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> Gupta
> > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > >
> > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > >
> > > > >
> > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > >
> > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > method.
> > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > so that the writers can free the memory associated with the lock less
> > > > > > data structures.
> > > > > >
> > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > >
> > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > you thank me the first time you have to fix something.
> > > > >
> > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > The structure visibility definitely needs to be addressed.
> > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > >
> > > Every function that is not in the direct datapath should not be inline.
> > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> >
> > Plus synchronization routines: spin/rwlock/barrier, etc.
> > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > (just a bit more sophisticated).
> > Konstantin
>
> If you look at the other userspace RCU, you wil see that the only inlines
> are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
>
> The synchronization logic is all real functions.
In fact, I think urcu provides both flavors:
https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
(I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 15:38 0% ` Stephen Hemminger
@ 2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 17:39 0% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 15:38 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 12:24:47 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Saturday, April 13, 2019 12:06 AM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Fri, 12 Apr 2019 22:24:45 +0000
> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > >
> > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > >
> > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > method.
> > > > > This library helps identify the quiescent state of the reader threads
> > > > > so that the writers can free the memory associated with the lock less
> > > > > data structures.
> > > > >
> > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > >
> > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > you thank me the first time you have to fix something.
> > > >
> > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > The structure visibility definitely needs to be addressed.
> > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> >
> > Every function that is not in the direct datapath should not be inline.
> > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
>
> Plus synchronization routines: spin/rwlock/barrier, etc.
> I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> (just a bit more sophisticated).
> Konstantin
If you look at the other userspace RCU, you wil see that the only inlines
are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
The synchronization logic is all real functions.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 12:24 0% ` Ananyev, Konstantin
@ 2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 17:39 0% ` Ananyev, Konstantin
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 15:38 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 12:24:47 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Saturday, April 13, 2019 12:06 AM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Fri, 12 Apr 2019 22:24:45 +0000
> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > >
> > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > >
> > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > method.
> > > > > This library helps identify the quiescent state of the reader threads
> > > > > so that the writers can free the memory associated with the lock less
> > > > > data structures.
> > > > >
> > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > >
> > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > you thank me the first time you have to fix something.
> > > >
> > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > The structure visibility definitely needs to be addressed.
> > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> >
> > Every function that is not in the direct datapath should not be inline.
> > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
>
> Plus synchronization routines: spin/rwlock/barrier, etc.
> I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> (just a bit more sophisticated).
> Konstantin
If you look at the other userspace RCU, you wil see that the only inlines
are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
The synchronization logic is all real functions.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 12:24 0% ` Ananyev, Konstantin
@ 2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 15:38 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 12:24 UTC (permalink / raw)
To: Stephen Hemminger, Honnappa Nagarahalli
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, April 13, 2019 12:06 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Fri, 12 Apr 2019 22:24:45 +0000
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
>
> > >
> > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > >
> > > > Add RCU library supporting quiescent state based memory reclamation
> > > method.
> > > > This library helps identify the quiescent state of the reader threads
> > > > so that the writers can free the memory associated with the lock less
> > > > data structures.
> > > >
> > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > >
> > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > you thank me the first time you have to fix something.
> > >
> > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > The structure visibility definitely needs to be addressed.
> > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
>
> Every function that is not in the direct datapath should not be inline.
> Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
Plus synchronization routines: spin/rwlock/barrier, etc.
I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
(just a bit more sophisticated).
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-12 23:06 0% ` Stephen Hemminger
@ 2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 15:38 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 12:24 UTC (permalink / raw)
To: Stephen Hemminger, Honnappa Nagarahalli
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, April 13, 2019 12:06 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Fri, 12 Apr 2019 22:24:45 +0000
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
>
> > >
> > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > >
> > > > Add RCU library supporting quiescent state based memory reclamation
> > > method.
> > > > This library helps identify the quiescent state of the reader threads
> > > > so that the writers can free the memory associated with the lock less
> > > > data structures.
> > > >
> > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > >
> > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > you thank me the first time you have to fix something.
> > >
> > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > The structure visibility definitely needs to be addressed.
> > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
>
> Every function that is not in the direct datapath should not be inline.
> Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
Plus synchronization routines: spin/rwlock/barrier, etc.
I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
(just a bit more sophisticated).
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-15 9:10 4% ` Bruce Richardson
@ 2019-04-15 9:10 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-15 9:10 UTC (permalink / raw)
To: Neil Horman; +Cc: Ray Kinsella, dev
On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote:
> On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> > On 07/04/2019 10:48, Thomas Monjalon wrote:
> > > 04/04/2019 16:07, Burakov, Anatoly:
> > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > [SNIP]
> > >> So, if we are to cement our core API - we have to make a concrete effort
> > >> to specify what goes and what stays, if we want it to be maintainable.
> > >> The DPDK 1.0 specification, if you will :)
> > >
> > > "DPDK 1.0 specification", that's a great project name :-)
> > >
> >
> > Honestly - I would say that I am nervous of this.
> >
> > The definition of a DPDK 1.0 specification as a gate to API stability,
> > feels like a "great plan tomorrow" instead of a "good plan" today. I
> > think that getting people to dedicate time to such a specification might
> > prove problematic and I could see this effort being very time consuming.
> > It might never get completed.
> >
> > My preference would be to instead adopt a well-publicised community
> > timeline for adopting more conservative API maintenance rules.
> >
> > Perhaps we could give ourselves as a community a time-limited window in
> > which to address concerns around the API before they become hardened -
> > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> > to 9 months.
> >
> > We then would know the timeline when niggles like exposure of internal
> > structures and mbuf structure needed to be sorted by and could
> > prioritize accordingly.
> >
> > Ray K
>
> I'm hesitant to say this, because I'm not usually a fan of throwing up
> barricades to progress, but might some level of CI integration be useful here?
>
> Part of the problem, as I've seen it (and I think you've noted previously in
> this thread), is that ABI stability just hasn't been a priority, and not
> something that developers look at when making changes, nor when reviewers review
> patches. When I wrote the early ABI checking tools for DPDK, while the reaction
> was generally positive (I think), the results were informational, and treated as
> such (something to take note of perhaps, but something that could be ignored if
> there were more pressing issues). Perhaps a concrete step might be to run the
> ABI checker during a CI run on every commit, and block acceptance of a patch if
> it modifies the ABI. That would at least put a procedural break in ABI
> modification without clear approval from the board.
>
No objections to that here. Sounds a reasonable suggestion.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
@ 2019-04-15 9:10 4% ` Bruce Richardson
2019-04-15 9:10 4% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-15 9:10 UTC (permalink / raw)
To: Neil Horman; +Cc: Ray Kinsella, dev
On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote:
> On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> > On 07/04/2019 10:48, Thomas Monjalon wrote:
> > > 04/04/2019 16:07, Burakov, Anatoly:
> > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > [SNIP]
> > >> So, if we are to cement our core API - we have to make a concrete effort
> > >> to specify what goes and what stays, if we want it to be maintainable.
> > >> The DPDK 1.0 specification, if you will :)
> > >
> > > "DPDK 1.0 specification", that's a great project name :-)
> > >
> >
> > Honestly - I would say that I am nervous of this.
> >
> > The definition of a DPDK 1.0 specification as a gate to API stability,
> > feels like a "great plan tomorrow" instead of a "good plan" today. I
> > think that getting people to dedicate time to such a specification might
> > prove problematic and I could see this effort being very time consuming.
> > It might never get completed.
> >
> > My preference would be to instead adopt a well-publicised community
> > timeline for adopting more conservative API maintenance rules.
> >
> > Perhaps we could give ourselves as a community a time-limited window in
> > which to address concerns around the API before they become hardened -
> > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> > to 9 months.
> >
> > We then would know the timeline when niggles like exposure of internal
> > structures and mbuf structure needed to be sorted by and could
> > prioritize accordingly.
> >
> > Ray K
>
> I'm hesitant to say this, because I'm not usually a fan of throwing up
> barricades to progress, but might some level of CI integration be useful here?
>
> Part of the problem, as I've seen it (and I think you've noted previously in
> this thread), is that ABI stability just hasn't been a priority, and not
> something that developers look at when making changes, nor when reviewers review
> patches. When I wrote the early ABI checking tools for DPDK, while the reaction
> was generally positive (I think), the results were informational, and treated as
> such (something to take note of perhaps, but something that could be ignored if
> there were more pressing issues). Perhaps a concrete step might be to run the
> ABI checker during a CI run on every commit, and block acceptance of a patch if
> it modifies the ABI. That would at least put a procedural break in ABI
> modification without clear approval from the board.
>
No objections to that here. Sounds a reasonable suggestion.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-14 0:42 9% ` Neil Horman
@ 2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-14 0:42 UTC (permalink / raw)
To: Ray Kinsella; +Cc: dev
On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
> > 04/04/2019 16:07, Burakov, Anatoly:
> >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >> So, if we are to cement our core API - we have to make a concrete effort
> >> to specify what goes and what stays, if we want it to be maintainable.
> >> The DPDK 1.0 specification, if you will :)
> >
> > "DPDK 1.0 specification", that's a great project name :-)
> >
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
I'm hesitant to say this, because I'm not usually a fan of throwing up
barricades to progress, but might some level of CI integration be useful here?
Part of the problem, as I've seen it (and I think you've noted previously in
this thread), is that ABI stability just hasn't been a priority, and not
something that developers look at when making changes, nor when reviewers review
patches. When I wrote the early ABI checking tools for DPDK, while the reaction
was generally positive (I think), the results were informational, and treated as
such (something to take note of perhaps, but something that could be ignored if
there were more pressing issues). Perhaps a concrete step might be to run the
ABI checker during a CI run on every commit, and block acceptance of a patch if
it modifies the ABI. That would at least put a procedural break in ABI
modification without clear approval from the board.
Neil
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
2 siblings, 2 replies; 200+ results
From: Neil Horman @ 2019-04-14 0:42 UTC (permalink / raw)
To: Ray Kinsella; +Cc: dev
On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
> > 04/04/2019 16:07, Burakov, Anatoly:
> >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >> So, if we are to cement our core API - we have to make a concrete effort
> >> to specify what goes and what stays, if we want it to be maintainable.
> >> The DPDK 1.0 specification, if you will :)
> >
> > "DPDK 1.0 specification", that's a great project name :-)
> >
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
I'm hesitant to say this, because I'm not usually a fan of throwing up
barricades to progress, but might some level of CI integration be useful here?
Part of the problem, as I've seen it (and I think you've noted previously in
this thread), is that ABI stability just hasn't been a priority, and not
something that developers look at when making changes, nor when reviewers review
patches. When I wrote the early ABI checking tools for DPDK, while the reaction
was generally positive (I think), the results were informational, and treated as
such (something to take note of perhaps, but something that could be ignored if
there were more pressing issues). Perhaps a concrete step might be to run the
ABI checker during a CI run on every commit, and block acceptance of a patch if
it modifies the ABI. That would at least put a procedural break in ABI
modification without clear approval from the board.
Neil
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 23:06 0% ` Stephen Hemminger
@ 2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-15 12:24 0% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 23:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Fri, 12 Apr 2019 22:24:45 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > On Fri, 12 Apr 2019 15:20:37 -0500
> > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> >
> > > Add RCU library supporting quiescent state based memory reclamation
> > method.
> > > This library helps identify the quiescent state of the reader threads
> > > so that the writers can free the memory associated with the lock less
> > > data structures.
> > >
> > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > all use of inline and visible structures. Yes it might be marginally slower, but
> > you thank me the first time you have to fix something.
> >
> Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> The structure visibility definitely needs to be addressed.
> For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
Every function that is not in the direct datapath should not be inline.
Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 22:24 3% ` Honnappa Nagarahalli
@ 2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-15 12:24 0% ` Ananyev, Konstantin
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 23:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Fri, 12 Apr 2019 22:24:45 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > On Fri, 12 Apr 2019 15:20:37 -0500
> > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> >
> > > Add RCU library supporting quiescent state based memory reclamation
> > method.
> > > This library helps identify the quiescent state of the reader threads
> > > so that the writers can free the memory associated with the lock less
> > > data structures.
> > >
> > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > all use of inline and visible structures. Yes it might be marginally slower, but
> > you thank me the first time you have to fix something.
> >
> Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> The structure visibility definitely needs to be addressed.
> For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
Every function that is not in the direct datapath should not be inline.
Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:24 3% ` Honnappa Nagarahalli
@ 2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 23:06 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-12 22:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
>
> On Fri, 12 Apr 2019 15:20:37 -0500
> Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
>
> > Add RCU library supporting quiescent state based memory reclamation
> method.
> > This library helps identify the quiescent state of the reader threads
> > so that the writers can free the memory associated with the lock less
> > data structures.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> After evaluating long term API/ABI issues, I think you need to get rid of almost
> all use of inline and visible structures. Yes it might be marginally slower, but
> you thank me the first time you have to fix something.
>
Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
The structure visibility definitely needs to be addressed.
For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:06 3% ` Stephen Hemminger
@ 2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 23:06 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-12 22:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
>
> On Fri, 12 Apr 2019 15:20:37 -0500
> Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
>
> > Add RCU library supporting quiescent state based memory reclamation
> method.
> > This library helps identify the quiescent state of the reader threads
> > so that the writers can free the memory associated with the lock less
> > data structures.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> After evaluating long term API/ABI issues, I think you need to get rid of almost
> all use of inline and visible structures. Yes it might be marginally slower, but
> you thank me the first time you have to fix something.
>
Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
The structure visibility definitely needs to be addressed.
For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:06 3% ` Stephen Hemminger
@ 2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:24 3% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 22:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev, gavin.hu,
dharmik.thakkar, malvika.gupta
On Fri, 12 Apr 2019 15:20:37 -0500
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> Add RCU library supporting quiescent state based memory reclamation method.
> This library helps identify the quiescent state of the reader threads so
> that the writers can free the memory associated with the lock less data
> structures.
>
> Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
After evaluating long term API/ABI issues, I think you need to get rid
of almost all use of inline and visible structures. Yes it might be marginally
slower, but you thank me the first time you have to fix something.
Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
@ 2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:24 3% ` Honnappa Nagarahalli
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 22:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev, gavin.hu,
dharmik.thakkar, malvika.gupta
On Fri, 12 Apr 2019 15:20:37 -0500
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> Add RCU library supporting quiescent state based memory reclamation method.
> This library helps identify the quiescent state of the reader threads so
> that the writers can free the memory associated with the lock less data
> structures.
>
> Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
After evaluating long term API/ABI issues, I think you need to get rid
of almost all use of inline and visible structures. Yes it might be marginally
slower, but you thank me the first time you have to fix something.
Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 16:05 0% ` Stephen Hemminger
@ 2019-04-12 16:05 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 16:05 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian
On Fri, 12 Apr 2019 16:32:01 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 26/03/2019 10:29, David Marchand:
> > > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> > wrote:
> > >
> > > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > > Introduce a new api to retrieve per queue statistics from the
> > drivers.
> > > > > The api objectives:
> > > > > - easily add some common per queue statistics and have it exposed
> > > > > through the user xstats api while the user stats api is left
> > untouched
> > > > > - remove the limitations on the per queue statistics count (inherited
> > > > > from ixgbe) and avoid recurrent bugs on stats array overflow
> >
> > First comment, I think it would be easier to read if renaming the legacy
> > basic stats interface was in a separate patch.
> >
>
> It will be quite artificial, but I can do this yes.
>
>
> > > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> > my
> > > > concern is if it is overkill to have three dev_ops to get stats
> > > > and I am feeling that is making xstat code more complex.
> > >
> > > Having these new (meant to be) internal dev_ops has the avantage of
> > > separating the statistics reported from the drivers from the exported
> > api.
> > > This is also why I did not prefix the structure names with rte_.
> >
> > Yes, and to make it clear, please do not talk about API,
> > as it is only a driver interface.
> >
>
> Ok, so I will describe this as a "driver interface" update.
>
>
>
> > > The "complex" part is in a single place, ethdev and this is when
> > > translating from an internal representation to the exposed bits in the
> > > public apis.
> > >
> > > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > > rte_eth_stats'?
> > > >
> > >
> > > It does not solve the problem of drivers that are buggy because of the
> > > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > > All drivers need to be aware of this limitation of the rte_eth_stats
> > > structure.
> >
> > Yes, this limitation should be dropped.
> > I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> > deprecated as they were a bad abstraction of ixgbe limitation.
> >
>
> That's a different topic from my pov, but yes, this mapping stuff should go
> away, later.
>
>
> > > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > > change, so
> > > > fix can be done with less changes, although it will push the fix into
> > next
> > > > release because of the ABI break.
> > >
> > > I am fine with merging this together, we don't want to backport this
> > > anyway, right?
> >
> > No, it would make some behaviours changing in stable releases,
> > so better to not backport it and keep the buggy behaviour in old branches.
> >
>
> Since the time I had posted this RFC, I have worked on a RFC v2, I will
> post this next week, with the drivers I found time to convert.
> We will have to take a decision on what goes to -rc2 between this and the
> q_errors[] patchset.
>
>
It looks like this all about maintaining source compatiablity with older
or out of tree drivers. This is not something DPDK has to worry about.
Why not just do a mondo patch that fixes all the drivers to use the new stats API.
You do need to keep the same ethdev interface for applications, but driver
API can change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
@ 2019-04-12 16:05 0% ` Stephen Hemminger
2019-04-12 16:05 0% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-12 16:05 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian
On Fri, 12 Apr 2019 16:32:01 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 26/03/2019 10:29, David Marchand:
> > > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> > wrote:
> > >
> > > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > > Introduce a new api to retrieve per queue statistics from the
> > drivers.
> > > > > The api objectives:
> > > > > - easily add some common per queue statistics and have it exposed
> > > > > through the user xstats api while the user stats api is left
> > untouched
> > > > > - remove the limitations on the per queue statistics count (inherited
> > > > > from ixgbe) and avoid recurrent bugs on stats array overflow
> >
> > First comment, I think it would be easier to read if renaming the legacy
> > basic stats interface was in a separate patch.
> >
>
> It will be quite artificial, but I can do this yes.
>
>
> > > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> > my
> > > > concern is if it is overkill to have three dev_ops to get stats
> > > > and I am feeling that is making xstat code more complex.
> > >
> > > Having these new (meant to be) internal dev_ops has the avantage of
> > > separating the statistics reported from the drivers from the exported
> > api.
> > > This is also why I did not prefix the structure names with rte_.
> >
> > Yes, and to make it clear, please do not talk about API,
> > as it is only a driver interface.
> >
>
> Ok, so I will describe this as a "driver interface" update.
>
>
>
> > > The "complex" part is in a single place, ethdev and this is when
> > > translating from an internal representation to the exposed bits in the
> > > public apis.
> > >
> > > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > > rte_eth_stats'?
> > > >
> > >
> > > It does not solve the problem of drivers that are buggy because of the
> > > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > > All drivers need to be aware of this limitation of the rte_eth_stats
> > > structure.
> >
> > Yes, this limitation should be dropped.
> > I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> > deprecated as they were a bad abstraction of ixgbe limitation.
> >
>
> That's a different topic from my pov, but yes, this mapping stuff should go
> away, later.
>
>
> > > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > > change, so
> > > > fix can be done with less changes, although it will push the fix into
> > next
> > > > release because of the ABI break.
> > >
> > > I am fine with merging this together, we don't want to backport this
> > > anyway, right?
> >
> > No, it would make some behaviours changing in stable releases,
> > so better to not backport it and keep the buggy behaviour in old branches.
> >
>
> Since the time I had posted this RFC, I have worked on a RFC v2, I will
> post this next week, with the drivers I found time to convert.
> We will have to take a decision on what goes to -rc2 between this and the
> q_errors[] patchset.
>
>
It looks like this all about maintaining source compatiablity with older
or out of tree drivers. This is not something DPDK has to worry about.
Why not just do a mondo patch that fixes all the drivers to use the new stats API.
You do need to keep the same ethdev interface for applications, but driver
API can change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:57 0% ` Ferruh Yigit
@ 2019-04-12 15:57 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:45 PM, Thomas Monjalon wrote:
> 12/04/2019 17:38, Ferruh Yigit:
>> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
>>> 11/03/2019 18:22, Ferruh Yigit:
>>>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>>>> According to the api, the q_errors[] per queue statistic is for reception
>>>>> errors not transmit errors.
>>>>> This is a first cleanup on statistics before looking at oerrors.
>>>>>
>>>>
>>>> Yes, the patchset looks aligned with the API documentation [1].
>>>>
>>>> What can be the solution after cleanup? We can merge this cleanup and solution
>>>> next to each-other to not leave a gap?
>>>
>>> I think we should merge those fixes in 19.05-rc2.
>>>
>>> It seems there is a lot more work to achieve on stats, so better
>>> to start without waiting for the full picture.
>>>
>>
>> The problem is "q_errors" is available only for Rx queues, and David's patch is
>> preventing drivers to put Tx error stats into "q_errors" field.
>>
>> But it is clear that there is a need for a field for Tx queues errors. David has
>> another patch to using xstats for this. But I believe xstats is making solution
>> confusing, and now approach is unbalanced for Rx and Tx queues.
>>
>> I am for adding a new field for Tx queues "q_errors", and this will make getting
>> stats and David's patch very simple.
>>
>> The problem with the new fields is it breaks the ABI, but we already increased
>> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
>
> If changing the stats API, we should increase the number of stats per queue:
> #define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
> What about 128 queues per port? 256?
We have 5 uint64_t using this [1], it will be 6 if we add new one.
So having 256 queues, will cost 12K memory, this is not a big number.
Is there any other concern of having large array other than possible memory waste?
[1]
uint64_t q_ipackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_opackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_ibytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_obytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_errors[RTE_ETHDEV_QUEUE_STAT_CNTRS];
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:45 0% ` Thomas Monjalon
@ 2019-04-12 15:57 0% ` Ferruh Yigit
2019-04-12 15:57 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:45 PM, Thomas Monjalon wrote:
> 12/04/2019 17:38, Ferruh Yigit:
>> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
>>> 11/03/2019 18:22, Ferruh Yigit:
>>>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>>>> According to the api, the q_errors[] per queue statistic is for reception
>>>>> errors not transmit errors.
>>>>> This is a first cleanup on statistics before looking at oerrors.
>>>>>
>>>>
>>>> Yes, the patchset looks aligned with the API documentation [1].
>>>>
>>>> What can be the solution after cleanup? We can merge this cleanup and solution
>>>> next to each-other to not leave a gap?
>>>
>>> I think we should merge those fixes in 19.05-rc2.
>>>
>>> It seems there is a lot more work to achieve on stats, so better
>>> to start without waiting for the full picture.
>>>
>>
>> The problem is "q_errors" is available only for Rx queues, and David's patch is
>> preventing drivers to put Tx error stats into "q_errors" field.
>>
>> But it is clear that there is a need for a field for Tx queues errors. David has
>> another patch to using xstats for this. But I believe xstats is making solution
>> confusing, and now approach is unbalanced for Rx and Tx queues.
>>
>> I am for adding a new field for Tx queues "q_errors", and this will make getting
>> stats and David's patch very simple.
>>
>> The problem with the new fields is it breaks the ABI, but we already increased
>> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
>
> If changing the stats API, we should increase the number of stats per queue:
> #define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
> What about 128 queues per port? 256?
We have 5 uint64_t using this [1], it will be 6 if we add new one.
So having 256 queues, will cost 12K memory, this is not a big number.
Is there any other concern of having large array other than possible memory waste?
[1]
uint64_t q_ipackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_opackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_ibytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_obytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_errors[RTE_ETHDEV_QUEUE_STAT_CNTRS];
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:45 0% ` Thomas Monjalon
@ 2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:57 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 15:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, David Marchand, Andrew Rybchenko
12/04/2019 17:38, Ferruh Yigit:
> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> > 11/03/2019 18:22, Ferruh Yigit:
> >> On 3/4/2019 11:18 AM, David Marchand wrote:
> >>> According to the api, the q_errors[] per queue statistic is for reception
> >>> errors not transmit errors.
> >>> This is a first cleanup on statistics before looking at oerrors.
> >>>
> >>
> >> Yes, the patchset looks aligned with the API documentation [1].
> >>
> >> What can be the solution after cleanup? We can merge this cleanup and solution
> >> next to each-other to not leave a gap?
> >
> > I think we should merge those fixes in 19.05-rc2.
> >
> > It seems there is a lot more work to achieve on stats, so better
> > to start without waiting for the full picture.
> >
>
> The problem is "q_errors" is available only for Rx queues, and David's patch is
> preventing drivers to put Tx error stats into "q_errors" field.
>
> But it is clear that there is a need for a field for Tx queues errors. David has
> another patch to using xstats for this. But I believe xstats is making solution
> confusing, and now approach is unbalanced for Rx and Tx queues.
>
> I am for adding a new field for Tx queues "q_errors", and this will make getting
> stats and David's patch very simple.
>
> The problem with the new fields is it breaks the ABI, but we already increased
> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
If changing the stats API, we should increase the number of stats per queue:
#define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
What about 128 queues per port? 256?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:38 3% ` Ferruh Yigit
@ 2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:57 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 15:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, David Marchand, Andrew Rybchenko
12/04/2019 17:38, Ferruh Yigit:
> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> > 11/03/2019 18:22, Ferruh Yigit:
> >> On 3/4/2019 11:18 AM, David Marchand wrote:
> >>> According to the api, the q_errors[] per queue statistic is for reception
> >>> errors not transmit errors.
> >>> This is a first cleanup on statistics before looking at oerrors.
> >>>
> >>
> >> Yes, the patchset looks aligned with the API documentation [1].
> >>
> >> What can be the solution after cleanup? We can merge this cleanup and solution
> >> next to each-other to not leave a gap?
> >
> > I think we should merge those fixes in 19.05-rc2.
> >
> > It seems there is a lot more work to achieve on stats, so better
> > to start without waiting for the full picture.
> >
>
> The problem is "q_errors" is available only for Rx queues, and David's patch is
> preventing drivers to put Tx error stats into "q_errors" field.
>
> But it is clear that there is a need for a field for Tx queues errors. David has
> another patch to using xstats for this. But I believe xstats is making solution
> confusing, and now approach is unbalanced for Rx and Tx queues.
>
> I am for adding a new field for Tx queues "q_errors", and this will make getting
> stats and David's patch very simple.
>
> The problem with the new fields is it breaks the ABI, but we already increased
> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
If changing the stats API, we should increase the number of stats per queue:
#define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
What about 128 queues per port? 256?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:38 3% ` Ferruh Yigit
@ 2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:45 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> 11/03/2019 18:22, Ferruh Yigit:
>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>> According to the api, the q_errors[] per queue statistic is for reception
>>> errors not transmit errors.
>>> This is a first cleanup on statistics before looking at oerrors.
>>>
>>
>> Yes, the patchset looks aligned with the API documentation [1].
>>
>> What can be the solution after cleanup? We can merge this cleanup and solution
>> next to each-other to not leave a gap?
>
> I think we should merge those fixes in 19.05-rc2.
>
> It seems there is a lot more work to achieve on stats, so better
> to start without waiting for the full picture.
>
The problem is "q_errors" is available only for Rx queues, and David's patch is
preventing drivers to put Tx error stats into "q_errors" field.
But it is clear that there is a need for a field for Tx queues errors. David has
another patch to using xstats for this. But I believe xstats is making solution
confusing, and now approach is unbalanced for Rx and Tx queues.
I am for adding a new field for Tx queues "q_errors", and this will make getting
stats and David's patch very simple.
The problem with the new fields is it breaks the ABI, but we already increased
the ABIVER for ethdev this release, I believe this is very good timing for this fix.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
@ 2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:45 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> 11/03/2019 18:22, Ferruh Yigit:
>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>> According to the api, the q_errors[] per queue statistic is for reception
>>> errors not transmit errors.
>>> This is a first cleanup on statistics before looking at oerrors.
>>>
>>
>> Yes, the patchset looks aligned with the API documentation [1].
>>
>> What can be the solution after cleanup? We can merge this cleanup and solution
>> next to each-other to not leave a gap?
>
> I think we should merge those fixes in 19.05-rc2.
>
> It seems there is a lot more work to achieve on stats, so better
> to start without waiting for the full picture.
>
The problem is "q_errors" is available only for Rx queues, and David's patch is
preventing drivers to put Tx error stats into "q_errors" field.
But it is clear that there is a need for a field for Tx queues errors. David has
another patch to using xstats for this. But I believe xstats is making solution
confusing, and now approach is unbalanced for Rx and Tx queues.
I am for adding a new field for Tx queues "q_errors", and this will make getting
stats and David's patch very simple.
The problem with the new fields is it breaks the ABI, but we already increased
the ABIVER for ethdev this release, I believe this is very good timing for this fix.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 14:32 0% ` David Marchand
@ 2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-12 14:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> 26/03/2019 10:29, David Marchand:
> > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
> >
> > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > Introduce a new api to retrieve per queue statistics from the
> drivers.
> > > > The api objectives:
> > > > - easily add some common per queue statistics and have it exposed
> > > > through the user xstats api while the user stats api is left
> untouched
> > > > - remove the limitations on the per queue statistics count (inherited
> > > > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> First comment, I think it would be easier to read if renaming the legacy
> basic stats interface was in a separate patch.
>
It will be quite artificial, but I can do this yes.
> > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> my
> > > concern is if it is overkill to have three dev_ops to get stats
> > > and I am feeling that is making xstat code more complex.
> >
> > Having these new (meant to be) internal dev_ops has the avantage of
> > separating the statistics reported from the drivers from the exported
> api.
> > This is also why I did not prefix the structure names with rte_.
>
> Yes, and to make it clear, please do not talk about API,
> as it is only a driver interface.
>
Ok, so I will describe this as a "driver interface" update.
> > The "complex" part is in a single place, ethdev and this is when
> > translating from an internal representation to the exposed bits in the
> > public apis.
> >
> > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > rte_eth_stats'?
> > >
> >
> > It does not solve the problem of drivers that are buggy because of the
> > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > All drivers need to be aware of this limitation of the rte_eth_stats
> > structure.
>
> Yes, this limitation should be dropped.
> I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> deprecated as they were a bad abstraction of ixgbe limitation.
>
That's a different topic from my pov, but yes, this mapping stuff should go
away, later.
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > change, so
> > > fix can be done with less changes, although it will push the fix into
> next
> > > release because of the ABI break.
> >
> > I am fine with merging this together, we don't want to backport this
> > anyway, right?
>
> No, it would make some behaviours changing in stable releases,
> so better to not backport it and keep the buggy behaviour in old branches.
>
Since the time I had posted this RFC, I have worked on a RFC v2, I will
post this next week, with the drivers I found time to convert.
We will have to take a decision on what goes to -rc2 between this and the
q_errors[] patchset.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
@ 2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: David Marchand @ 2019-04-12 14:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> 26/03/2019 10:29, David Marchand:
> > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
> >
> > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > Introduce a new api to retrieve per queue statistics from the
> drivers.
> > > > The api objectives:
> > > > - easily add some common per queue statistics and have it exposed
> > > > through the user xstats api while the user stats api is left
> untouched
> > > > - remove the limitations on the per queue statistics count (inherited
> > > > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> First comment, I think it would be easier to read if renaming the legacy
> basic stats interface was in a separate patch.
>
It will be quite artificial, but I can do this yes.
> > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> my
> > > concern is if it is overkill to have three dev_ops to get stats
> > > and I am feeling that is making xstat code more complex.
> >
> > Having these new (meant to be) internal dev_ops has the avantage of
> > separating the statistics reported from the drivers from the exported
> api.
> > This is also why I did not prefix the structure names with rte_.
>
> Yes, and to make it clear, please do not talk about API,
> as it is only a driver interface.
>
Ok, so I will describe this as a "driver interface" update.
> > The "complex" part is in a single place, ethdev and this is when
> > translating from an internal representation to the exposed bits in the
> > public apis.
> >
> > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > rte_eth_stats'?
> > >
> >
> > It does not solve the problem of drivers that are buggy because of the
> > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > All drivers need to be aware of this limitation of the rte_eth_stats
> > structure.
>
> Yes, this limitation should be dropped.
> I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> deprecated as they were a bad abstraction of ixgbe limitation.
>
That's a different topic from my pov, but yes, this mapping stuff should go
away, later.
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > change, so
> > > fix can be done with less changes, although it will push the fix into
> next
> > > release because of the ABI break.
> >
> > I am fine with merging this together, we don't want to backport this
> > anyway, right?
>
> No, it would make some behaviours changing in stable releases,
> so better to not backport it and keep the buggy behaviour in old branches.
>
Since the time I had posted this RFC, I have worked on a RFC v2, I will
post this next week, with the drivers I found time to convert.
We will have to take a decision on what goes to -rc2 between this and the
q_errors[] patchset.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 13:29 0% ` Thomas Monjalon
@ 2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 13:29 UTC (permalink / raw)
To: David Marchand
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
26/03/2019 10:29, David Marchand:
> On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > Introduce a new api to retrieve per queue statistics from the drivers.
> > > The api objectives:
> > > - easily add some common per queue statistics and have it exposed
> > > through the user xstats api while the user stats api is left untouched
> > > - remove the limitations on the per queue statistics count (inherited
> > > from ixgbe) and avoid recurrent bugs on stats array overflow
First comment, I think it would be easier to read if renaming the legacy
basic stats interface was in a separate patch.
> > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> > concern is if it is overkill to have three dev_ops to get stats
> > and I am feeling that is making xstat code more complex.
>
> Having these new (meant to be) internal dev_ops has the avantage of
> separating the statistics reported from the drivers from the exported api.
> This is also why I did not prefix the structure names with rte_.
Yes, and to make it clear, please do not talk about API,
as it is only a driver interface.
> The "complex" part is in a single place, ethdev and this is when
> translating from an internal representation to the exposed bits in the
> public apis.
>
> Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > rte_eth_stats'?
> >
>
> It does not solve the problem of drivers that are buggy because of the
> limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> All drivers need to be aware of this limitation of the rte_eth_stats
> structure.
Yes, this limitation should be dropped.
I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
deprecated as they were a bad abstraction of ixgbe limitation.
> The drivers manipulate queues in rx/tx_queue_setup dev_ops for example,
> having rxq/txq_stats_get dev_ops is more consistent to me.
+1
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > change, so
> > fix can be done with less changes, although it will push the fix into next
> > release because of the ABI break.
>
> I am fine with merging this together, we don't want to backport this
> anyway, right?
No, it would make some behaviours changing in stable releases,
so better to not backport it and keep the buggy behaviour in old branches.
> But so far, I don't feel the need to break the rte_eth_stats_get API, if we
> want to go to this, we can define an entirely new api to expose
> standardized bits and still use the rxq/txq_stats_get internal dev_ops I
> propose.
Good
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
@ 2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 13:29 UTC (permalink / raw)
To: David Marchand
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
26/03/2019 10:29, David Marchand:
> On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > Introduce a new api to retrieve per queue statistics from the drivers.
> > > The api objectives:
> > > - easily add some common per queue statistics and have it exposed
> > > through the user xstats api while the user stats api is left untouched
> > > - remove the limitations on the per queue statistics count (inherited
> > > from ixgbe) and avoid recurrent bugs on stats array overflow
First comment, I think it would be easier to read if renaming the legacy
basic stats interface was in a separate patch.
> > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> > concern is if it is overkill to have three dev_ops to get stats
> > and I am feeling that is making xstat code more complex.
>
> Having these new (meant to be) internal dev_ops has the avantage of
> separating the statistics reported from the drivers from the exported api.
> This is also why I did not prefix the structure names with rte_.
Yes, and to make it clear, please do not talk about API,
as it is only a driver interface.
> The "complex" part is in a single place, ethdev and this is when
> translating from an internal representation to the exposed bits in the
> public apis.
>
> Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > rte_eth_stats'?
> >
>
> It does not solve the problem of drivers that are buggy because of the
> limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> All drivers need to be aware of this limitation of the rte_eth_stats
> structure.
Yes, this limitation should be dropped.
I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
deprecated as they were a bad abstraction of ixgbe limitation.
> The drivers manipulate queues in rx/tx_queue_setup dev_ops for example,
> having rxq/txq_stats_get dev_ops is more consistent to me.
+1
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > change, so
> > fix can be done with less changes, although it will push the fix into next
> > release because of the ABI break.
>
> I am fine with merging this together, we don't want to backport this
> anyway, right?
No, it would make some behaviours changing in stable releases,
so better to not backport it and keep the buggy behaviour in old branches.
> But so far, I don't feel the need to break the rte_eth_stats_get API, if we
> want to go to this, we can define an entirely new api to expose
> standardized bits and still use the rxq/txq_stats_get internal dev_ops I
> propose.
Good
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH V3] doc: add guideines for initial PMD submission
2019-04-12 10:26 4% [dpdk-dev] [PATCH V3] " Rami Rosen
@ 2019-04-12 10:26 4% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-04-12 10:26 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V3 changes:
* Fix a typo.
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, initial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH V3] doc: add guideines for initial PMD submission
@ 2019-04-12 10:26 4% Rami Rosen
2019-04-12 10:26 4% ` Rami Rosen
0 siblings, 1 reply; 200+ results
From: Rami Rosen @ 2019-04-12 10:26 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V3 changes:
* Fix a typo.
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, initial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission
2019-04-12 10:13 4% [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission Rami Rosen
@ 2019-04-12 10:13 4% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-04-12 10:13 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, intial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission
@ 2019-04-12 10:13 4% Rami Rosen
2019-04-12 10:13 4% ` Rami Rosen
0 siblings, 1 reply; 200+ results
From: Rami Rosen @ 2019-04-12 10:13 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, intial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums
2019-04-11 10:41 1% [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums Bruce Richardson
@ 2019-04-11 10:41 1% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-11 10:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
The cmdline defined an enum for the various numeric type parameters,
but these were missing the RTE_ prefix and so could conflict with defines
in various environments, e.g. on Windows. Adding the prefix fixes these
conflicts.
Note: this changes the API used by apps using cmdline, but since enum
values aren't changing, it's ABI compatible.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test-cmdline/commands.c | 2 +-
app/test-pmd/bpf_cmd.c | 8 +-
app/test-pmd/cmdline.c | 656 +++++++++---------
app/test-pmd/cmdline_mtr.c | 84 +--
app/test-pmd/cmdline_tm.c | 172 ++---
app/test/test_cmdline_num.c | 48 +-
doc/guides/rel_notes/release_19_05.rst | 4 +
examples/ethtool/ethtool-app/ethapp.c | 18 +-
examples/ipsec-secgw/parser.c | 2 +-
examples/qos_sched/cmdline.c | 46 +-
examples/quota_watermark/qwctl/commands.c | 2 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/vm_power_cli.c | 8 +-
lib/librte_cmdline/cmdline_parse_num.c | 40 +-
lib/librte_cmdline/cmdline_parse_num.h | 16 +-
15 files changed, 556 insertions(+), 552 deletions(-)
diff --git a/app/test-cmdline/commands.c b/app/test-cmdline/commands.c
index d81da9665..0e2ca8ac4 100644
--- a/app/test-cmdline/commands.c
+++ b/app/test-cmdline/commands.c
@@ -191,7 +191,7 @@ cmd_num_parsed(void *parsed_result,
}
cmdline_parse_token_num_t cmd_num_tok =
- TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, RTE_UINT32);
cmdline_parse_inst_t cmd_num = {
.f = cmd_num_parsed, /* function to call */
diff --git a/app/test-pmd/bpf_cmd.c b/app/test-pmd/bpf_cmd.c
index 830bfc13a..254290f30 100644
--- a/app/test-pmd/bpf_cmd.c
+++ b/app/test-pmd/bpf_cmd.c
@@ -124,9 +124,9 @@ cmdline_parse_token_string_t cmd_load_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_load_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_load_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, RTE_UINT16);
cmdline_parse_token_string_t cmd_load_bpf_flags =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
flags, NULL);
@@ -180,9 +180,9 @@ cmdline_parse_token_string_t cmd_unload_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_unld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_unload_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_unload_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_bpf_unld_parse = {
.f = cmd_operate_bpf_unld_parsed,
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ab03c111..82e67ab92 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1250,7 +1250,7 @@ cmdline_parse_token_string_t cmd_operate_specific_port_port =
name, "start#stop#close#reset");
cmdline_parse_token_num_t cmd_operate_specific_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_specific_port_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_inst_t cmd_operate_specific_port = {
.f = cmd_operate_specific_port_parsed,
@@ -1386,7 +1386,7 @@ cmdline_parse_token_string_t cmd_operate_detach_port_keyword =
keyword, "detach");
cmdline_parse_token_num_t cmd_operate_detach_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_detach_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_detach_port = {
.f = cmd_operate_detach_port_parsed,
@@ -1567,7 +1567,7 @@ cmdline_parse_token_string_t cmd_config_speed_specific_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, keyword,
"config");
cmdline_parse_token_num_t cmd_config_speed_specific_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_speed_specific_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item1,
"speed");
@@ -1639,7 +1639,7 @@ cmdline_parse_token_string_t cmd_config_loopback_all_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_all, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_all_mode =
- TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_all = {
.f = cmd_config_loopback_all_parsed,
@@ -1693,13 +1693,13 @@ cmdline_parse_token_string_t cmd_config_loopback_specific_keyword =
"config");
cmdline_parse_token_num_t cmd_config_loopback_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_loopback_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_specific, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_specific_mode =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, mode,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_specific = {
.f = cmd_config_loopback_specific_parsed,
@@ -1789,7 +1789,7 @@ cmdline_parse_token_string_t cmd_config_rx_tx_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rx_tx, name,
"rxq#txq#rxd#txd");
cmdline_parse_token_num_t cmd_config_rx_tx_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rx_tx = {
.f = cmd_config_rx_tx_parsed,
@@ -1871,7 +1871,7 @@ cmdline_parse_token_string_t cmd_config_max_pkt_len_name =
"max-pkt-len");
cmdline_parse_token_num_t cmd_config_max_pkt_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_max_pkt_len_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_max_pkt_len = {
.f = cmd_config_max_pkt_len_parsed,
@@ -1920,9 +1920,9 @@ cmdline_parse_token_string_t cmd_config_mtu_mtu =
TOKEN_STRING_INITIALIZER(struct cmd_config_mtu_result, keyword,
"mtu");
cmdline_parse_token_num_t cmd_config_mtu_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_config_mtu_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_mtu = {
.f = cmd_config_mtu_parsed,
@@ -2287,7 +2287,7 @@ cmdline_parse_token_string_t cmd_config_rss_hash_key_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key, config,
"config");
cmdline_parse_token_num_t cmd_config_rss_hash_key_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_hash_key_rss_hash_key =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key,
rss_hash_key, "rss-hash-key");
@@ -2385,19 +2385,19 @@ cmdline_parse_token_string_t cmd_config_rxtx_ring_size_config =
config, "config");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_portid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- portid, UINT16);
+ portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rsize =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rsize, "ring_size");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- size, UINT16);
+ size, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rxtx_ring_size = {
.f = cmd_config_rxtx_ring_size_parsed,
@@ -2486,11 +2486,11 @@ cmd_config_rxtx_queue_parsed(void *parsed_result,
cmdline_parse_token_string_t cmd_config_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_config_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, opname,
"start#stop");
@@ -2566,13 +2566,13 @@ cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_port =
port, "port");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
opname, "deferred_start");
@@ -2608,11 +2608,11 @@ struct cmd_setup_rxtx_queue {
cmdline_parse_token_string_t cmd_setup_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_setup =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, setup, "setup");
@@ -2819,7 +2819,7 @@ cmdline_parse_token_string_t cmd_config_rss_reta_port =
cmdline_parse_token_string_t cmd_config_rss_reta_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, keyword, "config");
cmdline_parse_token_num_t cmd_config_rss_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_reta_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, name, "rss");
cmdline_parse_token_string_t cmd_config_rss_reta_list_name =
@@ -2927,13 +2927,13 @@ cmdline_parse_token_string_t cmd_showport_reta_show =
cmdline_parse_token_string_t cmd_showport_reta_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, port, "port");
cmdline_parse_token_num_t cmd_showport_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_rss =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, rss, "rss");
cmdline_parse_token_string_t cmd_showport_reta_reta =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, reta, "reta");
cmdline_parse_token_num_t cmd_showport_reta_size =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_list_of_items =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta,
list_of_items, NULL);
@@ -2978,7 +2978,7 @@ cmdline_parse_token_string_t cmd_showport_rss_hash_show =
cmdline_parse_token_string_t cmd_showport_rss_hash_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, port, "port");
cmdline_parse_token_num_t cmd_showport_rss_hash_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_rss_hash_rss_hash =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, rss_hash,
"rss-hash");
@@ -3082,7 +3082,7 @@ cmdline_parse_token_string_t cmd_config_dcb_port =
cmdline_parse_token_string_t cmd_config_dcb_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, config, "config");
cmdline_parse_token_num_t cmd_config_dcb_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_dcb_dcb =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, dcb, "dcb");
cmdline_parse_token_string_t cmd_config_dcb_vt =
@@ -3090,7 +3090,7 @@ cmdline_parse_token_string_t cmd_config_dcb_vt =
cmdline_parse_token_string_t cmd_config_dcb_vt_en =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, vt_en, "on#off");
cmdline_parse_token_num_t cmd_config_dcb_num_tcs =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_dcb_pfc=
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, pfc, "pfc");
cmdline_parse_token_string_t cmd_config_dcb_pfc_en =
@@ -3185,7 +3185,7 @@ cmdline_parse_token_string_t cmd_config_burst_all =
cmdline_parse_token_string_t cmd_config_burst_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_burst, name, "burst");
cmdline_parse_token_num_t cmd_config_burst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_burst = {
.f = cmd_config_burst_parsed,
@@ -3254,7 +3254,7 @@ cmdline_parse_token_string_t cmd_config_thresh_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_thresh, name,
"txpt#txht#txwt#rxpt#rxht#rxwt");
cmdline_parse_token_num_t cmd_config_thresh_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, RTE_UINT8);
cmdline_parse_inst_t cmd_config_thresh = {
.f = cmd_config_thresh_parsed,
@@ -3318,7 +3318,7 @@ cmdline_parse_token_string_t cmd_config_threshold_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_threshold, name,
"txfreet#txrst#rxfreet");
cmdline_parse_token_num_t cmd_config_threshold_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_threshold = {
.f = cmd_config_threshold_parsed,
@@ -3524,7 +3524,7 @@ cmdline_parse_token_string_t cmd_setmask_mask =
TOKEN_STRING_INITIALIZER(struct cmd_setmask_result, mask,
"coremask#portmask");
cmdline_parse_token_num_t cmd_setmask_value =
- TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, UINT64);
+ TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, RTE_UINT64);
cmdline_parse_inst_t cmd_set_fwd_mask = {
.f = cmd_set_mask_parsed,
@@ -3570,7 +3570,7 @@ cmdline_parse_token_string_t cmd_set_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_result, what,
"nbport#nbcore#burst#verbose");
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_set_numbers = {
.f = cmd_set_parsed,
@@ -3618,7 +3618,7 @@ cmdline_parse_token_string_t cmd_set_log_log =
cmdline_parse_token_string_t cmd_set_log_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_log_result, type, NULL);
cmdline_parse_token_num_t cmd_set_log_level =
- TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, RTE_UINT32);
cmdline_parse_inst_t cmd_set_log = {
.f = cmd_set_log_parsed,
@@ -3752,7 +3752,7 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_all_all =
all, "all");
cmdline_parse_token_num_t cmd_rx_vlan_filter_all_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_all_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter_all = {
.f = cmd_rx_vlan_filter_all_parsed,
@@ -3914,10 +3914,10 @@ cmdline_parse_token_string_t cmd_vlan_tpid_what =
what, "tpid");
cmdline_parse_token_num_t cmd_vlan_tpid_tpid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- tp_id, UINT16);
+ tp_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vlan_tpid_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_vlan_tpid = {
.f = cmd_vlan_tpid_parsed,
@@ -3964,10 +3964,10 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter = {
.f = cmd_rx_vlan_filter_parsed,
@@ -4017,10 +4017,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set = {
.f = cmd_tx_vlan_set_parsed,
@@ -4071,13 +4071,13 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_qinq_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid_outer =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id_outer, UINT16);
+ vlan_id_outer, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set_qinq = {
.f = cmd_tx_vlan_set_qinq_parsed,
@@ -4129,10 +4129,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_pvid =
pvid, "pvid");
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_vlan_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_mode =
TOKEN_STRING_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
mode, "on#off");
@@ -4184,7 +4184,7 @@ cmdline_parse_token_string_t cmd_tx_vlan_reset_reset =
reset, "reset");
cmdline_parse_token_num_t cmd_tx_vlan_reset_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_reset = {
.f = cmd_tx_vlan_reset_parsed,
@@ -4370,7 +4370,7 @@ cmdline_parse_token_string_t cmd_csum_hwsw =
hwsw, "hw#sw");
cmdline_parse_token_num_t cmd_csum_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_set = {
.f = cmd_csum_parsed,
@@ -4441,7 +4441,7 @@ cmdline_parse_token_string_t cmd_csum_tunnel_onoff =
onoff, "on#off");
cmdline_parse_token_num_t cmd_csum_tunnel_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_tunnel_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_tunnel = {
.f = cmd_csum_tunnel_parsed,
@@ -4521,10 +4521,10 @@ cmdline_parse_token_string_t cmd_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tso_set = {
.f = cmd_tso_set_parsed,
@@ -4667,10 +4667,10 @@ cmdline_parse_token_string_t cmd_tunnel_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tunnel_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_tso_set = {
.f = cmd_tunnel_tso_set_parsed,
@@ -4734,7 +4734,7 @@ cmdline_parse_token_string_t cmd_gro_enable_port =
cmd_keyword, "port");
cmdline_parse_token_num_t cmd_gro_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_enable_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
cmd_keyword, "gro");
@@ -4784,7 +4784,7 @@ cmdline_parse_token_string_t cmd_gro_show_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_gro_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_show_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_show_result,
cmd_keyword, "gro");
@@ -4834,7 +4834,7 @@ cmdline_parse_token_string_t cmd_gro_flush_flush =
cmd_flush, "flush");
cmdline_parse_token_num_t cmd_gro_flush_cycles =
TOKEN_NUM_INITIALIZER(struct cmd_gro_flush_result,
- cmd_cycles, UINT8);
+ cmd_cycles, RTE_UINT8);
cmdline_parse_inst_t cmd_gro_flush = {
.f = cmd_gro_flush_parsed,
@@ -4884,7 +4884,7 @@ cmdline_parse_token_string_t cmd_gso_enable_mode =
cmd_mode, "on#off");
cmdline_parse_token_num_t cmd_gso_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_enable = {
.f = cmd_gso_enable_parsed,
@@ -4943,7 +4943,7 @@ cmdline_parse_token_string_t cmd_gso_size_segsz =
cmd_segsz, "segsz");
cmdline_parse_token_num_t cmd_gso_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_gso_size_result,
- cmd_size, UINT16);
+ cmd_size, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_size = {
.f = cmd_gso_size_parsed,
@@ -5001,7 +5001,7 @@ cmdline_parse_token_string_t cmd_gso_show_keyword =
cmd_keyword, "gso");
cmdline_parse_token_num_t cmd_gso_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_show = {
.f = cmd_gso_show_parsed,
@@ -5144,7 +5144,7 @@ cmdline_parse_token_string_t cmd_setbypass_mode_value =
value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_mode = {
.f = cmd_set_bypass_mode_parsed,
@@ -5250,7 +5250,7 @@ cmdline_parse_token_string_t cmd_setbypass_event_mode_value =
mode_value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_event_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_event_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_event = {
.f = cmd_set_bypass_event_parsed,
@@ -5417,7 +5417,7 @@ cmdline_parse_token_string_t cmd_showbypass_config_config =
config, "config");
cmdline_parse_token_num_t cmd_showbypass_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bypass_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bypass_config = {
.f = cmd_show_bypass_config_parsed,
@@ -5466,10 +5466,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
mode, "mode");
cmdline_parse_token_num_t cmd_setbonding_mode_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_token_num_t cmd_setbonding_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_mode = {
.f = cmd_set_bonding_mode_parsed,
@@ -5543,7 +5543,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
dedicated_queues, "dedicated_queues");
cmdline_parse_token_num_t cmd_setbonding_lacp_dedicated_queues_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_lacp_dedicated_queues_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
mode, "enable#disable");
@@ -5611,7 +5611,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
balance_xmit_policy, "balance_xmit_policy");
cmdline_parse_token_num_t cmd_setbonding_balance_xmit_policy_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_balance_xmit_policy_policy =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
policy, "l2#l23#l34");
@@ -5759,7 +5759,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_show_bonding_config_result,
config, "config");
cmdline_parse_token_num_t cmd_showbonding_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bonding_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bonding_config = {
.f = cmd_show_bonding_config_parsed,
@@ -5812,10 +5812,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_primary_result,
primary, "primary");
cmdline_parse_token_num_t cmd_setbonding_primary_slave =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setbonding_primary_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_primary = {
.f = cmd_set_bonding_primary_parsed,
@@ -5870,10 +5870,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_add_bonding_slave_result,
slave, "slave");
cmdline_parse_token_num_t cmd_addbonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_addbonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_add_bonding_slave = {
.f = cmd_add_bonding_slave_parsed,
@@ -5928,10 +5928,10 @@ cmdline_parse_token_string_t cmd_removebonding_slave_slave =
slave, "slave");
cmdline_parse_token_num_t cmd_removebonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_removebonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_remove_bonding_slave = {
.f = cmd_remove_bonding_slave_parsed,
@@ -6005,10 +6005,10 @@ cmdline_parse_token_string_t cmd_createbonded_device_device =
device, "device");
cmdline_parse_token_num_t cmd_createbonded_device_mode =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- mode, UINT8);
+ mode, RTE_UINT8);
cmdline_parse_token_num_t cmd_createbonded_device_socket =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- socket, UINT8);
+ socket, RTE_UINT8);
cmdline_parse_inst_t cmd_create_bonded_device = {
.f = cmd_create_bonded_device_parsed,
@@ -6061,7 +6061,7 @@ cmdline_parse_token_string_t cmd_set_bond_mac_addr_mac =
"mac_addr");
cmdline_parse_token_num_t cmd_set_bond_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_bond_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_bond_mac_addr_result, address);
@@ -6114,10 +6114,10 @@ cmdline_parse_token_string_t cmd_set_bond_mon_period_mon_period =
mon_period, "mon_period");
cmdline_parse_token_num_t cmd_set_bond_mon_period_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_bond_mon_period_period_ms =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- period_ms, UINT32);
+ period_ms, RTE_UINT32);
cmdline_parse_inst_t cmd_set_bond_mon_period = {
.f = cmd_set_bond_mon_period_parsed,
@@ -6176,7 +6176,7 @@ cmdline_parse_token_string_t cmd_set_bonding_agg_mode_agg_mode =
cmdline_parse_token_num_t cmd_set_bonding_agg_mode_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_agg_mode_policy_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_bonding_agg_mode_policy_string =
TOKEN_STRING_INITIALIZER(
@@ -6364,11 +6364,11 @@ cmdline_parse_token_string_t cmd_set_burst_tx_retry_tx =
cmdline_parse_token_string_t cmd_set_burst_tx_retry_delay =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, delay, "delay");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_time =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_burst_tx_retry_retry =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry, "retry");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_retry_num =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, RTE_UINT32);
cmdline_parse_inst_t cmd_set_burst_tx_retry = {
.f = cmd_set_burst_tx_retry_parsed,
@@ -6434,7 +6434,7 @@ cmdline_parse_token_string_t cmd_setpromisc_portall =
"all");
cmdline_parse_token_num_t cmd_setpromisc_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_promisc_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setpromisc_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_promisc_mode_result, mode,
"on#off");
@@ -6514,7 +6514,7 @@ cmdline_parse_token_string_t cmd_setallmulti_portall =
"all");
cmdline_parse_token_num_t cmd_setallmulti_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_allmulti_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setallmulti_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_allmulti_mode_result, mode,
"on#off");
@@ -6592,25 +6592,25 @@ cmdline_parse_token_string_t cmd_lfc_set_high_water_str =
hw_str, "high_water");
cmdline_parse_token_num_t cmd_lfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_low_water_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
lw_str, "low_water");
cmdline_parse_token_num_t cmd_lfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_pause_time_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
pt_str, "pause_time");
cmdline_parse_token_num_t cmd_lfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_send_xon_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
xon_str, "send_xon");
cmdline_parse_token_num_t cmd_lfc_set_send_xon =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- send_xon, UINT16);
+ send_xon, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_mac_ctrl_frame_fwd_mode =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
mac_ctrl_frame_fwd, "mac_ctrl_frame_fwd");
@@ -6625,7 +6625,7 @@ cmdline_parse_token_string_t cmd_lfc_set_autoneg =
autoneg, "on#off");
cmdline_parse_token_num_t cmd_lfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
/* forward declaration */
static void
@@ -6920,19 +6920,19 @@ cmdline_parse_token_string_t cmd_pfc_set_tx_mode =
tx_pfc_mode, "on#off");
cmdline_parse_token_num_t cmd_pfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_num_t cmd_pfc_set_priority =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- priority, UINT8);
+ priority, RTE_UINT8);
cmdline_parse_token_num_t cmd_pfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_priority_flow_control_set = {
.f = cmd_priority_flow_ctrl_set_parsed,
@@ -7070,7 +7070,7 @@ cmdline_parse_token_string_t cmd_start_tx_first_n_tx_first =
tx_first, "tx_first");
cmdline_parse_token_num_t cmd_start_tx_first_n_tx_num =
TOKEN_NUM_INITIALIZER(struct cmd_start_tx_first_n_result,
- tx_num, UINT32);
+ tx_num, RTE_UINT32);
cmdline_parse_inst_t cmd_start_tx_first_n = {
.f = cmd_start_tx_first_n_parsed,
@@ -7101,7 +7101,7 @@ cmdline_parse_token_string_t cmd_set_link_up_link_up =
cmdline_parse_token_string_t cmd_set_link_up_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_up_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_up_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, RTE_UINT16);
static void cmd_set_link_up_parsed(__attribute__((unused)) void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -7140,7 +7140,7 @@ cmdline_parse_token_string_t cmd_set_link_down_link_down =
cmdline_parse_token_string_t cmd_set_link_down_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_down_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_down_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, RTE_UINT16);
static void cmd_set_link_down_parsed(
__attribute__((unused)) void *parsed_result,
@@ -7327,7 +7327,7 @@ cmdline_parse_token_string_t cmd_showport_what =
TOKEN_STRING_INITIALIZER(struct cmd_showport_result, what,
"info#summary#stats#xstats#fdir#stat_qmap#dcb_tc#cap");
cmdline_parse_token_num_t cmd_showport_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, RTE_UINT16);
cmdline_parse_inst_t cmd_showport = {
.f = cmd_showport_parsed,
@@ -7373,9 +7373,9 @@ cmdline_parse_token_string_t cmd_showqueue_type =
cmdline_parse_token_string_t cmd_showqueue_what =
TOKEN_STRING_INITIALIZER(struct cmd_showqueue_result, what, "info");
cmdline_parse_token_num_t cmd_showqueue_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, RTE_UINT16);
cmdline_parse_token_num_t cmd_showqueue_queuenum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, RTE_UINT16);
cmdline_parse_inst_t cmd_showqueue = {
.f = cmd_showqueue_parsed,
@@ -7456,9 +7456,9 @@ cmdline_parse_token_string_t cmd_read_reg_read =
cmdline_parse_token_string_t cmd_read_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_read_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, RTE_UINT32);
cmdline_parse_inst_t cmd_read_reg = {
.f = cmd_read_reg_parsed,
@@ -7501,16 +7501,16 @@ cmdline_parse_token_string_t cmd_read_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_read_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit_field = {
.f = cmd_read_reg_bit_field_parsed,
@@ -7552,11 +7552,11 @@ cmdline_parse_token_string_t cmd_read_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_read_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit = {
.f = cmd_read_reg_bit_parsed,
@@ -7595,11 +7595,11 @@ cmdline_parse_token_string_t cmd_write_reg_write =
cmdline_parse_token_string_t cmd_write_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_write_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg = {
.f = cmd_write_reg_parsed,
@@ -7644,19 +7644,19 @@ cmdline_parse_token_string_t cmd_write_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_write_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_value =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg_bit_field = {
.f = cmd_write_reg_bit_field_parsed,
@@ -7702,13 +7702,13 @@ cmdline_parse_token_string_t cmd_write_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_write_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, RTE_UINT8);
cmdline_parse_inst_t cmd_write_reg_bit = {
.f = cmd_write_reg_bit_parsed,
@@ -7754,11 +7754,11 @@ cmdline_parse_token_string_t cmd_read_rxd_txd_rxd_txd =
TOKEN_STRING_INITIALIZER(struct cmd_read_rxd_txd_result, rxd_txd,
"rxd#txd");
cmdline_parse_token_num_t cmd_read_rxd_txd_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_queue_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_desc_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, RTE_UINT16);
cmdline_parse_inst_t cmd_read_rxd_txd = {
.f = cmd_read_rxd_txd_parsed,
@@ -7836,7 +7836,7 @@ cmdline_parse_token_string_t cmd_mac_addr_what =
"add#remove#set");
cmdline_parse_token_num_t cmd_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_mac_addr_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -7882,7 +7882,7 @@ cmdline_parse_token_string_t cmd_eth_peer_set =
cmdline_parse_token_string_t cmd_eth_peer =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, eth_peer, "eth-peer");
cmdline_parse_token_num_t cmd_eth_peer_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_eth_peer_addr =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, peer_addr, NULL);
@@ -7931,13 +7931,13 @@ cmdline_parse_token_string_t cmd_setqmap_what =
what, "tx#rx");
cmdline_parse_token_num_t cmd_setqmap_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_queueid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_mapvalue =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- map_value, UINT8);
+ map_value, RTE_UINT8);
cmdline_parse_inst_t cmd_set_qmap = {
.f = cmd_set_qmap_parsed,
@@ -8033,7 +8033,7 @@ cmdline_parse_token_string_t cmd_set_uc_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_hash_table,
what, "uta");
@@ -8094,7 +8094,7 @@ cmdline_parse_token_string_t cmd_set_uc_all_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_all_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_all_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_all_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_all_hash_table,
what, "uta");
@@ -8186,13 +8186,13 @@ cmdline_parse_token_string_t cmd_set_vf_macvlan_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_macvlan_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_macvlan_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_macvlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_macvlan_vf_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_set_vf_macvlan_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_macvlan_filter,
address);
@@ -8255,13 +8255,13 @@ cmdline_parse_token_string_t cmd_setvf_traffic_port =
port, "port");
cmdline_parse_token_num_t cmd_setvf_traffic_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setvf_traffic_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
vf, "vf");
cmdline_parse_token_num_t cmd_setvf_traffic_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_setvf_traffic_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
what, "tx#rx");
@@ -8343,13 +8343,13 @@ cmdline_parse_token_string_t cmd_set_vf_rxmode_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_rxmode_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_rxmode_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_rxmode_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vf_rxmode_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
what, "rxmode");
@@ -8426,13 +8426,13 @@ cmdline_parse_token_string_t cmd_vf_mac_addr_port =
port,"port");
cmdline_parse_token_num_t cmd_vf_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_mac_addr_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_mac_addr_result,
vf,"vf");
cmdline_parse_token_num_t cmd_vf_mac_addr_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_vf_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_vf_mac_addr_result,
address);
@@ -8517,19 +8517,19 @@ cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_port =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
port, "port");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vf_mask =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vf_mask, UINT64);
+ vf_mask, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rxvlan_filter = {
.f = cmd_vf_rx_vlan_filter_parsed,
@@ -8584,19 +8584,19 @@ cmdline_parse_token_string_t cmd_queue_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_queue_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_rate_limit_queue =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
queue, "queue");
cmdline_parse_token_num_t cmd_queue_rate_limit_queuenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- queue_num, UINT8);
+ queue_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_queue_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_inst_t cmd_queue_rate_limit = {
.f = cmd_queue_rate_limit_parsed,
@@ -8654,25 +8654,25 @@ cmdline_parse_token_string_t cmd_vf_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_vf_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rate_limit_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_vf_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_vf_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_q_msk =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
q_msk, "queue_mask");
cmdline_parse_token_num_t cmd_vf_rate_limit_q_msk_val =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- q_msk_val, UINT64);
+ q_msk_val, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rate_limit = {
.f = cmd_vf_rate_limit_parsed,
@@ -8794,7 +8794,7 @@ cmdline_parse_token_string_t cmd_tunnel_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_tunnel_filter_outer_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_tunnel_filter_result,
outer_mac);
@@ -8803,7 +8803,7 @@ cmdline_parse_token_etheraddr_t cmd_tunnel_filter_inner_mac =
inner_mac);
cmdline_parse_token_num_t cmd_tunnel_filter_innner_vlan =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- inner_vlan, UINT16);
+ inner_vlan, RTE_UINT16);
cmdline_parse_token_ipaddr_t cmd_tunnel_filter_ip_value =
TOKEN_IPADDR_INITIALIZER(struct cmd_tunnel_filter_result,
ip_value);
@@ -8817,10 +8817,10 @@ cmdline_parse_token_string_t cmd_tunnel_filter_filter_type =
"imac#omac-imac-tenid");
cmdline_parse_token_num_t cmd_tunnel_filter_tenant_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- tenant_id, UINT32);
+ tenant_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_tunnel_filter_queue_num =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- queue_num, UINT16);
+ queue_num, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_filter = {
.f = cmd_tunnel_filter_parsed,
@@ -8886,10 +8886,10 @@ cmdline_parse_token_string_t cmd_tunnel_udp_config_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_udp_config_udp_port =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- udp_port, UINT16);
+ udp_port, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_udp_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_udp_config = {
.f = cmd_tunnel_udp_config_parsed,
@@ -8959,7 +8959,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_config =
"config");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port,
udp_tunnel_port,
@@ -8972,7 +8972,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
"vxlan#geneve#vxlan-gpe");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
.f = cmd_cfg_tunnel_udp_port_parsed,
@@ -9021,13 +9021,13 @@ cmdline_parse_token_string_t cmd_global_config_cmd =
"global_config");
cmdline_parse_token_num_t cmd_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_global_config_type =
TOKEN_STRING_INITIALIZER(struct cmd_global_config_result,
cfg_type, "gre-key-len");
cmdline_parse_token_num_t cmd_global_config_gre_key_len =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result,
- len, UINT8);
+ len, RTE_UINT8);
cmdline_parse_inst_t cmd_global_config = {
.f = cmd_global_config_parsed,
@@ -9064,13 +9064,13 @@ cmdline_parse_token_string_t cmd_mirror_mask_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_mask_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_mask_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_mask_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
what, "pool-mirror-up#pool-mirror-down"
@@ -9083,7 +9083,7 @@ cmdline_parse_token_string_t cmd_mirror_mask_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_mask_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
on, "on#off");
@@ -9179,13 +9179,13 @@ cmdline_parse_token_string_t cmd_mirror_link_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_link_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_link_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_link_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
what, "uplink-mirror#downlink-mirror");
@@ -9194,7 +9194,7 @@ cmdline_parse_token_string_t cmd_mirror_link_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_link_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
on, "on#off");
@@ -9265,13 +9265,13 @@ cmdline_parse_token_string_t cmd_rm_mirror_rule_port =
port, "port");
cmdline_parse_token_num_t cmd_rm_mirror_rule_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rm_mirror_rule_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_rm_mirror_rule_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_rm_mirror_rule_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
static void
cmd_reset_mirror_rule_parsed(void *parsed_result,
@@ -9464,7 +9464,7 @@ cmdline_parse_token_string_t cmd_syn_filter_filter =
filter, "syn_filter");
cmdline_parse_token_num_t cmd_syn_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_syn_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_syn_filter_result,
ops, "add#del");
@@ -9479,7 +9479,7 @@ cmdline_parse_token_string_t cmd_syn_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_syn_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_syn_filter = {
.f = cmd_syn_filter_parsed,
@@ -9556,7 +9556,7 @@ cmdline_parse_token_string_t cmd_queue_region_port =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result, port, "port");
cmdline_parse_token_num_t cmd_queue_region_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
cmd, "queue-region");
@@ -9565,19 +9565,19 @@ cmdline_parse_token_string_t cmd_queue_region_id =
region, "region_id");
cmdline_parse_token_num_t cmd_queue_region_index =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_start_index =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_start_index, "queue_start_index");
cmdline_parse_token_num_t cmd_queue_region_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_id, UINT8);
+ queue_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_num =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_num, "queue_num");
cmdline_parse_token_num_t cmd_queue_region_queue_num_value =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_num_value, UINT8);
+ queue_num_value, RTE_UINT8);
cmdline_parse_inst_t cmd_queue_region = {
.f = cmd_queue_region_parsed,
@@ -9656,7 +9656,7 @@ cmdline_parse_token_string_t cmd_region_flowtype_port =
port, "port");
cmdline_parse_token_num_t cmd_region_flowtype_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_region_flowtype_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
cmd, "queue-region");
@@ -9665,13 +9665,13 @@ cmdline_parse_token_string_t cmd_region_flowtype_index =
region, "region_id");
cmdline_parse_token_num_t cmd_region_flowtype_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_region_flowtype_flow_index =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
flowtype, "flowtype");
cmdline_parse_token_num_t cmd_region_flowtype_flow_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- flowtype_id, UINT8);
+ flowtype_id, RTE_UINT8);
cmdline_parse_inst_t cmd_region_flowtype = {
.f = cmd_region_flowtype_parsed,
.data = NULL,
@@ -9747,7 +9747,7 @@ cmdline_parse_token_string_t cmd_user_priority_region_port =
port, "port");
cmdline_parse_token_num_t cmd_user_priority_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_user_priority_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
cmd, "queue-region");
@@ -9756,13 +9756,13 @@ cmdline_parse_token_string_t cmd_user_priority_region_UP =
user_priority, "UP");
cmdline_parse_token_num_t cmd_user_priority_region_UP_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- user_priority_id, UINT8);
+ user_priority_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_user_priority_region_region =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
region, "region_id");
cmdline_parse_token_num_t cmd_user_priority_region_region_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_inst_t cmd_user_priority_region = {
.f = cmd_user_priority_region_parsed,
@@ -9840,7 +9840,7 @@ cmdline_parse_token_string_t cmd_flush_queue_region_port =
port, "port");
cmdline_parse_token_num_t cmd_flush_queue_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_flush_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flush_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_flush_queue_region_result,
cmd, "queue-region");
@@ -9921,7 +9921,7 @@ cmdline_parse_token_string_t cmd_show_queue_region_info_port =
port, "port");
cmdline_parse_token_num_t cmd_show_queue_region_info_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_show_queue_region_info,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_queue_region_info_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_show_queue_region_info,
cmd, "queue-region");
@@ -10022,7 +10022,7 @@ cmdline_parse_token_string_t cmd_2tuple_filter_filter =
filter, "2tuple_filter");
cmdline_parse_token_num_t cmd_2tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
ops, "add#del");
@@ -10031,37 +10031,37 @@ cmdline_parse_token_string_t cmd_2tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_2tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_2tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_2tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_2tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_2tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_2tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_2tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_2tuple_filter = {
.f = cmd_2tuple_filter_parsed,
@@ -10201,7 +10201,7 @@ cmdline_parse_token_string_t cmd_5tuple_filter_filter =
filter, "5tuple_filter");
cmdline_parse_token_num_t cmd_5tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
ops, "add#del");
@@ -10222,43 +10222,43 @@ cmdline_parse_token_string_t cmd_5tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_5tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_src_port =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
src_port, "src_port");
cmdline_parse_token_num_t cmd_5tuple_filter_src_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- src_port_value, UINT16);
+ src_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_5tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_5tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_5tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_5tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_5tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_5tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_5tuple_filter = {
.f = cmd_5tuple_filter_parsed,
@@ -10424,7 +10424,7 @@ cmdline_parse_token_string_t cmd_flex_filter_filter =
filter, "flex_filter");
cmdline_parse_token_num_t cmd_flex_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flex_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
ops, "add#del");
@@ -10433,7 +10433,7 @@ cmdline_parse_token_string_t cmd_flex_filter_len =
len, "len");
cmdline_parse_token_num_t cmd_flex_filter_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- len_value, UINT8);
+ len_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_bytes =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
bytes, "bytes");
@@ -10451,13 +10451,13 @@ cmdline_parse_token_string_t cmd_flex_filter_priority =
priority, "priority");
cmdline_parse_token_num_t cmd_flex_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_flex_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_flex_filter = {
.f = cmd_flex_filter_parsed,
.data = NULL,
@@ -10503,7 +10503,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_filter =
filter, "ethertype_filter");
cmdline_parse_token_num_t cmd_ethertype_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
ops, "add#del");
@@ -10518,7 +10518,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_ethertype =
ethertype, "ethertype");
cmdline_parse_token_num_t cmd_ethertype_filter_ethertype_value =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- ethertype_value, UINT16);
+ ethertype_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_drop =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
drop, "drop#fwd");
@@ -10527,7 +10527,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_ethertype_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
static void
cmd_ethertype_filter_parsed(void *parsed_result,
@@ -11003,7 +11003,7 @@ cmdline_parse_token_string_t cmd_flow_director_filter =
flow_director_filter, "flow_director_filter");
cmdline_parse_token_num_t cmd_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ops, "add#del#update");
@@ -11018,7 +11018,7 @@ cmdline_parse_token_string_t cmd_flow_director_ether =
ether, "ether");
cmdline_parse_token_num_t cmd_flow_director_ether_type =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ether_type, UINT16);
+ ether_type, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
src, "src");
@@ -11027,7 +11027,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_src =
ip_src);
cmdline_parse_token_num_t cmd_flow_director_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
dst, "dst");
@@ -11036,37 +11036,37 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_dst =
ip_dst);
cmdline_parse_token_num_t cmd_flow_director_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_verify_tag =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
verify_tag, "verify_tag");
cmdline_parse_token_num_t cmd_flow_director_verify_tag_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- verify_tag_value, UINT32);
+ verify_tag_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_tos =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
tos, "tos");
cmdline_parse_token_num_t cmd_flow_director_tos_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tos_value, UINT8);
+ tos_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_proto =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
proto, "proto");
cmdline_parse_token_num_t cmd_flow_director_proto_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- proto_value, UINT8);
+ proto_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ttl, "ttl");
cmdline_parse_token_num_t cmd_flow_director_ttl_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ttl_value, UINT8);
+ ttl_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- vlan_value, UINT16);
+ vlan_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexbytes =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
flexbytes, "flexbytes");
@@ -11084,13 +11084,13 @@ cmdline_parse_token_string_t cmd_flow_director_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_flow_director_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_fd_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
fd_id, "fd_id");
cmdline_parse_token_num_t cmd_flow_director_fd_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- fd_id_value, UINT32);
+ fd_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
@@ -11124,7 +11124,7 @@ cmdline_parse_token_string_t cmd_flow_director_tunnel_id =
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tunnel_id_value, UINT32);
+ tunnel_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_packet =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
packet, "packet");
@@ -11368,7 +11368,7 @@ cmdline_parse_token_string_t cmd_flush_flow_director_flush =
flush_flow_director, "flush_flow_director");
cmdline_parse_token_num_t cmd_flush_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flush_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_flush_flow_director_parsed(void *parsed_result,
@@ -11486,13 +11486,13 @@ cmdline_parse_token_string_t cmd_flow_director_mask =
flow_director_mask, "flow_director_mask");
cmdline_parse_token_num_t cmd_flow_director_mask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_mask_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- vlan_mask, UINT16);
+ vlan_mask, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
src_mask, "src_mask");
@@ -11504,7 +11504,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_src =
ipv6_src);
cmdline_parse_token_num_t cmd_flow_director_mask_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
dst_mask, "dst_mask");
@@ -11516,7 +11516,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_dst =
ipv6_dst);
cmdline_parse_token_num_t cmd_flow_director_mask_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
@@ -11535,19 +11535,19 @@ cmdline_parse_token_string_t cmd_flow_director_mask_mac =
mac, "mac");
cmdline_parse_token_num_t cmd_flow_director_mask_mac_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- mac_addr_byte_mask, UINT8);
+ mac_addr_byte_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_type =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_type, "tunnel-type");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_type_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_type_mask, UINT8);
+ tunnel_type_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_id_mask, UINT32);
+ tunnel_id_mask, RTE_UINT32);
cmdline_parse_inst_t cmd_set_flow_director_ip_mask = {
.f = cmd_flow_director_mask_parsed,
@@ -11701,7 +11701,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexmask =
"flow_director_flex_mask");
cmdline_parse_token_num_t cmd_flow_director_flexmask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flex_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexmask_flow =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flex_mask_result,
flow, "flow");
@@ -11819,7 +11819,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexpayload =
"flow_director_flex_payload");
cmdline_parse_token_num_t cmd_flow_director_flexpayload_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flexpayload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexpayload_payload_layer =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flexpayload_result,
payload_layer, "raw#l2#l3#l4");
@@ -11887,7 +11887,7 @@ cmdline_parse_token_string_t cmd_get_sym_hash_ena_per_port_all =
get_sym_hash_ena_per_port, "get_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_get_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_sym_hash_ena_per_port = {
.f = cmd_get_sym_hash_per_port_parsed,
@@ -11943,7 +11943,7 @@ cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_all =
set_sym_hash_ena_per_port, "set_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_set_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_enable =
TOKEN_STRING_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
enable, "enable#disable");
@@ -12065,7 +12065,7 @@ cmdline_parse_token_string_t cmd_get_hash_global_config_all =
get_hash_global_config, "get_hash_global_config");
cmdline_parse_token_num_t cmd_get_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_hash_global_config = {
.f = cmd_get_hash_global_config_parsed,
@@ -12137,7 +12137,7 @@ cmdline_parse_token_string_t cmd_set_hash_global_config_all =
set_hash_global_config, "set_hash_global_config");
cmdline_parse_token_num_t cmd_set_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_global_config_hash_func =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_global_config_result,
hash_func, "toeplitz#simple_xor#default");
@@ -12253,7 +12253,7 @@ cmdline_parse_token_string_t cmd_set_hash_input_set_cmd =
set_hash_input_set, "set_hash_input_set");
cmdline_parse_token_num_t cmd_set_hash_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_input_set_result,
flow_type, NULL);
@@ -12326,7 +12326,7 @@ cmdline_parse_token_string_t cmd_set_fdir_input_set_cmd =
set_fdir_input_set, "set_fdir_input_set");
cmdline_parse_token_num_t cmd_set_fdir_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_fdir_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_fdir_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_fdir_input_set_result,
flow_type,
@@ -12399,7 +12399,7 @@ cmdline_parse_token_string_t cmd_mcast_addr_what =
TOKEN_STRING_INITIALIZER(struct cmd_mcast_addr_result, what,
"add#remove");
cmdline_parse_token_num_t cmd_mcast_addr_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mcast_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -12448,7 +12448,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
@@ -12464,7 +12464,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_eth_type =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_eth_type_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- eth_type_val, UINT16);
+ eth_type_val, RTE_UINT16);
static enum rte_eth_tunnel_type
str2fdir_l2_tunnel_type(char *string)
@@ -12582,7 +12582,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_en_dis_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
@@ -12760,7 +12760,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_port_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_tag_id_val, UINT32);
+ port_tag_id_val, RTE_UINT32);
cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12768,7 +12768,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_e_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- e_tag_id_val, UINT16);
+ e_tag_id_val, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12776,7 +12776,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
cmdline_parse_token_num_t cmd_config_e_tag_dst_pool_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- dst_pool_val, UINT8);
+ dst_pool_val, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_e_tag_port =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12784,7 +12784,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port =
cmdline_parse_token_num_t cmd_config_e_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_vf =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12792,7 +12792,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_vf =
cmdline_parse_token_num_t cmd_config_e_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
/* E-tag insertion configuration */
static void
@@ -13111,11 +13111,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
@@ -13217,11 +13217,11 @@ cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
@@ -13323,11 +13323,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_stripq_stripq =
cmdline_parse_token_num_t cmd_vf_vlan_stripq_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_stripq_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_vlan_stripq_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
@@ -13429,15 +13429,15 @@ cmdline_parse_token_string_t cmd_vf_vlan_insert_insert =
cmdline_parse_token_num_t cmd_vf_vlan_insert_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vlan_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
static void
cmd_set_vf_vlan_insert_parsed(
@@ -13527,7 +13527,7 @@ cmdline_parse_token_string_t cmd_tx_loopback_loopback =
cmdline_parse_token_num_t cmd_tx_loopback_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_loopback_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_loopback_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_loopback_result,
@@ -13627,7 +13627,7 @@ cmdline_parse_token_string_t cmd_all_queues_drop_en_drop =
cmdline_parse_token_num_t cmd_all_queues_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_all_queues_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_all_queues_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_all_queues_drop_en_result,
@@ -13719,11 +13719,11 @@ cmdline_parse_token_string_t cmd_vf_split_drop_en_drop =
cmdline_parse_token_num_t cmd_vf_split_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_split_drop_en_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_split_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_split_drop_en_result,
@@ -13813,11 +13813,11 @@ cmdline_parse_token_string_t cmd_set_vf_mac_addr_addr =
cmdline_parse_token_num_t cmd_set_vf_mac_addr_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_mac_addr_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_vf_mac_addr_mac_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_mac_addr_result,
mac_addr);
@@ -13914,7 +13914,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_on_offload =
cmdline_parse_token_num_t cmd_macsec_offload_on_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_on_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_on_on =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_on_result,
@@ -14026,7 +14026,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_off_offload =
cmdline_parse_token_num_t cmd_macsec_offload_off_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_off_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_off_off =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_off_result,
@@ -14118,7 +14118,7 @@ cmdline_parse_token_string_t cmd_macsec_sc_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
TOKEN_ETHERADDR_INITIALIZER
(struct cmd_macsec_sc_result,
@@ -14126,7 +14126,7 @@ cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
cmdline_parse_token_num_t cmd_macsec_sc_pi =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- pi, UINT16);
+ pi, RTE_UINT16);
static void
cmd_set_macsec_sc_parsed(
@@ -14210,19 +14210,19 @@ cmdline_parse_token_string_t cmd_macsec_sa_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_macsec_sa_idx =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- idx, UINT8);
+ idx, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_an =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- an, UINT8);
+ an, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_pn =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- pn, UINT32);
+ pn, RTE_UINT32);
cmdline_parse_token_string_t cmd_macsec_sa_key =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_sa_result,
@@ -14330,11 +14330,11 @@ cmdline_parse_token_string_t cmd_vf_promisc_promisc =
cmdline_parse_token_num_t cmd_vf_promisc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_promisc_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_promisc_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_promisc_result,
@@ -14420,11 +14420,11 @@ cmdline_parse_token_string_t cmd_vf_allmulti_allmulti =
cmdline_parse_token_num_t cmd_vf_allmulti_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_allmulti_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_allmulti_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_allmulti_result,
@@ -14510,11 +14510,11 @@ cmdline_parse_token_string_t cmd_set_vf_broadcast_broadcast =
cmdline_parse_token_num_t cmd_set_vf_broadcast_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_broadcast_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_broadcast_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_broadcast_result,
@@ -14604,11 +14604,11 @@ cmdline_parse_token_string_t cmd_set_vf_vlan_tag_tag =
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_vlan_tag_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
@@ -14714,19 +14714,19 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_max_bw =
cmdline_parse_token_num_t cmd_vf_tc_bw_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_no =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_no, UINT8);
+ tc_no, RTE_UINT8);
cmdline_parse_token_num_t cmd_vf_tc_bw_bw =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- bw, UINT32);
+ bw, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_tc_bw_result,
@@ -14734,7 +14734,7 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_map =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_map, UINT8);
+ tc_map, RTE_UINT8);
/* VF max bandwidth setting */
static void
@@ -15039,7 +15039,7 @@ cmdline_parse_token_string_t cmd_set_port_tm_hierarchy_default_default =
cmdline_parse_token_num_t cmd_set_port_tm_hierarchy_default_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_hierarchy_default_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_set_port_tm_hierarchy_default_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -15119,27 +15119,27 @@ cmdline_parse_token_string_t cmd_set_vxlan_vni =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vni");
cmdline_parse_token_num_t cmd_set_vxlan_vni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_vxlan_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-src");
cmdline_parse_token_num_t cmd_set_vxlan_udp_src_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-dst");
cmdline_parse_token_num_t cmd_set_vxlan_udp_dst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_ip_tos =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-tos");
cmdline_parse_token_num_t cmd_set_vxlan_ip_tos_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-ttl");
cmdline_parse_token_num_t cmd_set_vxlan_ip_ttl_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-src");
@@ -15154,7 +15154,7 @@ cmdline_parse_token_string_t cmd_set_vxlan_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_vxlan_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"eth-src");
@@ -15339,7 +15339,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_tni =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"tni");
cmdline_parse_token_num_t cmd_set_nvgre_tni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_nvgre_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"ip-src");
@@ -15354,7 +15354,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_nvgre_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_nvgre_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"eth-src");
@@ -15485,7 +15485,7 @@ cmdline_parse_token_string_t cmd_set_l2_encap_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_l2_encap_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_l2_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"eth-src");
@@ -15645,7 +15645,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "ip-src");
@@ -15661,7 +15661,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "eth-src");
@@ -15869,19 +15869,19 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-src");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_src_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_src,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-dst");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_dst_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_dst,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "ip-src");
@@ -15897,7 +15897,7 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "eth-src");
@@ -16140,7 +16140,7 @@ cmdline_parse_token_string_t cmd_ddp_add_ddp =
cmdline_parse_token_string_t cmd_ddp_add_add =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, add, "add");
cmdline_parse_token_num_t cmd_ddp_add_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_add_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, filepath, NULL);
@@ -16220,7 +16220,7 @@ cmdline_parse_token_string_t cmd_ddp_del_ddp =
cmdline_parse_token_string_t cmd_ddp_del_del =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, del, "del");
cmdline_parse_token_num_t cmd_ddp_del_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_del_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, filepath, NULL);
@@ -16527,7 +16527,7 @@ cmdline_parse_token_string_t cmd_ddp_get_list_get =
cmdline_parse_token_string_t cmd_ddp_get_list_list =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_get_list_result, list, "list");
cmdline_parse_token_num_t cmd_ddp_get_list_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, RTE_UINT16);
static void
cmd_ddp_get_list_parsed(
@@ -16676,13 +16676,13 @@ cmdline_parse_token_string_t cmd_cfg_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_cfg_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_cfg_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_cfg_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_cfg_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
inset_type,
@@ -16695,7 +16695,7 @@ cmdline_parse_token_string_t cmd_cfg_input_set_field =
field, "field");
cmdline_parse_token_num_t cmd_cfg_input_set_field_idx =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- field_idx, UINT8);
+ field_idx, RTE_UINT8);
cmdline_parse_inst_t cmd_cfg_input_set = {
.f = cmd_cfg_input_set_parsed,
@@ -16777,13 +16777,13 @@ cmdline_parse_token_string_t cmd_clear_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_clear_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_clear_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_clear_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_clear_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
inset_type,
@@ -16840,11 +16840,11 @@ cmdline_parse_token_string_t cmd_show_vf_stats_stats =
cmdline_parse_token_num_t cmd_show_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_show_vf_stats_parsed(
@@ -16949,11 +16949,11 @@ cmdline_parse_token_string_t cmd_clear_vf_stats_stats =
cmdline_parse_token_num_t cmd_clear_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_clear_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_clear_vf_stats_parsed(
@@ -17033,7 +17033,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_reset_config =
cmdline_parse_token_num_t cmd_pctype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_reset_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
@@ -17115,7 +17115,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_get_port =
cmdline_parse_token_num_t cmd_pctype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_get_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_get_result,
@@ -17219,7 +17219,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_config =
cmdline_parse_token_num_t cmd_pctype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_update_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_update_result,
@@ -17239,7 +17239,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_pc_type =
cmdline_parse_token_num_t cmd_pctype_mapping_update_flow_type =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- flow_type, UINT16);
+ flow_type, RTE_UINT16);
static void
cmd_pctype_mapping_update_parsed(
@@ -17333,11 +17333,11 @@ cmdline_parse_token_string_t cmd_ptype_mapping_get_get =
cmdline_parse_token_num_t cmd_ptype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_get_valid_only =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- valid_only, UINT8);
+ valid_only, RTE_UINT8);
static void
cmd_ptype_mapping_get_parsed(
@@ -17430,19 +17430,19 @@ cmdline_parse_token_string_t cmd_ptype_mapping_replace_replace =
cmdline_parse_token_num_t cmd_ptype_mapping_replace_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_target =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- target, UINT32);
+ target, RTE_UINT32);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_mask =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- mask, UINT8);
+ mask, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_pkt_type =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- pkt_type, UINT32);
+ pkt_type, RTE_UINT32);
static void
cmd_ptype_mapping_replace_parsed(
@@ -17524,7 +17524,7 @@ cmdline_parse_token_string_t cmd_ptype_mapping_reset_reset =
cmdline_parse_token_num_t cmd_ptype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_ptype_mapping_reset_parsed(
@@ -17597,15 +17597,15 @@ cmdline_parse_token_string_t cmd_ptype_mapping_update_update =
cmdline_parse_token_num_t cmd_ptype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_update_hw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- hw_ptype, UINT8);
+ hw_ptype, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_update_sw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- sw_ptype, UINT32);
+ sw_ptype, RTE_UINT32);
static void
cmd_ptype_mapping_update_parsed(
@@ -17716,7 +17716,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_rx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_capa_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
@@ -17809,7 +17809,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_rx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_configuration_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
@@ -17887,7 +17887,7 @@ cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -18005,7 +18005,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18013,7 +18013,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18110,7 +18110,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_tx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_capa_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
@@ -18203,7 +18203,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_tx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_configuration_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
@@ -18281,7 +18281,7 @@ cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
@@ -18406,7 +18406,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18414,7 +18414,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18527,13 +18527,13 @@ cmdline_parse_token_string_t cmd_config_tx_metadata_specific_keyword =
keyword, "config");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tx_metadata_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
item, "tx_metadata");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- value, UINT32);
+ value, RTE_UINT32);
cmdline_parse_inst_t cmd_config_tx_metadata_specific = {
.f = cmd_config_tx_metadata_specific_parsed,
@@ -18582,7 +18582,7 @@ cmdline_parse_token_string_t cmd_show_tx_metadata_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_show_tx_metadata_pid =
TOKEN_NUM_INITIALIZER(struct cmd_show_tx_metadata_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_tx_metadata_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_show_tx_metadata_result,
cmd_keyword, "tx_metadata");
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..423bf6e66 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -253,7 +253,7 @@ cmdline_parse_token_string_t cmd_show_port_meter_cap_cap =
struct cmd_show_port_meter_cap_result, cap, "cap");
cmdline_parse_token_num_t cmd_show_port_meter_cap_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_cap_result, port_id, UINT16);
+ struct cmd_show_port_meter_cap_result, port_id, RTE_UINT16);
static void cmd_show_port_meter_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -359,23 +359,23 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcm_srtcm_rfc2697 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_srtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -461,27 +461,27 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_trtcm_trtcm_rfc2698 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pir, UINT64);
+ pir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pbs, UINT64);
+ pbs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -571,27 +571,27 @@ cmdline_parse_token_string_t
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_eir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- eir, UINT64);
+ eir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_rfc4115_parsed(
void *parsed_result,
@@ -672,11 +672,11 @@ cmdline_parse_token_string_t cmd_del_port_meter_profile_profile =
cmdline_parse_token_num_t cmd_del_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
static void cmd_del_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -742,13 +742,13 @@ cmdline_parse_token_string_t cmd_create_port_meter_meter =
struct cmd_create_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_create_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, port_id, UINT16);
+ struct cmd_create_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_create_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, mtr_id, UINT32);
+ struct cmd_create_port_meter_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_create_port_meter_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, profile_id, UINT32);
+ struct cmd_create_port_meter_result, profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_meter_enable =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_enable, "yes#no");
@@ -763,10 +763,10 @@ cmdline_parse_token_string_t cmd_create_port_meter_r_action =
r_action, "R#Y#G#D#r#y#g#d");
cmdline_parse_token_num_t cmd_create_port_meter_statistics_mask =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- statistics_mask, UINT64);
+ statistics_mask, RTE_UINT64);
cmdline_parse_token_num_t cmd_create_port_meter_shared =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- shared, UINT32);
+ shared, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_input_color =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_input_color, TOKEN_STRING_MULTI);
@@ -866,10 +866,10 @@ cmdline_parse_token_string_t cmd_enable_port_meter_meter =
struct cmd_enable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_enable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, port_id, UINT16);
+ struct cmd_enable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_enable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, mtr_id, UINT32);
+ struct cmd_enable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_enable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -927,10 +927,10 @@ cmdline_parse_token_string_t cmd_disable_port_meter_meter =
struct cmd_disable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_disable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, port_id, UINT16);
+ struct cmd_disable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_disable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, mtr_id, UINT32);
+ struct cmd_disable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_disable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -988,10 +988,10 @@ cmdline_parse_token_string_t cmd_del_port_meter_meter =
struct cmd_del_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_del_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, port_id, UINT16);
+ struct cmd_del_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, mtr_id, UINT32);
+ struct cmd_del_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_del_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1054,13 +1054,13 @@ cmdline_parse_token_string_t cmd_set_port_meter_profile_profile =
struct cmd_set_port_meter_profile_result, profile, "profile");
cmdline_parse_token_num_t cmd_set_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, port_id, UINT16);
+ struct cmd_set_port_meter_profile_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_profile_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_profile_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, profile_id, UINT32);
+ struct cmd_set_port_meter_profile_result, profile_id, RTE_UINT32);
static void cmd_set_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1208,15 +1208,15 @@ cmdline_parse_token_string_t cmd_set_port_meter_policer_action_action =
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_mtr_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, mtr_id,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_action_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, action_mask,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_port_meter_policer_action_policer_action =
TOKEN_STRING_INITIALIZER(
struct cmd_set_port_meter_policer_action_result,
@@ -1316,14 +1316,14 @@ cmdline_parse_token_string_t cmd_set_port_meter_stats_mask_mask =
struct cmd_set_port_meter_stats_mask_result, mask, "mask");
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, port_id, UINT16);
+ struct cmd_set_port_meter_stats_mask_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_stats_mask_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_stats_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_stats_mask_result, stats_mask,
- UINT64);
+ RTE_UINT64);
static void cmd_set_port_meter_stats_mask_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1388,10 +1388,10 @@ cmdline_parse_token_string_t cmd_show_port_meter_stats_stats =
struct cmd_show_port_meter_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_meter_stats_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, port_id, UINT16);
+ struct cmd_show_port_meter_stats_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_meter_stats_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, mtr_id, UINT32);
+ struct cmd_show_port_meter_stats_result, mtr_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_show_port_meter_stats_clear =
TOKEN_STRING_INITIALIZER(
struct cmd_show_port_meter_stats_result, clear, "yes#no");
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 101208474..c0d846422 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -217,7 +217,7 @@ cmdline_parse_token_string_t cmd_show_port_tm_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_show_port_tm_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -354,10 +354,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_level_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
static void cmd_show_port_tm_level_cap_parsed(void *parsed_result,
@@ -481,10 +481,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -593,14 +593,14 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_stats_stats =
struct cmd_show_port_tm_node_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_stats_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_clear =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_tm_node_stats_result, clear, UINT32);
+ struct cmd_show_port_tm_node_stats_result, clear, RTE_UINT32);
static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -712,11 +712,11 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_type_type =
cmdline_parse_token_num_t cmd_show_port_tm_node_type_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_type_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_type_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -804,31 +804,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_rate, UINT64);
+ cmit_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_size, UINT64);
+ cmit_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_rate, UINT64);
+ peak_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_size, UINT64);
+ peak_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_pktlen_adjust =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- pktlen_adjust, UINT32);
+ pktlen_adjust, RTE_UINT32);
static void cmd_add_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -920,11 +920,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1001,15 +1001,15 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shaper_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_add_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1101,11 +1101,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1194,11 +1194,11 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1206,19 +1206,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_g, UINT64);
+ min_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_g, UINT64);
+ max_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_g, UINT16);
+ maxp_inv_g, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_g, UINT16);
+ wq_log2_g, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1226,19 +1226,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_y, UINT64);
+ min_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_y, UINT64);
+ max_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_y, UINT16);
+ maxp_inv_y, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_y, UINT16);
+ wq_log2_y, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1246,19 +1246,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_r, UINT64);
+ min_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_r, UINT64);
+ max_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_r, UINT16);
+ maxp_inv_r, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_r, UINT16);
+ wq_log2_r, RTE_UINT16);
static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
@@ -1374,11 +1374,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
static void cmd_del_port_tm_node_wred_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1456,15 +1456,15 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_shaper_profile_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t
cmd_set_port_tm_node_shaper_shaper_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_set_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1550,31 +1550,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_nonleaf_node_node =
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_nonleaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_n_sp_priorities =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- n_sp_priorities, UINT32);
+ n_sp_priorities, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_nonleaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
@@ -1708,34 +1708,34 @@ cmdline_parse_token_string_t cmd_add_port_tm_leaf_node_node =
struct cmd_add_port_tm_leaf_node_result, node, "node");
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_cman_mode =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- cman_mode, UINT32);
+ cman_mode, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_wred_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_leaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
@@ -1858,10 +1858,10 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_node =
struct cmd_del_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_del_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_del_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1936,19 +1936,19 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_parent_parent =
struct cmd_set_port_tm_node_parent_result, parent, "parent");
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, port_id, UINT16);
+ struct cmd_set_port_tm_node_parent_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, node_id, UINT32);
+ struct cmd_set_port_tm_node_parent_result, node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_parent_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- parent_id, UINT32);
+ parent_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_priority =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_weight =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- weight, UINT32);
+ weight, RTE_UINT32);
static void cmd_set_port_tm_node_parent_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2024,10 +2024,10 @@ cmdline_parse_token_string_t cmd_suspend_port_tm_node_node =
struct cmd_suspend_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_suspend_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, port_id, UINT16);
+ struct cmd_suspend_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_suspend_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, node_id, UINT32);
+ struct cmd_suspend_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_suspend_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2089,10 +2089,10 @@ cmdline_parse_token_string_t cmd_resume_port_tm_node_node =
struct cmd_resume_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_resume_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, port_id, UINT16);
+ struct cmd_resume_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_resume_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, node_id, UINT32);
+ struct cmd_resume_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_resume_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2156,7 +2156,7 @@ cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_commit =
cmdline_parse_token_num_t cmd_port_tm_hierarchy_commit_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_port_tm_hierarchy_commit_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_clean_on_fail =
TOKEN_STRING_INITIALIZER(struct cmd_port_tm_hierarchy_commit_result,
clean_on_fail, "yes#no");
@@ -2236,17 +2236,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_ecn_ip_ecn =
ip_ecn, "ip_ecn");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_ecn_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2323,17 +2323,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_dscp_ip_dscp =
ip_dscp, "ip_dscp");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_dscp_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2410,17 +2410,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_vlan_dei_vlan_dei =
vlan_dei, "vlan_dei");
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_vlan_dei_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
diff --git a/app/test/test_cmdline_num.c b/app/test/test_cmdline_num.c
index 4c97caf3d..71a6a7fa8 100644
--- a/app/test/test_cmdline_num.c
+++ b/app/test/test_cmdline_num.c
@@ -233,31 +233,31 @@ static int
can_parse_unsigned(uint64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX)
return 0;
break;
- case INT64:
+ case RTE_INT64:
if (expected_result > INT64_MAX)
return 0;
break;
@@ -271,31 +271,31 @@ static int
can_parse_signed(int64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX || expected_result < 0)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX || expected_result < 0)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX || expected_result < 0)
return 0;
break;
- case UINT64:
+ case RTE_UINT64:
if (expected_result < 0)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX || expected_result < INT8_MIN)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX || expected_result < INT16_MIN)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX || expected_result < INT32_MIN)
return 0;
break;
@@ -315,7 +315,7 @@ test_parse_num_invalid_param(void)
int ret = 0;
/* set up a token */
- token.num_data.type = UINT32;
+ token.num_data.type = RTE_UINT32;
/* copy string to buffer */
strlcpy(buf, num_valid_positive_strs[0].str, sizeof(buf));
@@ -388,7 +388,7 @@ test_parse_num_invalid_data(void)
cmdline_parse_token_num_t token;
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test full strings */
@@ -427,7 +427,7 @@ test_parse_num_valid(void)
/** valid strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive strings */
@@ -481,13 +481,13 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
result = (int8_t) result;
break;
- case INT16:
+ case RTE_INT16:
result = (int16_t) result;
break;
- case INT32:
+ case RTE_INT32:
result = (int32_t) result;
break;
default:
@@ -505,7 +505,7 @@ test_parse_num_valid(void)
/** garbage strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive garbage strings */
@@ -559,15 +559,15 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
if (result & (INT8_MAX + 1))
result |= 0xFFFFFFFFFFFFFF00ULL;
break;
- case INT16:
+ case RTE_INT16:
if (result & (INT16_MAX + 1))
result |= 0xFFFFFFFFFFFF0000ULL;
break;
- case INT32:
+ case RTE_INT32:
if (result & (INT32_MAX + 1ULL))
result |= 0xFFFFFFFF00000000ULL;
break;
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c..d660f441a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -192,6 +192,10 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* cmdline: the numeric types to be used when defining cmdline parameters
+ have been renamed to have an ``RTE_`` prefix. For example, ``UINT8`` now
+ becomes ``RTE_UINT8``.
+
ABI Changes
-----------
diff --git a/examples/ethtool/ethtool-app/ethapp.c b/examples/ethtool/ethtool-app/ethapp.c
index a4e64b354..22f293904 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -70,7 +70,7 @@ cmdline_parse_token_string_t pcmd_rxmode_token_cmd =
cmdline_parse_token_string_t pcmd_portstats_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "portstats");
cmdline_parse_token_num_t pcmd_int_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, RTE_UINT16);
/* Commands taking port id and string */
cmdline_parse_token_string_t pcmd_eeprom_token_cmd =
@@ -84,7 +84,7 @@ cmdline_parse_token_string_t pcmd_regs_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "regs");
cmdline_parse_token_num_t pcmd_intstr_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_intstr_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, opt, NULL);
@@ -92,7 +92,7 @@ cmdline_parse_token_string_t pcmd_intstr_token_opt =
cmdline_parse_token_string_t pcmd_macaddr_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intmac_params, cmd, "macaddr");
cmdline_parse_token_num_t pcmd_intmac_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, RTE_UINT16);
cmdline_parse_token_etheraddr_t pcmd_intmac_token_mac =
TOKEN_ETHERADDR_INITIALIZER(struct pcmd_intmac_params, mac);
@@ -106,18 +106,18 @@ cmdline_parse_token_string_t pcmd_ringparam_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intintint_params, cmd,
"ringparam");
cmdline_parse_token_num_t pcmd_intintint_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_tx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_rx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, RTE_UINT16);
/* Pause commands */
cmdline_parse_token_string_t pcmd_pause_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "pause");
cmdline_parse_token_num_t pcmd_pause_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_pause_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params,
opt, "all#tx#rx#none");
@@ -126,11 +126,11 @@ cmdline_parse_token_string_t pcmd_pause_token_opt =
cmdline_parse_token_string_t pcmd_vlan_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, cmd, "vlan");
cmdline_parse_token_num_t pcmd_vlan_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_vlan_token_mode =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, mode, "add#del");
cmdline_parse_token_num_t pcmd_vlan_token_vid =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, RTE_UINT16);
static void
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index b0a8ee23b..523b46d6b 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -516,7 +516,7 @@ cmdline_parse_token_string_t cfg_add_neigh_start =
cmdline_parse_token_string_t cfg_add_neigh_pstr =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, pstr, "port");
cmdline_parse_token_num_t cfg_add_neigh_port =
- TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, RTE_UINT16);
cmdline_parse_token_string_t cfg_add_neigh_mac =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, mac, NULL);
diff --git a/examples/qos_sched/cmdline.c b/examples/qos_sched/cmdline.c
index 15f51830c..b163b6f9f 100644
--- a/examples/qos_sched/cmdline.c
+++ b/examples/qos_sched/cmdline.c
@@ -113,7 +113,7 @@ cmdline_parse_token_string_t cmd_setqavg_param_string =
"period#n");
cmdline_parse_token_num_t cmd_setqavg_number =
TOKEN_NUM_INITIALIZER(struct cmd_setqavg_result, number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_setqavg = {
.f = cmd_setqavg_parsed,
@@ -188,10 +188,10 @@ cmdline_parse_token_string_t cmd_subportstats_subport_string =
"subport");
cmdline_parse_token_num_t cmd_subportstats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_subportstats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_subportstats = {
.f = cmd_subportstats_parsed,
@@ -236,19 +236,19 @@ cmdline_parse_token_string_t cmd_pipestats_port_string =
"port");
cmdline_parse_token_num_t cmd_pipestats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_pipestats_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_pipestats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_pipestats_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_pipestats_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_pipestats = {
.f = cmd_pipestats_parsed,
@@ -299,31 +299,31 @@ cmdline_parse_token_string_t cmd_avg_q_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_q_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_q_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_q_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_q_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_q_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_string_t cmd_avg_q_q_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, q_string,
"q");
cmdline_parse_token_num_t cmd_avg_q_q_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, q_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_q = {
.f = cmd_avg_q_parsed,
@@ -376,25 +376,25 @@ cmdline_parse_token_string_t cmd_avg_tcpipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcpipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcpipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcpipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_tcpipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcpipe_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcpipe = {
.f = cmd_avg_tcpipe_parsed,
@@ -443,19 +443,19 @@ cmdline_parse_token_string_t cmd_avg_pipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_pipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_pipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_pipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_pipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_pipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_pipe = {
.f = cmd_avg_pipe_parsed,
@@ -502,19 +502,19 @@ cmdline_parse_token_string_t cmd_avg_tcsubport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcsubport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcsubport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcsubport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcsubport_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcsubport_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcsubport = {
.f = cmd_avg_tcsubport_parsed,
@@ -559,13 +559,13 @@ cmdline_parse_token_string_t cmd_avg_subport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_subport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_subport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_subport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_subport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_subport = {
.f = cmd_avg_subport_parsed,
diff --git a/examples/quota_watermark/qwctl/commands.c b/examples/quota_watermark/qwctl/commands.c
index a1c646b9f..3f0cef7f1 100644
--- a/examples/quota_watermark/qwctl/commands.c
+++ b/examples/quota_watermark/qwctl/commands.c
@@ -74,7 +74,7 @@ cmdline_parse_token_string_t cmd_set_variable =
TOKEN_STRING_INITIALIZER(struct cmd_set_tokens, variable, NULL);
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, RTE_UINT32);
static void
cmd_set_handler(__attribute__((unused)) void *parsed_result,
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 2d9e7689a..82e1a0a03 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -160,7 +160,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_string_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- lcore_id, UINT8);
+ lcore_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/examples/vm_power_manager/vm_power_cli.c b/examples/vm_power_manager/vm_power_cli.c
index 41e89ff20..98e61a4ac 100644
--- a/examples/vm_power_manager/vm_power_cli.c
+++ b/examples/vm_power_manager/vm_power_cli.c
@@ -155,10 +155,10 @@ cmdline_parse_token_string_t cmd_set_pcpu_vm_name =
vm_name, NULL);
cmdline_parse_token_num_t set_pcpu_vcpu =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- vcpu, UINT8);
+ vcpu, RTE_UINT8);
cmdline_parse_token_num_t set_pcpu_core =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- core, UINT64);
+ core, RTE_UINT64);
cmdline_parse_inst_t cmd_set_pcpu_set = {
@@ -408,7 +408,7 @@ cmdline_parse_token_string_t cmd_show_cpu_freq =
cmdline_parse_token_num_t cmd_show_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_show_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_inst_t cmd_show_cpu_freq_set = {
.f = cmd_show_cpu_freq_parsed,
@@ -457,7 +457,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_num_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/lib/librte_cmdline/cmdline_parse_num.c b/lib/librte_cmdline/cmdline_parse_num.c
index 182ac12f0..37d094893 100644
--- a/lib/librte_cmdline/cmdline_parse_num.c
+++ b/lib/librte_cmdline/cmdline_parse_num.c
@@ -69,23 +69,23 @@ static int
check_res_size(struct cmdline_token_num_data *nd, unsigned ressize)
{
switch (nd->type) {
- case INT8:
- case UINT8:
+ case RTE_INT8:
+ case RTE_UINT8:
if (ressize < sizeof(int8_t))
return -1;
break;
- case INT16:
- case UINT16:
+ case RTE_INT16:
+ case RTE_UINT16:
if (ressize < sizeof(int16_t))
return -1;
break;
- case INT32:
- case UINT32:
+ case RTE_INT32:
+ case RTE_UINT32:
if (ressize < sizeof(int32_t))
return -1;
break;
- case INT64:
- case UINT64:
+ case RTE_INT64:
+ case RTE_UINT64:
if (ressize < sizeof(int64_t))
return -1;
break;
@@ -259,35 +259,35 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
case HEX_OK:
case OCTAL_OK:
case BIN_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX ) {
if (res) *(int8_t *)res = (int8_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= INT16_MAX ) {
+ else if ( nd.type == RTE_INT16 && res1 <= INT16_MAX ) {
if (res) *(int16_t *)res = (int16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= INT32_MAX ) {
+ else if ( nd.type == RTE_INT32 && res1 <= INT32_MAX ) {
if (res) *(int32_t *)res = (int32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= INT64_MAX ) {
+ else if ( nd.type == RTE_INT64 && res1 <= INT64_MAX ) {
if (res) *(int64_t *)res = (int64_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT8 && res1 <= UINT8_MAX ) {
+ else if ( nd.type == RTE_UINT8 && res1 <= UINT8_MAX ) {
if (res) *(uint8_t *)res = (uint8_t) res1;
return buf-srcbuf;
}
- else if (nd.type == UINT16 && res1 <= UINT16_MAX ) {
+ else if (nd.type == RTE_UINT16 && res1 <= UINT16_MAX ) {
if (res) *(uint16_t *)res = (uint16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT32 && res1 <= UINT32_MAX ) {
+ else if ( nd.type == RTE_UINT32 && res1 <= UINT32_MAX ) {
if (res) *(uint32_t *)res = (uint32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT64 ) {
+ else if ( nd.type == RTE_UINT64 ) {
if (res) *(uint64_t *)res = res1;
return buf-srcbuf;
}
@@ -297,19 +297,19 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
break;
case DEC_NEG_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX + 1 ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX + 1 ) {
if (res) *(int8_t *)res = (int8_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
+ else if ( nd.type == RTE_INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
if (res) *(int16_t *)res = (int16_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
+ else if ( nd.type == RTE_INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
if (res) *(int32_t *)res = (int32_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
+ else if ( nd.type == RTE_INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
if (res) *(int64_t *)res = (int64_t) (-res1);
return buf-srcbuf;
}
diff --git a/lib/librte_cmdline/cmdline_parse_num.h b/lib/librte_cmdline/cmdline_parse_num.h
index 58b28cad7..02133bb21 100644
--- a/lib/librte_cmdline/cmdline_parse_num.h
+++ b/lib/librte_cmdline/cmdline_parse_num.h
@@ -14,14 +14,14 @@ extern "C" {
#endif
enum cmdline_numtype {
- UINT8 = 0,
- UINT16,
- UINT32,
- UINT64,
- INT8,
- INT16,
- INT32,
- INT64
+ RTE_UINT8 = 0,
+ RTE_UINT16,
+ RTE_UINT32,
+ RTE_UINT64,
+ RTE_INT8,
+ RTE_INT16,
+ RTE_INT32,
+ RTE_INT64
};
struct cmdline_token_num_data {
--
2.20.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums
@ 2019-04-11 10:41 1% Bruce Richardson
2019-04-11 10:41 1% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-11 10:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
The cmdline defined an enum for the various numeric type parameters,
but these were missing the RTE_ prefix and so could conflict with defines
in various environments, e.g. on Windows. Adding the prefix fixes these
conflicts.
Note: this changes the API used by apps using cmdline, but since enum
values aren't changing, it's ABI compatible.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test-cmdline/commands.c | 2 +-
app/test-pmd/bpf_cmd.c | 8 +-
app/test-pmd/cmdline.c | 656 +++++++++---------
app/test-pmd/cmdline_mtr.c | 84 +--
app/test-pmd/cmdline_tm.c | 172 ++---
app/test/test_cmdline_num.c | 48 +-
doc/guides/rel_notes/release_19_05.rst | 4 +
examples/ethtool/ethtool-app/ethapp.c | 18 +-
examples/ipsec-secgw/parser.c | 2 +-
examples/qos_sched/cmdline.c | 46 +-
examples/quota_watermark/qwctl/commands.c | 2 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/vm_power_cli.c | 8 +-
lib/librte_cmdline/cmdline_parse_num.c | 40 +-
lib/librte_cmdline/cmdline_parse_num.h | 16 +-
15 files changed, 556 insertions(+), 552 deletions(-)
diff --git a/app/test-cmdline/commands.c b/app/test-cmdline/commands.c
index d81da9665..0e2ca8ac4 100644
--- a/app/test-cmdline/commands.c
+++ b/app/test-cmdline/commands.c
@@ -191,7 +191,7 @@ cmd_num_parsed(void *parsed_result,
}
cmdline_parse_token_num_t cmd_num_tok =
- TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, RTE_UINT32);
cmdline_parse_inst_t cmd_num = {
.f = cmd_num_parsed, /* function to call */
diff --git a/app/test-pmd/bpf_cmd.c b/app/test-pmd/bpf_cmd.c
index 830bfc13a..254290f30 100644
--- a/app/test-pmd/bpf_cmd.c
+++ b/app/test-pmd/bpf_cmd.c
@@ -124,9 +124,9 @@ cmdline_parse_token_string_t cmd_load_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_load_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_load_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, RTE_UINT16);
cmdline_parse_token_string_t cmd_load_bpf_flags =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
flags, NULL);
@@ -180,9 +180,9 @@ cmdline_parse_token_string_t cmd_unload_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_unld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_unload_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_unload_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_bpf_unld_parse = {
.f = cmd_operate_bpf_unld_parsed,
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ab03c111..82e67ab92 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1250,7 +1250,7 @@ cmdline_parse_token_string_t cmd_operate_specific_port_port =
name, "start#stop#close#reset");
cmdline_parse_token_num_t cmd_operate_specific_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_specific_port_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_inst_t cmd_operate_specific_port = {
.f = cmd_operate_specific_port_parsed,
@@ -1386,7 +1386,7 @@ cmdline_parse_token_string_t cmd_operate_detach_port_keyword =
keyword, "detach");
cmdline_parse_token_num_t cmd_operate_detach_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_detach_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_detach_port = {
.f = cmd_operate_detach_port_parsed,
@@ -1567,7 +1567,7 @@ cmdline_parse_token_string_t cmd_config_speed_specific_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, keyword,
"config");
cmdline_parse_token_num_t cmd_config_speed_specific_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_speed_specific_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item1,
"speed");
@@ -1639,7 +1639,7 @@ cmdline_parse_token_string_t cmd_config_loopback_all_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_all, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_all_mode =
- TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_all = {
.f = cmd_config_loopback_all_parsed,
@@ -1693,13 +1693,13 @@ cmdline_parse_token_string_t cmd_config_loopback_specific_keyword =
"config");
cmdline_parse_token_num_t cmd_config_loopback_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_loopback_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_specific, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_specific_mode =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, mode,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_specific = {
.f = cmd_config_loopback_specific_parsed,
@@ -1789,7 +1789,7 @@ cmdline_parse_token_string_t cmd_config_rx_tx_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rx_tx, name,
"rxq#txq#rxd#txd");
cmdline_parse_token_num_t cmd_config_rx_tx_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rx_tx = {
.f = cmd_config_rx_tx_parsed,
@@ -1871,7 +1871,7 @@ cmdline_parse_token_string_t cmd_config_max_pkt_len_name =
"max-pkt-len");
cmdline_parse_token_num_t cmd_config_max_pkt_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_max_pkt_len_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_max_pkt_len = {
.f = cmd_config_max_pkt_len_parsed,
@@ -1920,9 +1920,9 @@ cmdline_parse_token_string_t cmd_config_mtu_mtu =
TOKEN_STRING_INITIALIZER(struct cmd_config_mtu_result, keyword,
"mtu");
cmdline_parse_token_num_t cmd_config_mtu_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_config_mtu_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_mtu = {
.f = cmd_config_mtu_parsed,
@@ -2287,7 +2287,7 @@ cmdline_parse_token_string_t cmd_config_rss_hash_key_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key, config,
"config");
cmdline_parse_token_num_t cmd_config_rss_hash_key_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_hash_key_rss_hash_key =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key,
rss_hash_key, "rss-hash-key");
@@ -2385,19 +2385,19 @@ cmdline_parse_token_string_t cmd_config_rxtx_ring_size_config =
config, "config");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_portid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- portid, UINT16);
+ portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rsize =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rsize, "ring_size");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- size, UINT16);
+ size, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rxtx_ring_size = {
.f = cmd_config_rxtx_ring_size_parsed,
@@ -2486,11 +2486,11 @@ cmd_config_rxtx_queue_parsed(void *parsed_result,
cmdline_parse_token_string_t cmd_config_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_config_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, opname,
"start#stop");
@@ -2566,13 +2566,13 @@ cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_port =
port, "port");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
opname, "deferred_start");
@@ -2608,11 +2608,11 @@ struct cmd_setup_rxtx_queue {
cmdline_parse_token_string_t cmd_setup_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_setup =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, setup, "setup");
@@ -2819,7 +2819,7 @@ cmdline_parse_token_string_t cmd_config_rss_reta_port =
cmdline_parse_token_string_t cmd_config_rss_reta_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, keyword, "config");
cmdline_parse_token_num_t cmd_config_rss_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_reta_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, name, "rss");
cmdline_parse_token_string_t cmd_config_rss_reta_list_name =
@@ -2927,13 +2927,13 @@ cmdline_parse_token_string_t cmd_showport_reta_show =
cmdline_parse_token_string_t cmd_showport_reta_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, port, "port");
cmdline_parse_token_num_t cmd_showport_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_rss =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, rss, "rss");
cmdline_parse_token_string_t cmd_showport_reta_reta =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, reta, "reta");
cmdline_parse_token_num_t cmd_showport_reta_size =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_list_of_items =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta,
list_of_items, NULL);
@@ -2978,7 +2978,7 @@ cmdline_parse_token_string_t cmd_showport_rss_hash_show =
cmdline_parse_token_string_t cmd_showport_rss_hash_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, port, "port");
cmdline_parse_token_num_t cmd_showport_rss_hash_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_rss_hash_rss_hash =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, rss_hash,
"rss-hash");
@@ -3082,7 +3082,7 @@ cmdline_parse_token_string_t cmd_config_dcb_port =
cmdline_parse_token_string_t cmd_config_dcb_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, config, "config");
cmdline_parse_token_num_t cmd_config_dcb_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_dcb_dcb =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, dcb, "dcb");
cmdline_parse_token_string_t cmd_config_dcb_vt =
@@ -3090,7 +3090,7 @@ cmdline_parse_token_string_t cmd_config_dcb_vt =
cmdline_parse_token_string_t cmd_config_dcb_vt_en =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, vt_en, "on#off");
cmdline_parse_token_num_t cmd_config_dcb_num_tcs =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_dcb_pfc=
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, pfc, "pfc");
cmdline_parse_token_string_t cmd_config_dcb_pfc_en =
@@ -3185,7 +3185,7 @@ cmdline_parse_token_string_t cmd_config_burst_all =
cmdline_parse_token_string_t cmd_config_burst_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_burst, name, "burst");
cmdline_parse_token_num_t cmd_config_burst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_burst = {
.f = cmd_config_burst_parsed,
@@ -3254,7 +3254,7 @@ cmdline_parse_token_string_t cmd_config_thresh_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_thresh, name,
"txpt#txht#txwt#rxpt#rxht#rxwt");
cmdline_parse_token_num_t cmd_config_thresh_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, RTE_UINT8);
cmdline_parse_inst_t cmd_config_thresh = {
.f = cmd_config_thresh_parsed,
@@ -3318,7 +3318,7 @@ cmdline_parse_token_string_t cmd_config_threshold_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_threshold, name,
"txfreet#txrst#rxfreet");
cmdline_parse_token_num_t cmd_config_threshold_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_threshold = {
.f = cmd_config_threshold_parsed,
@@ -3524,7 +3524,7 @@ cmdline_parse_token_string_t cmd_setmask_mask =
TOKEN_STRING_INITIALIZER(struct cmd_setmask_result, mask,
"coremask#portmask");
cmdline_parse_token_num_t cmd_setmask_value =
- TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, UINT64);
+ TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, RTE_UINT64);
cmdline_parse_inst_t cmd_set_fwd_mask = {
.f = cmd_set_mask_parsed,
@@ -3570,7 +3570,7 @@ cmdline_parse_token_string_t cmd_set_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_result, what,
"nbport#nbcore#burst#verbose");
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_set_numbers = {
.f = cmd_set_parsed,
@@ -3618,7 +3618,7 @@ cmdline_parse_token_string_t cmd_set_log_log =
cmdline_parse_token_string_t cmd_set_log_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_log_result, type, NULL);
cmdline_parse_token_num_t cmd_set_log_level =
- TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, RTE_UINT32);
cmdline_parse_inst_t cmd_set_log = {
.f = cmd_set_log_parsed,
@@ -3752,7 +3752,7 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_all_all =
all, "all");
cmdline_parse_token_num_t cmd_rx_vlan_filter_all_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_all_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter_all = {
.f = cmd_rx_vlan_filter_all_parsed,
@@ -3914,10 +3914,10 @@ cmdline_parse_token_string_t cmd_vlan_tpid_what =
what, "tpid");
cmdline_parse_token_num_t cmd_vlan_tpid_tpid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- tp_id, UINT16);
+ tp_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vlan_tpid_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_vlan_tpid = {
.f = cmd_vlan_tpid_parsed,
@@ -3964,10 +3964,10 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter = {
.f = cmd_rx_vlan_filter_parsed,
@@ -4017,10 +4017,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set = {
.f = cmd_tx_vlan_set_parsed,
@@ -4071,13 +4071,13 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_qinq_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid_outer =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id_outer, UINT16);
+ vlan_id_outer, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set_qinq = {
.f = cmd_tx_vlan_set_qinq_parsed,
@@ -4129,10 +4129,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_pvid =
pvid, "pvid");
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_vlan_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_mode =
TOKEN_STRING_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
mode, "on#off");
@@ -4184,7 +4184,7 @@ cmdline_parse_token_string_t cmd_tx_vlan_reset_reset =
reset, "reset");
cmdline_parse_token_num_t cmd_tx_vlan_reset_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_reset = {
.f = cmd_tx_vlan_reset_parsed,
@@ -4370,7 +4370,7 @@ cmdline_parse_token_string_t cmd_csum_hwsw =
hwsw, "hw#sw");
cmdline_parse_token_num_t cmd_csum_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_set = {
.f = cmd_csum_parsed,
@@ -4441,7 +4441,7 @@ cmdline_parse_token_string_t cmd_csum_tunnel_onoff =
onoff, "on#off");
cmdline_parse_token_num_t cmd_csum_tunnel_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_tunnel_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_tunnel = {
.f = cmd_csum_tunnel_parsed,
@@ -4521,10 +4521,10 @@ cmdline_parse_token_string_t cmd_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tso_set = {
.f = cmd_tso_set_parsed,
@@ -4667,10 +4667,10 @@ cmdline_parse_token_string_t cmd_tunnel_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tunnel_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_tso_set = {
.f = cmd_tunnel_tso_set_parsed,
@@ -4734,7 +4734,7 @@ cmdline_parse_token_string_t cmd_gro_enable_port =
cmd_keyword, "port");
cmdline_parse_token_num_t cmd_gro_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_enable_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
cmd_keyword, "gro");
@@ -4784,7 +4784,7 @@ cmdline_parse_token_string_t cmd_gro_show_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_gro_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_show_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_show_result,
cmd_keyword, "gro");
@@ -4834,7 +4834,7 @@ cmdline_parse_token_string_t cmd_gro_flush_flush =
cmd_flush, "flush");
cmdline_parse_token_num_t cmd_gro_flush_cycles =
TOKEN_NUM_INITIALIZER(struct cmd_gro_flush_result,
- cmd_cycles, UINT8);
+ cmd_cycles, RTE_UINT8);
cmdline_parse_inst_t cmd_gro_flush = {
.f = cmd_gro_flush_parsed,
@@ -4884,7 +4884,7 @@ cmdline_parse_token_string_t cmd_gso_enable_mode =
cmd_mode, "on#off");
cmdline_parse_token_num_t cmd_gso_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_enable = {
.f = cmd_gso_enable_parsed,
@@ -4943,7 +4943,7 @@ cmdline_parse_token_string_t cmd_gso_size_segsz =
cmd_segsz, "segsz");
cmdline_parse_token_num_t cmd_gso_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_gso_size_result,
- cmd_size, UINT16);
+ cmd_size, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_size = {
.f = cmd_gso_size_parsed,
@@ -5001,7 +5001,7 @@ cmdline_parse_token_string_t cmd_gso_show_keyword =
cmd_keyword, "gso");
cmdline_parse_token_num_t cmd_gso_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_show = {
.f = cmd_gso_show_parsed,
@@ -5144,7 +5144,7 @@ cmdline_parse_token_string_t cmd_setbypass_mode_value =
value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_mode = {
.f = cmd_set_bypass_mode_parsed,
@@ -5250,7 +5250,7 @@ cmdline_parse_token_string_t cmd_setbypass_event_mode_value =
mode_value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_event_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_event_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_event = {
.f = cmd_set_bypass_event_parsed,
@@ -5417,7 +5417,7 @@ cmdline_parse_token_string_t cmd_showbypass_config_config =
config, "config");
cmdline_parse_token_num_t cmd_showbypass_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bypass_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bypass_config = {
.f = cmd_show_bypass_config_parsed,
@@ -5466,10 +5466,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
mode, "mode");
cmdline_parse_token_num_t cmd_setbonding_mode_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_token_num_t cmd_setbonding_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_mode = {
.f = cmd_set_bonding_mode_parsed,
@@ -5543,7 +5543,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
dedicated_queues, "dedicated_queues");
cmdline_parse_token_num_t cmd_setbonding_lacp_dedicated_queues_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_lacp_dedicated_queues_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
mode, "enable#disable");
@@ -5611,7 +5611,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
balance_xmit_policy, "balance_xmit_policy");
cmdline_parse_token_num_t cmd_setbonding_balance_xmit_policy_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_balance_xmit_policy_policy =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
policy, "l2#l23#l34");
@@ -5759,7 +5759,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_show_bonding_config_result,
config, "config");
cmdline_parse_token_num_t cmd_showbonding_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bonding_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bonding_config = {
.f = cmd_show_bonding_config_parsed,
@@ -5812,10 +5812,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_primary_result,
primary, "primary");
cmdline_parse_token_num_t cmd_setbonding_primary_slave =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setbonding_primary_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_primary = {
.f = cmd_set_bonding_primary_parsed,
@@ -5870,10 +5870,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_add_bonding_slave_result,
slave, "slave");
cmdline_parse_token_num_t cmd_addbonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_addbonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_add_bonding_slave = {
.f = cmd_add_bonding_slave_parsed,
@@ -5928,10 +5928,10 @@ cmdline_parse_token_string_t cmd_removebonding_slave_slave =
slave, "slave");
cmdline_parse_token_num_t cmd_removebonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_removebonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_remove_bonding_slave = {
.f = cmd_remove_bonding_slave_parsed,
@@ -6005,10 +6005,10 @@ cmdline_parse_token_string_t cmd_createbonded_device_device =
device, "device");
cmdline_parse_token_num_t cmd_createbonded_device_mode =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- mode, UINT8);
+ mode, RTE_UINT8);
cmdline_parse_token_num_t cmd_createbonded_device_socket =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- socket, UINT8);
+ socket, RTE_UINT8);
cmdline_parse_inst_t cmd_create_bonded_device = {
.f = cmd_create_bonded_device_parsed,
@@ -6061,7 +6061,7 @@ cmdline_parse_token_string_t cmd_set_bond_mac_addr_mac =
"mac_addr");
cmdline_parse_token_num_t cmd_set_bond_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_bond_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_bond_mac_addr_result, address);
@@ -6114,10 +6114,10 @@ cmdline_parse_token_string_t cmd_set_bond_mon_period_mon_period =
mon_period, "mon_period");
cmdline_parse_token_num_t cmd_set_bond_mon_period_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_bond_mon_period_period_ms =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- period_ms, UINT32);
+ period_ms, RTE_UINT32);
cmdline_parse_inst_t cmd_set_bond_mon_period = {
.f = cmd_set_bond_mon_period_parsed,
@@ -6176,7 +6176,7 @@ cmdline_parse_token_string_t cmd_set_bonding_agg_mode_agg_mode =
cmdline_parse_token_num_t cmd_set_bonding_agg_mode_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_agg_mode_policy_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_bonding_agg_mode_policy_string =
TOKEN_STRING_INITIALIZER(
@@ -6364,11 +6364,11 @@ cmdline_parse_token_string_t cmd_set_burst_tx_retry_tx =
cmdline_parse_token_string_t cmd_set_burst_tx_retry_delay =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, delay, "delay");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_time =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_burst_tx_retry_retry =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry, "retry");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_retry_num =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, RTE_UINT32);
cmdline_parse_inst_t cmd_set_burst_tx_retry = {
.f = cmd_set_burst_tx_retry_parsed,
@@ -6434,7 +6434,7 @@ cmdline_parse_token_string_t cmd_setpromisc_portall =
"all");
cmdline_parse_token_num_t cmd_setpromisc_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_promisc_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setpromisc_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_promisc_mode_result, mode,
"on#off");
@@ -6514,7 +6514,7 @@ cmdline_parse_token_string_t cmd_setallmulti_portall =
"all");
cmdline_parse_token_num_t cmd_setallmulti_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_allmulti_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setallmulti_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_allmulti_mode_result, mode,
"on#off");
@@ -6592,25 +6592,25 @@ cmdline_parse_token_string_t cmd_lfc_set_high_water_str =
hw_str, "high_water");
cmdline_parse_token_num_t cmd_lfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_low_water_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
lw_str, "low_water");
cmdline_parse_token_num_t cmd_lfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_pause_time_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
pt_str, "pause_time");
cmdline_parse_token_num_t cmd_lfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_send_xon_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
xon_str, "send_xon");
cmdline_parse_token_num_t cmd_lfc_set_send_xon =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- send_xon, UINT16);
+ send_xon, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_mac_ctrl_frame_fwd_mode =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
mac_ctrl_frame_fwd, "mac_ctrl_frame_fwd");
@@ -6625,7 +6625,7 @@ cmdline_parse_token_string_t cmd_lfc_set_autoneg =
autoneg, "on#off");
cmdline_parse_token_num_t cmd_lfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
/* forward declaration */
static void
@@ -6920,19 +6920,19 @@ cmdline_parse_token_string_t cmd_pfc_set_tx_mode =
tx_pfc_mode, "on#off");
cmdline_parse_token_num_t cmd_pfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_num_t cmd_pfc_set_priority =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- priority, UINT8);
+ priority, RTE_UINT8);
cmdline_parse_token_num_t cmd_pfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_priority_flow_control_set = {
.f = cmd_priority_flow_ctrl_set_parsed,
@@ -7070,7 +7070,7 @@ cmdline_parse_token_string_t cmd_start_tx_first_n_tx_first =
tx_first, "tx_first");
cmdline_parse_token_num_t cmd_start_tx_first_n_tx_num =
TOKEN_NUM_INITIALIZER(struct cmd_start_tx_first_n_result,
- tx_num, UINT32);
+ tx_num, RTE_UINT32);
cmdline_parse_inst_t cmd_start_tx_first_n = {
.f = cmd_start_tx_first_n_parsed,
@@ -7101,7 +7101,7 @@ cmdline_parse_token_string_t cmd_set_link_up_link_up =
cmdline_parse_token_string_t cmd_set_link_up_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_up_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_up_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, RTE_UINT16);
static void cmd_set_link_up_parsed(__attribute__((unused)) void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -7140,7 +7140,7 @@ cmdline_parse_token_string_t cmd_set_link_down_link_down =
cmdline_parse_token_string_t cmd_set_link_down_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_down_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_down_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, RTE_UINT16);
static void cmd_set_link_down_parsed(
__attribute__((unused)) void *parsed_result,
@@ -7327,7 +7327,7 @@ cmdline_parse_token_string_t cmd_showport_what =
TOKEN_STRING_INITIALIZER(struct cmd_showport_result, what,
"info#summary#stats#xstats#fdir#stat_qmap#dcb_tc#cap");
cmdline_parse_token_num_t cmd_showport_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, RTE_UINT16);
cmdline_parse_inst_t cmd_showport = {
.f = cmd_showport_parsed,
@@ -7373,9 +7373,9 @@ cmdline_parse_token_string_t cmd_showqueue_type =
cmdline_parse_token_string_t cmd_showqueue_what =
TOKEN_STRING_INITIALIZER(struct cmd_showqueue_result, what, "info");
cmdline_parse_token_num_t cmd_showqueue_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, RTE_UINT16);
cmdline_parse_token_num_t cmd_showqueue_queuenum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, RTE_UINT16);
cmdline_parse_inst_t cmd_showqueue = {
.f = cmd_showqueue_parsed,
@@ -7456,9 +7456,9 @@ cmdline_parse_token_string_t cmd_read_reg_read =
cmdline_parse_token_string_t cmd_read_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_read_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, RTE_UINT32);
cmdline_parse_inst_t cmd_read_reg = {
.f = cmd_read_reg_parsed,
@@ -7501,16 +7501,16 @@ cmdline_parse_token_string_t cmd_read_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_read_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit_field = {
.f = cmd_read_reg_bit_field_parsed,
@@ -7552,11 +7552,11 @@ cmdline_parse_token_string_t cmd_read_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_read_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit = {
.f = cmd_read_reg_bit_parsed,
@@ -7595,11 +7595,11 @@ cmdline_parse_token_string_t cmd_write_reg_write =
cmdline_parse_token_string_t cmd_write_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_write_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg = {
.f = cmd_write_reg_parsed,
@@ -7644,19 +7644,19 @@ cmdline_parse_token_string_t cmd_write_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_write_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_value =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg_bit_field = {
.f = cmd_write_reg_bit_field_parsed,
@@ -7702,13 +7702,13 @@ cmdline_parse_token_string_t cmd_write_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_write_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, RTE_UINT8);
cmdline_parse_inst_t cmd_write_reg_bit = {
.f = cmd_write_reg_bit_parsed,
@@ -7754,11 +7754,11 @@ cmdline_parse_token_string_t cmd_read_rxd_txd_rxd_txd =
TOKEN_STRING_INITIALIZER(struct cmd_read_rxd_txd_result, rxd_txd,
"rxd#txd");
cmdline_parse_token_num_t cmd_read_rxd_txd_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_queue_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_desc_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, RTE_UINT16);
cmdline_parse_inst_t cmd_read_rxd_txd = {
.f = cmd_read_rxd_txd_parsed,
@@ -7836,7 +7836,7 @@ cmdline_parse_token_string_t cmd_mac_addr_what =
"add#remove#set");
cmdline_parse_token_num_t cmd_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_mac_addr_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -7882,7 +7882,7 @@ cmdline_parse_token_string_t cmd_eth_peer_set =
cmdline_parse_token_string_t cmd_eth_peer =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, eth_peer, "eth-peer");
cmdline_parse_token_num_t cmd_eth_peer_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_eth_peer_addr =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, peer_addr, NULL);
@@ -7931,13 +7931,13 @@ cmdline_parse_token_string_t cmd_setqmap_what =
what, "tx#rx");
cmdline_parse_token_num_t cmd_setqmap_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_queueid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_mapvalue =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- map_value, UINT8);
+ map_value, RTE_UINT8);
cmdline_parse_inst_t cmd_set_qmap = {
.f = cmd_set_qmap_parsed,
@@ -8033,7 +8033,7 @@ cmdline_parse_token_string_t cmd_set_uc_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_hash_table,
what, "uta");
@@ -8094,7 +8094,7 @@ cmdline_parse_token_string_t cmd_set_uc_all_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_all_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_all_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_all_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_all_hash_table,
what, "uta");
@@ -8186,13 +8186,13 @@ cmdline_parse_token_string_t cmd_set_vf_macvlan_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_macvlan_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_macvlan_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_macvlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_macvlan_vf_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_set_vf_macvlan_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_macvlan_filter,
address);
@@ -8255,13 +8255,13 @@ cmdline_parse_token_string_t cmd_setvf_traffic_port =
port, "port");
cmdline_parse_token_num_t cmd_setvf_traffic_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setvf_traffic_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
vf, "vf");
cmdline_parse_token_num_t cmd_setvf_traffic_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_setvf_traffic_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
what, "tx#rx");
@@ -8343,13 +8343,13 @@ cmdline_parse_token_string_t cmd_set_vf_rxmode_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_rxmode_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_rxmode_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_rxmode_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vf_rxmode_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
what, "rxmode");
@@ -8426,13 +8426,13 @@ cmdline_parse_token_string_t cmd_vf_mac_addr_port =
port,"port");
cmdline_parse_token_num_t cmd_vf_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_mac_addr_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_mac_addr_result,
vf,"vf");
cmdline_parse_token_num_t cmd_vf_mac_addr_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_vf_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_vf_mac_addr_result,
address);
@@ -8517,19 +8517,19 @@ cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_port =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
port, "port");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vf_mask =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vf_mask, UINT64);
+ vf_mask, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rxvlan_filter = {
.f = cmd_vf_rx_vlan_filter_parsed,
@@ -8584,19 +8584,19 @@ cmdline_parse_token_string_t cmd_queue_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_queue_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_rate_limit_queue =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
queue, "queue");
cmdline_parse_token_num_t cmd_queue_rate_limit_queuenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- queue_num, UINT8);
+ queue_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_queue_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_inst_t cmd_queue_rate_limit = {
.f = cmd_queue_rate_limit_parsed,
@@ -8654,25 +8654,25 @@ cmdline_parse_token_string_t cmd_vf_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_vf_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rate_limit_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_vf_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_vf_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_q_msk =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
q_msk, "queue_mask");
cmdline_parse_token_num_t cmd_vf_rate_limit_q_msk_val =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- q_msk_val, UINT64);
+ q_msk_val, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rate_limit = {
.f = cmd_vf_rate_limit_parsed,
@@ -8794,7 +8794,7 @@ cmdline_parse_token_string_t cmd_tunnel_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_tunnel_filter_outer_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_tunnel_filter_result,
outer_mac);
@@ -8803,7 +8803,7 @@ cmdline_parse_token_etheraddr_t cmd_tunnel_filter_inner_mac =
inner_mac);
cmdline_parse_token_num_t cmd_tunnel_filter_innner_vlan =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- inner_vlan, UINT16);
+ inner_vlan, RTE_UINT16);
cmdline_parse_token_ipaddr_t cmd_tunnel_filter_ip_value =
TOKEN_IPADDR_INITIALIZER(struct cmd_tunnel_filter_result,
ip_value);
@@ -8817,10 +8817,10 @@ cmdline_parse_token_string_t cmd_tunnel_filter_filter_type =
"imac#omac-imac-tenid");
cmdline_parse_token_num_t cmd_tunnel_filter_tenant_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- tenant_id, UINT32);
+ tenant_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_tunnel_filter_queue_num =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- queue_num, UINT16);
+ queue_num, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_filter = {
.f = cmd_tunnel_filter_parsed,
@@ -8886,10 +8886,10 @@ cmdline_parse_token_string_t cmd_tunnel_udp_config_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_udp_config_udp_port =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- udp_port, UINT16);
+ udp_port, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_udp_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_udp_config = {
.f = cmd_tunnel_udp_config_parsed,
@@ -8959,7 +8959,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_config =
"config");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port,
udp_tunnel_port,
@@ -8972,7 +8972,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
"vxlan#geneve#vxlan-gpe");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
.f = cmd_cfg_tunnel_udp_port_parsed,
@@ -9021,13 +9021,13 @@ cmdline_parse_token_string_t cmd_global_config_cmd =
"global_config");
cmdline_parse_token_num_t cmd_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_global_config_type =
TOKEN_STRING_INITIALIZER(struct cmd_global_config_result,
cfg_type, "gre-key-len");
cmdline_parse_token_num_t cmd_global_config_gre_key_len =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result,
- len, UINT8);
+ len, RTE_UINT8);
cmdline_parse_inst_t cmd_global_config = {
.f = cmd_global_config_parsed,
@@ -9064,13 +9064,13 @@ cmdline_parse_token_string_t cmd_mirror_mask_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_mask_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_mask_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_mask_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
what, "pool-mirror-up#pool-mirror-down"
@@ -9083,7 +9083,7 @@ cmdline_parse_token_string_t cmd_mirror_mask_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_mask_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
on, "on#off");
@@ -9179,13 +9179,13 @@ cmdline_parse_token_string_t cmd_mirror_link_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_link_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_link_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_link_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
what, "uplink-mirror#downlink-mirror");
@@ -9194,7 +9194,7 @@ cmdline_parse_token_string_t cmd_mirror_link_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_link_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
on, "on#off");
@@ -9265,13 +9265,13 @@ cmdline_parse_token_string_t cmd_rm_mirror_rule_port =
port, "port");
cmdline_parse_token_num_t cmd_rm_mirror_rule_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rm_mirror_rule_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_rm_mirror_rule_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_rm_mirror_rule_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
static void
cmd_reset_mirror_rule_parsed(void *parsed_result,
@@ -9464,7 +9464,7 @@ cmdline_parse_token_string_t cmd_syn_filter_filter =
filter, "syn_filter");
cmdline_parse_token_num_t cmd_syn_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_syn_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_syn_filter_result,
ops, "add#del");
@@ -9479,7 +9479,7 @@ cmdline_parse_token_string_t cmd_syn_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_syn_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_syn_filter = {
.f = cmd_syn_filter_parsed,
@@ -9556,7 +9556,7 @@ cmdline_parse_token_string_t cmd_queue_region_port =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result, port, "port");
cmdline_parse_token_num_t cmd_queue_region_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
cmd, "queue-region");
@@ -9565,19 +9565,19 @@ cmdline_parse_token_string_t cmd_queue_region_id =
region, "region_id");
cmdline_parse_token_num_t cmd_queue_region_index =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_start_index =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_start_index, "queue_start_index");
cmdline_parse_token_num_t cmd_queue_region_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_id, UINT8);
+ queue_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_num =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_num, "queue_num");
cmdline_parse_token_num_t cmd_queue_region_queue_num_value =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_num_value, UINT8);
+ queue_num_value, RTE_UINT8);
cmdline_parse_inst_t cmd_queue_region = {
.f = cmd_queue_region_parsed,
@@ -9656,7 +9656,7 @@ cmdline_parse_token_string_t cmd_region_flowtype_port =
port, "port");
cmdline_parse_token_num_t cmd_region_flowtype_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_region_flowtype_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
cmd, "queue-region");
@@ -9665,13 +9665,13 @@ cmdline_parse_token_string_t cmd_region_flowtype_index =
region, "region_id");
cmdline_parse_token_num_t cmd_region_flowtype_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_region_flowtype_flow_index =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
flowtype, "flowtype");
cmdline_parse_token_num_t cmd_region_flowtype_flow_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- flowtype_id, UINT8);
+ flowtype_id, RTE_UINT8);
cmdline_parse_inst_t cmd_region_flowtype = {
.f = cmd_region_flowtype_parsed,
.data = NULL,
@@ -9747,7 +9747,7 @@ cmdline_parse_token_string_t cmd_user_priority_region_port =
port, "port");
cmdline_parse_token_num_t cmd_user_priority_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_user_priority_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
cmd, "queue-region");
@@ -9756,13 +9756,13 @@ cmdline_parse_token_string_t cmd_user_priority_region_UP =
user_priority, "UP");
cmdline_parse_token_num_t cmd_user_priority_region_UP_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- user_priority_id, UINT8);
+ user_priority_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_user_priority_region_region =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
region, "region_id");
cmdline_parse_token_num_t cmd_user_priority_region_region_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_inst_t cmd_user_priority_region = {
.f = cmd_user_priority_region_parsed,
@@ -9840,7 +9840,7 @@ cmdline_parse_token_string_t cmd_flush_queue_region_port =
port, "port");
cmdline_parse_token_num_t cmd_flush_queue_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_flush_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flush_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_flush_queue_region_result,
cmd, "queue-region");
@@ -9921,7 +9921,7 @@ cmdline_parse_token_string_t cmd_show_queue_region_info_port =
port, "port");
cmdline_parse_token_num_t cmd_show_queue_region_info_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_show_queue_region_info,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_queue_region_info_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_show_queue_region_info,
cmd, "queue-region");
@@ -10022,7 +10022,7 @@ cmdline_parse_token_string_t cmd_2tuple_filter_filter =
filter, "2tuple_filter");
cmdline_parse_token_num_t cmd_2tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
ops, "add#del");
@@ -10031,37 +10031,37 @@ cmdline_parse_token_string_t cmd_2tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_2tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_2tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_2tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_2tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_2tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_2tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_2tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_2tuple_filter = {
.f = cmd_2tuple_filter_parsed,
@@ -10201,7 +10201,7 @@ cmdline_parse_token_string_t cmd_5tuple_filter_filter =
filter, "5tuple_filter");
cmdline_parse_token_num_t cmd_5tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
ops, "add#del");
@@ -10222,43 +10222,43 @@ cmdline_parse_token_string_t cmd_5tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_5tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_src_port =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
src_port, "src_port");
cmdline_parse_token_num_t cmd_5tuple_filter_src_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- src_port_value, UINT16);
+ src_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_5tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_5tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_5tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_5tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_5tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_5tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_5tuple_filter = {
.f = cmd_5tuple_filter_parsed,
@@ -10424,7 +10424,7 @@ cmdline_parse_token_string_t cmd_flex_filter_filter =
filter, "flex_filter");
cmdline_parse_token_num_t cmd_flex_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flex_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
ops, "add#del");
@@ -10433,7 +10433,7 @@ cmdline_parse_token_string_t cmd_flex_filter_len =
len, "len");
cmdline_parse_token_num_t cmd_flex_filter_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- len_value, UINT8);
+ len_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_bytes =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
bytes, "bytes");
@@ -10451,13 +10451,13 @@ cmdline_parse_token_string_t cmd_flex_filter_priority =
priority, "priority");
cmdline_parse_token_num_t cmd_flex_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_flex_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_flex_filter = {
.f = cmd_flex_filter_parsed,
.data = NULL,
@@ -10503,7 +10503,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_filter =
filter, "ethertype_filter");
cmdline_parse_token_num_t cmd_ethertype_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
ops, "add#del");
@@ -10518,7 +10518,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_ethertype =
ethertype, "ethertype");
cmdline_parse_token_num_t cmd_ethertype_filter_ethertype_value =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- ethertype_value, UINT16);
+ ethertype_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_drop =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
drop, "drop#fwd");
@@ -10527,7 +10527,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_ethertype_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
static void
cmd_ethertype_filter_parsed(void *parsed_result,
@@ -11003,7 +11003,7 @@ cmdline_parse_token_string_t cmd_flow_director_filter =
flow_director_filter, "flow_director_filter");
cmdline_parse_token_num_t cmd_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ops, "add#del#update");
@@ -11018,7 +11018,7 @@ cmdline_parse_token_string_t cmd_flow_director_ether =
ether, "ether");
cmdline_parse_token_num_t cmd_flow_director_ether_type =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ether_type, UINT16);
+ ether_type, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
src, "src");
@@ -11027,7 +11027,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_src =
ip_src);
cmdline_parse_token_num_t cmd_flow_director_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
dst, "dst");
@@ -11036,37 +11036,37 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_dst =
ip_dst);
cmdline_parse_token_num_t cmd_flow_director_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_verify_tag =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
verify_tag, "verify_tag");
cmdline_parse_token_num_t cmd_flow_director_verify_tag_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- verify_tag_value, UINT32);
+ verify_tag_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_tos =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
tos, "tos");
cmdline_parse_token_num_t cmd_flow_director_tos_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tos_value, UINT8);
+ tos_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_proto =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
proto, "proto");
cmdline_parse_token_num_t cmd_flow_director_proto_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- proto_value, UINT8);
+ proto_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ttl, "ttl");
cmdline_parse_token_num_t cmd_flow_director_ttl_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ttl_value, UINT8);
+ ttl_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- vlan_value, UINT16);
+ vlan_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexbytes =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
flexbytes, "flexbytes");
@@ -11084,13 +11084,13 @@ cmdline_parse_token_string_t cmd_flow_director_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_flow_director_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_fd_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
fd_id, "fd_id");
cmdline_parse_token_num_t cmd_flow_director_fd_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- fd_id_value, UINT32);
+ fd_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
@@ -11124,7 +11124,7 @@ cmdline_parse_token_string_t cmd_flow_director_tunnel_id =
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tunnel_id_value, UINT32);
+ tunnel_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_packet =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
packet, "packet");
@@ -11368,7 +11368,7 @@ cmdline_parse_token_string_t cmd_flush_flow_director_flush =
flush_flow_director, "flush_flow_director");
cmdline_parse_token_num_t cmd_flush_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flush_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_flush_flow_director_parsed(void *parsed_result,
@@ -11486,13 +11486,13 @@ cmdline_parse_token_string_t cmd_flow_director_mask =
flow_director_mask, "flow_director_mask");
cmdline_parse_token_num_t cmd_flow_director_mask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_mask_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- vlan_mask, UINT16);
+ vlan_mask, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
src_mask, "src_mask");
@@ -11504,7 +11504,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_src =
ipv6_src);
cmdline_parse_token_num_t cmd_flow_director_mask_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
dst_mask, "dst_mask");
@@ -11516,7 +11516,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_dst =
ipv6_dst);
cmdline_parse_token_num_t cmd_flow_director_mask_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
@@ -11535,19 +11535,19 @@ cmdline_parse_token_string_t cmd_flow_director_mask_mac =
mac, "mac");
cmdline_parse_token_num_t cmd_flow_director_mask_mac_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- mac_addr_byte_mask, UINT8);
+ mac_addr_byte_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_type =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_type, "tunnel-type");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_type_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_type_mask, UINT8);
+ tunnel_type_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_id_mask, UINT32);
+ tunnel_id_mask, RTE_UINT32);
cmdline_parse_inst_t cmd_set_flow_director_ip_mask = {
.f = cmd_flow_director_mask_parsed,
@@ -11701,7 +11701,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexmask =
"flow_director_flex_mask");
cmdline_parse_token_num_t cmd_flow_director_flexmask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flex_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexmask_flow =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flex_mask_result,
flow, "flow");
@@ -11819,7 +11819,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexpayload =
"flow_director_flex_payload");
cmdline_parse_token_num_t cmd_flow_director_flexpayload_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flexpayload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexpayload_payload_layer =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flexpayload_result,
payload_layer, "raw#l2#l3#l4");
@@ -11887,7 +11887,7 @@ cmdline_parse_token_string_t cmd_get_sym_hash_ena_per_port_all =
get_sym_hash_ena_per_port, "get_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_get_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_sym_hash_ena_per_port = {
.f = cmd_get_sym_hash_per_port_parsed,
@@ -11943,7 +11943,7 @@ cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_all =
set_sym_hash_ena_per_port, "set_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_set_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_enable =
TOKEN_STRING_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
enable, "enable#disable");
@@ -12065,7 +12065,7 @@ cmdline_parse_token_string_t cmd_get_hash_global_config_all =
get_hash_global_config, "get_hash_global_config");
cmdline_parse_token_num_t cmd_get_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_hash_global_config = {
.f = cmd_get_hash_global_config_parsed,
@@ -12137,7 +12137,7 @@ cmdline_parse_token_string_t cmd_set_hash_global_config_all =
set_hash_global_config, "set_hash_global_config");
cmdline_parse_token_num_t cmd_set_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_global_config_hash_func =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_global_config_result,
hash_func, "toeplitz#simple_xor#default");
@@ -12253,7 +12253,7 @@ cmdline_parse_token_string_t cmd_set_hash_input_set_cmd =
set_hash_input_set, "set_hash_input_set");
cmdline_parse_token_num_t cmd_set_hash_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_input_set_result,
flow_type, NULL);
@@ -12326,7 +12326,7 @@ cmdline_parse_token_string_t cmd_set_fdir_input_set_cmd =
set_fdir_input_set, "set_fdir_input_set");
cmdline_parse_token_num_t cmd_set_fdir_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_fdir_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_fdir_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_fdir_input_set_result,
flow_type,
@@ -12399,7 +12399,7 @@ cmdline_parse_token_string_t cmd_mcast_addr_what =
TOKEN_STRING_INITIALIZER(struct cmd_mcast_addr_result, what,
"add#remove");
cmdline_parse_token_num_t cmd_mcast_addr_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mcast_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -12448,7 +12448,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
@@ -12464,7 +12464,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_eth_type =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_eth_type_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- eth_type_val, UINT16);
+ eth_type_val, RTE_UINT16);
static enum rte_eth_tunnel_type
str2fdir_l2_tunnel_type(char *string)
@@ -12582,7 +12582,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_en_dis_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
@@ -12760,7 +12760,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_port_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_tag_id_val, UINT32);
+ port_tag_id_val, RTE_UINT32);
cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12768,7 +12768,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_e_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- e_tag_id_val, UINT16);
+ e_tag_id_val, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12776,7 +12776,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
cmdline_parse_token_num_t cmd_config_e_tag_dst_pool_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- dst_pool_val, UINT8);
+ dst_pool_val, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_e_tag_port =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12784,7 +12784,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port =
cmdline_parse_token_num_t cmd_config_e_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_vf =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12792,7 +12792,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_vf =
cmdline_parse_token_num_t cmd_config_e_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
/* E-tag insertion configuration */
static void
@@ -13111,11 +13111,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
@@ -13217,11 +13217,11 @@ cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
@@ -13323,11 +13323,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_stripq_stripq =
cmdline_parse_token_num_t cmd_vf_vlan_stripq_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_stripq_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_vlan_stripq_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
@@ -13429,15 +13429,15 @@ cmdline_parse_token_string_t cmd_vf_vlan_insert_insert =
cmdline_parse_token_num_t cmd_vf_vlan_insert_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vlan_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
static void
cmd_set_vf_vlan_insert_parsed(
@@ -13527,7 +13527,7 @@ cmdline_parse_token_string_t cmd_tx_loopback_loopback =
cmdline_parse_token_num_t cmd_tx_loopback_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_loopback_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_loopback_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_loopback_result,
@@ -13627,7 +13627,7 @@ cmdline_parse_token_string_t cmd_all_queues_drop_en_drop =
cmdline_parse_token_num_t cmd_all_queues_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_all_queues_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_all_queues_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_all_queues_drop_en_result,
@@ -13719,11 +13719,11 @@ cmdline_parse_token_string_t cmd_vf_split_drop_en_drop =
cmdline_parse_token_num_t cmd_vf_split_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_split_drop_en_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_split_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_split_drop_en_result,
@@ -13813,11 +13813,11 @@ cmdline_parse_token_string_t cmd_set_vf_mac_addr_addr =
cmdline_parse_token_num_t cmd_set_vf_mac_addr_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_mac_addr_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_vf_mac_addr_mac_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_mac_addr_result,
mac_addr);
@@ -13914,7 +13914,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_on_offload =
cmdline_parse_token_num_t cmd_macsec_offload_on_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_on_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_on_on =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_on_result,
@@ -14026,7 +14026,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_off_offload =
cmdline_parse_token_num_t cmd_macsec_offload_off_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_off_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_off_off =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_off_result,
@@ -14118,7 +14118,7 @@ cmdline_parse_token_string_t cmd_macsec_sc_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
TOKEN_ETHERADDR_INITIALIZER
(struct cmd_macsec_sc_result,
@@ -14126,7 +14126,7 @@ cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
cmdline_parse_token_num_t cmd_macsec_sc_pi =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- pi, UINT16);
+ pi, RTE_UINT16);
static void
cmd_set_macsec_sc_parsed(
@@ -14210,19 +14210,19 @@ cmdline_parse_token_string_t cmd_macsec_sa_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_macsec_sa_idx =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- idx, UINT8);
+ idx, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_an =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- an, UINT8);
+ an, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_pn =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- pn, UINT32);
+ pn, RTE_UINT32);
cmdline_parse_token_string_t cmd_macsec_sa_key =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_sa_result,
@@ -14330,11 +14330,11 @@ cmdline_parse_token_string_t cmd_vf_promisc_promisc =
cmdline_parse_token_num_t cmd_vf_promisc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_promisc_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_promisc_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_promisc_result,
@@ -14420,11 +14420,11 @@ cmdline_parse_token_string_t cmd_vf_allmulti_allmulti =
cmdline_parse_token_num_t cmd_vf_allmulti_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_allmulti_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_allmulti_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_allmulti_result,
@@ -14510,11 +14510,11 @@ cmdline_parse_token_string_t cmd_set_vf_broadcast_broadcast =
cmdline_parse_token_num_t cmd_set_vf_broadcast_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_broadcast_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_broadcast_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_broadcast_result,
@@ -14604,11 +14604,11 @@ cmdline_parse_token_string_t cmd_set_vf_vlan_tag_tag =
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_vlan_tag_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
@@ -14714,19 +14714,19 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_max_bw =
cmdline_parse_token_num_t cmd_vf_tc_bw_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_no =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_no, UINT8);
+ tc_no, RTE_UINT8);
cmdline_parse_token_num_t cmd_vf_tc_bw_bw =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- bw, UINT32);
+ bw, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_tc_bw_result,
@@ -14734,7 +14734,7 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_map =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_map, UINT8);
+ tc_map, RTE_UINT8);
/* VF max bandwidth setting */
static void
@@ -15039,7 +15039,7 @@ cmdline_parse_token_string_t cmd_set_port_tm_hierarchy_default_default =
cmdline_parse_token_num_t cmd_set_port_tm_hierarchy_default_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_hierarchy_default_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_set_port_tm_hierarchy_default_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -15119,27 +15119,27 @@ cmdline_parse_token_string_t cmd_set_vxlan_vni =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vni");
cmdline_parse_token_num_t cmd_set_vxlan_vni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_vxlan_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-src");
cmdline_parse_token_num_t cmd_set_vxlan_udp_src_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-dst");
cmdline_parse_token_num_t cmd_set_vxlan_udp_dst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_ip_tos =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-tos");
cmdline_parse_token_num_t cmd_set_vxlan_ip_tos_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-ttl");
cmdline_parse_token_num_t cmd_set_vxlan_ip_ttl_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-src");
@@ -15154,7 +15154,7 @@ cmdline_parse_token_string_t cmd_set_vxlan_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_vxlan_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"eth-src");
@@ -15339,7 +15339,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_tni =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"tni");
cmdline_parse_token_num_t cmd_set_nvgre_tni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_nvgre_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"ip-src");
@@ -15354,7 +15354,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_nvgre_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_nvgre_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"eth-src");
@@ -15485,7 +15485,7 @@ cmdline_parse_token_string_t cmd_set_l2_encap_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_l2_encap_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_l2_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"eth-src");
@@ -15645,7 +15645,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "ip-src");
@@ -15661,7 +15661,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "eth-src");
@@ -15869,19 +15869,19 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-src");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_src_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_src,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-dst");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_dst_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_dst,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "ip-src");
@@ -15897,7 +15897,7 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "eth-src");
@@ -16140,7 +16140,7 @@ cmdline_parse_token_string_t cmd_ddp_add_ddp =
cmdline_parse_token_string_t cmd_ddp_add_add =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, add, "add");
cmdline_parse_token_num_t cmd_ddp_add_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_add_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, filepath, NULL);
@@ -16220,7 +16220,7 @@ cmdline_parse_token_string_t cmd_ddp_del_ddp =
cmdline_parse_token_string_t cmd_ddp_del_del =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, del, "del");
cmdline_parse_token_num_t cmd_ddp_del_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_del_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, filepath, NULL);
@@ -16527,7 +16527,7 @@ cmdline_parse_token_string_t cmd_ddp_get_list_get =
cmdline_parse_token_string_t cmd_ddp_get_list_list =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_get_list_result, list, "list");
cmdline_parse_token_num_t cmd_ddp_get_list_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, RTE_UINT16);
static void
cmd_ddp_get_list_parsed(
@@ -16676,13 +16676,13 @@ cmdline_parse_token_string_t cmd_cfg_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_cfg_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_cfg_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_cfg_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_cfg_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
inset_type,
@@ -16695,7 +16695,7 @@ cmdline_parse_token_string_t cmd_cfg_input_set_field =
field, "field");
cmdline_parse_token_num_t cmd_cfg_input_set_field_idx =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- field_idx, UINT8);
+ field_idx, RTE_UINT8);
cmdline_parse_inst_t cmd_cfg_input_set = {
.f = cmd_cfg_input_set_parsed,
@@ -16777,13 +16777,13 @@ cmdline_parse_token_string_t cmd_clear_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_clear_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_clear_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_clear_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_clear_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
inset_type,
@@ -16840,11 +16840,11 @@ cmdline_parse_token_string_t cmd_show_vf_stats_stats =
cmdline_parse_token_num_t cmd_show_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_show_vf_stats_parsed(
@@ -16949,11 +16949,11 @@ cmdline_parse_token_string_t cmd_clear_vf_stats_stats =
cmdline_parse_token_num_t cmd_clear_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_clear_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_clear_vf_stats_parsed(
@@ -17033,7 +17033,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_reset_config =
cmdline_parse_token_num_t cmd_pctype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_reset_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
@@ -17115,7 +17115,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_get_port =
cmdline_parse_token_num_t cmd_pctype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_get_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_get_result,
@@ -17219,7 +17219,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_config =
cmdline_parse_token_num_t cmd_pctype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_update_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_update_result,
@@ -17239,7 +17239,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_pc_type =
cmdline_parse_token_num_t cmd_pctype_mapping_update_flow_type =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- flow_type, UINT16);
+ flow_type, RTE_UINT16);
static void
cmd_pctype_mapping_update_parsed(
@@ -17333,11 +17333,11 @@ cmdline_parse_token_string_t cmd_ptype_mapping_get_get =
cmdline_parse_token_num_t cmd_ptype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_get_valid_only =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- valid_only, UINT8);
+ valid_only, RTE_UINT8);
static void
cmd_ptype_mapping_get_parsed(
@@ -17430,19 +17430,19 @@ cmdline_parse_token_string_t cmd_ptype_mapping_replace_replace =
cmdline_parse_token_num_t cmd_ptype_mapping_replace_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_target =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- target, UINT32);
+ target, RTE_UINT32);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_mask =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- mask, UINT8);
+ mask, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_pkt_type =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- pkt_type, UINT32);
+ pkt_type, RTE_UINT32);
static void
cmd_ptype_mapping_replace_parsed(
@@ -17524,7 +17524,7 @@ cmdline_parse_token_string_t cmd_ptype_mapping_reset_reset =
cmdline_parse_token_num_t cmd_ptype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_ptype_mapping_reset_parsed(
@@ -17597,15 +17597,15 @@ cmdline_parse_token_string_t cmd_ptype_mapping_update_update =
cmdline_parse_token_num_t cmd_ptype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_update_hw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- hw_ptype, UINT8);
+ hw_ptype, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_update_sw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- sw_ptype, UINT32);
+ sw_ptype, RTE_UINT32);
static void
cmd_ptype_mapping_update_parsed(
@@ -17716,7 +17716,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_rx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_capa_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
@@ -17809,7 +17809,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_rx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_configuration_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
@@ -17887,7 +17887,7 @@ cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -18005,7 +18005,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18013,7 +18013,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18110,7 +18110,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_tx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_capa_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
@@ -18203,7 +18203,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_tx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_configuration_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
@@ -18281,7 +18281,7 @@ cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
@@ -18406,7 +18406,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18414,7 +18414,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18527,13 +18527,13 @@ cmdline_parse_token_string_t cmd_config_tx_metadata_specific_keyword =
keyword, "config");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tx_metadata_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
item, "tx_metadata");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- value, UINT32);
+ value, RTE_UINT32);
cmdline_parse_inst_t cmd_config_tx_metadata_specific = {
.f = cmd_config_tx_metadata_specific_parsed,
@@ -18582,7 +18582,7 @@ cmdline_parse_token_string_t cmd_show_tx_metadata_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_show_tx_metadata_pid =
TOKEN_NUM_INITIALIZER(struct cmd_show_tx_metadata_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_tx_metadata_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_show_tx_metadata_result,
cmd_keyword, "tx_metadata");
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..423bf6e66 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -253,7 +253,7 @@ cmdline_parse_token_string_t cmd_show_port_meter_cap_cap =
struct cmd_show_port_meter_cap_result, cap, "cap");
cmdline_parse_token_num_t cmd_show_port_meter_cap_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_cap_result, port_id, UINT16);
+ struct cmd_show_port_meter_cap_result, port_id, RTE_UINT16);
static void cmd_show_port_meter_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -359,23 +359,23 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcm_srtcm_rfc2697 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_srtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -461,27 +461,27 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_trtcm_trtcm_rfc2698 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pir, UINT64);
+ pir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pbs, UINT64);
+ pbs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -571,27 +571,27 @@ cmdline_parse_token_string_t
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_eir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- eir, UINT64);
+ eir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_rfc4115_parsed(
void *parsed_result,
@@ -672,11 +672,11 @@ cmdline_parse_token_string_t cmd_del_port_meter_profile_profile =
cmdline_parse_token_num_t cmd_del_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
static void cmd_del_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -742,13 +742,13 @@ cmdline_parse_token_string_t cmd_create_port_meter_meter =
struct cmd_create_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_create_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, port_id, UINT16);
+ struct cmd_create_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_create_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, mtr_id, UINT32);
+ struct cmd_create_port_meter_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_create_port_meter_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, profile_id, UINT32);
+ struct cmd_create_port_meter_result, profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_meter_enable =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_enable, "yes#no");
@@ -763,10 +763,10 @@ cmdline_parse_token_string_t cmd_create_port_meter_r_action =
r_action, "R#Y#G#D#r#y#g#d");
cmdline_parse_token_num_t cmd_create_port_meter_statistics_mask =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- statistics_mask, UINT64);
+ statistics_mask, RTE_UINT64);
cmdline_parse_token_num_t cmd_create_port_meter_shared =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- shared, UINT32);
+ shared, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_input_color =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_input_color, TOKEN_STRING_MULTI);
@@ -866,10 +866,10 @@ cmdline_parse_token_string_t cmd_enable_port_meter_meter =
struct cmd_enable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_enable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, port_id, UINT16);
+ struct cmd_enable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_enable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, mtr_id, UINT32);
+ struct cmd_enable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_enable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -927,10 +927,10 @@ cmdline_parse_token_string_t cmd_disable_port_meter_meter =
struct cmd_disable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_disable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, port_id, UINT16);
+ struct cmd_disable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_disable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, mtr_id, UINT32);
+ struct cmd_disable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_disable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -988,10 +988,10 @@ cmdline_parse_token_string_t cmd_del_port_meter_meter =
struct cmd_del_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_del_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, port_id, UINT16);
+ struct cmd_del_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, mtr_id, UINT32);
+ struct cmd_del_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_del_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1054,13 +1054,13 @@ cmdline_parse_token_string_t cmd_set_port_meter_profile_profile =
struct cmd_set_port_meter_profile_result, profile, "profile");
cmdline_parse_token_num_t cmd_set_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, port_id, UINT16);
+ struct cmd_set_port_meter_profile_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_profile_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_profile_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, profile_id, UINT32);
+ struct cmd_set_port_meter_profile_result, profile_id, RTE_UINT32);
static void cmd_set_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1208,15 +1208,15 @@ cmdline_parse_token_string_t cmd_set_port_meter_policer_action_action =
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_mtr_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, mtr_id,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_action_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, action_mask,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_port_meter_policer_action_policer_action =
TOKEN_STRING_INITIALIZER(
struct cmd_set_port_meter_policer_action_result,
@@ -1316,14 +1316,14 @@ cmdline_parse_token_string_t cmd_set_port_meter_stats_mask_mask =
struct cmd_set_port_meter_stats_mask_result, mask, "mask");
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, port_id, UINT16);
+ struct cmd_set_port_meter_stats_mask_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_stats_mask_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_stats_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_stats_mask_result, stats_mask,
- UINT64);
+ RTE_UINT64);
static void cmd_set_port_meter_stats_mask_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1388,10 +1388,10 @@ cmdline_parse_token_string_t cmd_show_port_meter_stats_stats =
struct cmd_show_port_meter_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_meter_stats_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, port_id, UINT16);
+ struct cmd_show_port_meter_stats_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_meter_stats_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, mtr_id, UINT32);
+ struct cmd_show_port_meter_stats_result, mtr_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_show_port_meter_stats_clear =
TOKEN_STRING_INITIALIZER(
struct cmd_show_port_meter_stats_result, clear, "yes#no");
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 101208474..c0d846422 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -217,7 +217,7 @@ cmdline_parse_token_string_t cmd_show_port_tm_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_show_port_tm_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -354,10 +354,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_level_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
static void cmd_show_port_tm_level_cap_parsed(void *parsed_result,
@@ -481,10 +481,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -593,14 +593,14 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_stats_stats =
struct cmd_show_port_tm_node_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_stats_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_clear =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_tm_node_stats_result, clear, UINT32);
+ struct cmd_show_port_tm_node_stats_result, clear, RTE_UINT32);
static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -712,11 +712,11 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_type_type =
cmdline_parse_token_num_t cmd_show_port_tm_node_type_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_type_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_type_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -804,31 +804,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_rate, UINT64);
+ cmit_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_size, UINT64);
+ cmit_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_rate, UINT64);
+ peak_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_size, UINT64);
+ peak_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_pktlen_adjust =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- pktlen_adjust, UINT32);
+ pktlen_adjust, RTE_UINT32);
static void cmd_add_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -920,11 +920,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1001,15 +1001,15 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shaper_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_add_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1101,11 +1101,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1194,11 +1194,11 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1206,19 +1206,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_g, UINT64);
+ min_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_g, UINT64);
+ max_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_g, UINT16);
+ maxp_inv_g, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_g, UINT16);
+ wq_log2_g, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1226,19 +1226,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_y, UINT64);
+ min_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_y, UINT64);
+ max_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_y, UINT16);
+ maxp_inv_y, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_y, UINT16);
+ wq_log2_y, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1246,19 +1246,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_r, UINT64);
+ min_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_r, UINT64);
+ max_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_r, UINT16);
+ maxp_inv_r, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_r, UINT16);
+ wq_log2_r, RTE_UINT16);
static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
@@ -1374,11 +1374,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
static void cmd_del_port_tm_node_wred_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1456,15 +1456,15 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_shaper_profile_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t
cmd_set_port_tm_node_shaper_shaper_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_set_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1550,31 +1550,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_nonleaf_node_node =
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_nonleaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_n_sp_priorities =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- n_sp_priorities, UINT32);
+ n_sp_priorities, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_nonleaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
@@ -1708,34 +1708,34 @@ cmdline_parse_token_string_t cmd_add_port_tm_leaf_node_node =
struct cmd_add_port_tm_leaf_node_result, node, "node");
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_cman_mode =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- cman_mode, UINT32);
+ cman_mode, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_wred_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_leaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
@@ -1858,10 +1858,10 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_node =
struct cmd_del_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_del_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_del_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1936,19 +1936,19 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_parent_parent =
struct cmd_set_port_tm_node_parent_result, parent, "parent");
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, port_id, UINT16);
+ struct cmd_set_port_tm_node_parent_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, node_id, UINT32);
+ struct cmd_set_port_tm_node_parent_result, node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_parent_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- parent_id, UINT32);
+ parent_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_priority =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_weight =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- weight, UINT32);
+ weight, RTE_UINT32);
static void cmd_set_port_tm_node_parent_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2024,10 +2024,10 @@ cmdline_parse_token_string_t cmd_suspend_port_tm_node_node =
struct cmd_suspend_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_suspend_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, port_id, UINT16);
+ struct cmd_suspend_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_suspend_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, node_id, UINT32);
+ struct cmd_suspend_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_suspend_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2089,10 +2089,10 @@ cmdline_parse_token_string_t cmd_resume_port_tm_node_node =
struct cmd_resume_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_resume_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, port_id, UINT16);
+ struct cmd_resume_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_resume_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, node_id, UINT32);
+ struct cmd_resume_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_resume_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2156,7 +2156,7 @@ cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_commit =
cmdline_parse_token_num_t cmd_port_tm_hierarchy_commit_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_port_tm_hierarchy_commit_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_clean_on_fail =
TOKEN_STRING_INITIALIZER(struct cmd_port_tm_hierarchy_commit_result,
clean_on_fail, "yes#no");
@@ -2236,17 +2236,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_ecn_ip_ecn =
ip_ecn, "ip_ecn");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_ecn_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2323,17 +2323,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_dscp_ip_dscp =
ip_dscp, "ip_dscp");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_dscp_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2410,17 +2410,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_vlan_dei_vlan_dei =
vlan_dei, "vlan_dei");
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_vlan_dei_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
diff --git a/app/test/test_cmdline_num.c b/app/test/test_cmdline_num.c
index 4c97caf3d..71a6a7fa8 100644
--- a/app/test/test_cmdline_num.c
+++ b/app/test/test_cmdline_num.c
@@ -233,31 +233,31 @@ static int
can_parse_unsigned(uint64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX)
return 0;
break;
- case INT64:
+ case RTE_INT64:
if (expected_result > INT64_MAX)
return 0;
break;
@@ -271,31 +271,31 @@ static int
can_parse_signed(int64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX || expected_result < 0)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX || expected_result < 0)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX || expected_result < 0)
return 0;
break;
- case UINT64:
+ case RTE_UINT64:
if (expected_result < 0)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX || expected_result < INT8_MIN)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX || expected_result < INT16_MIN)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX || expected_result < INT32_MIN)
return 0;
break;
@@ -315,7 +315,7 @@ test_parse_num_invalid_param(void)
int ret = 0;
/* set up a token */
- token.num_data.type = UINT32;
+ token.num_data.type = RTE_UINT32;
/* copy string to buffer */
strlcpy(buf, num_valid_positive_strs[0].str, sizeof(buf));
@@ -388,7 +388,7 @@ test_parse_num_invalid_data(void)
cmdline_parse_token_num_t token;
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test full strings */
@@ -427,7 +427,7 @@ test_parse_num_valid(void)
/** valid strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive strings */
@@ -481,13 +481,13 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
result = (int8_t) result;
break;
- case INT16:
+ case RTE_INT16:
result = (int16_t) result;
break;
- case INT32:
+ case RTE_INT32:
result = (int32_t) result;
break;
default:
@@ -505,7 +505,7 @@ test_parse_num_valid(void)
/** garbage strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive garbage strings */
@@ -559,15 +559,15 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
if (result & (INT8_MAX + 1))
result |= 0xFFFFFFFFFFFFFF00ULL;
break;
- case INT16:
+ case RTE_INT16:
if (result & (INT16_MAX + 1))
result |= 0xFFFFFFFFFFFF0000ULL;
break;
- case INT32:
+ case RTE_INT32:
if (result & (INT32_MAX + 1ULL))
result |= 0xFFFFFFFF00000000ULL;
break;
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c..d660f441a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -192,6 +192,10 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* cmdline: the numeric types to be used when defining cmdline parameters
+ have been renamed to have an ``RTE_`` prefix. For example, ``UINT8`` now
+ becomes ``RTE_UINT8``.
+
ABI Changes
-----------
diff --git a/examples/ethtool/ethtool-app/ethapp.c b/examples/ethtool/ethtool-app/ethapp.c
index a4e64b354..22f293904 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -70,7 +70,7 @@ cmdline_parse_token_string_t pcmd_rxmode_token_cmd =
cmdline_parse_token_string_t pcmd_portstats_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "portstats");
cmdline_parse_token_num_t pcmd_int_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, RTE_UINT16);
/* Commands taking port id and string */
cmdline_parse_token_string_t pcmd_eeprom_token_cmd =
@@ -84,7 +84,7 @@ cmdline_parse_token_string_t pcmd_regs_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "regs");
cmdline_parse_token_num_t pcmd_intstr_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_intstr_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, opt, NULL);
@@ -92,7 +92,7 @@ cmdline_parse_token_string_t pcmd_intstr_token_opt =
cmdline_parse_token_string_t pcmd_macaddr_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intmac_params, cmd, "macaddr");
cmdline_parse_token_num_t pcmd_intmac_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, RTE_UINT16);
cmdline_parse_token_etheraddr_t pcmd_intmac_token_mac =
TOKEN_ETHERADDR_INITIALIZER(struct pcmd_intmac_params, mac);
@@ -106,18 +106,18 @@ cmdline_parse_token_string_t pcmd_ringparam_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intintint_params, cmd,
"ringparam");
cmdline_parse_token_num_t pcmd_intintint_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_tx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_rx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, RTE_UINT16);
/* Pause commands */
cmdline_parse_token_string_t pcmd_pause_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "pause");
cmdline_parse_token_num_t pcmd_pause_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_pause_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params,
opt, "all#tx#rx#none");
@@ -126,11 +126,11 @@ cmdline_parse_token_string_t pcmd_pause_token_opt =
cmdline_parse_token_string_t pcmd_vlan_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, cmd, "vlan");
cmdline_parse_token_num_t pcmd_vlan_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_vlan_token_mode =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, mode, "add#del");
cmdline_parse_token_num_t pcmd_vlan_token_vid =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, RTE_UINT16);
static void
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index b0a8ee23b..523b46d6b 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -516,7 +516,7 @@ cmdline_parse_token_string_t cfg_add_neigh_start =
cmdline_parse_token_string_t cfg_add_neigh_pstr =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, pstr, "port");
cmdline_parse_token_num_t cfg_add_neigh_port =
- TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, RTE_UINT16);
cmdline_parse_token_string_t cfg_add_neigh_mac =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, mac, NULL);
diff --git a/examples/qos_sched/cmdline.c b/examples/qos_sched/cmdline.c
index 15f51830c..b163b6f9f 100644
--- a/examples/qos_sched/cmdline.c
+++ b/examples/qos_sched/cmdline.c
@@ -113,7 +113,7 @@ cmdline_parse_token_string_t cmd_setqavg_param_string =
"period#n");
cmdline_parse_token_num_t cmd_setqavg_number =
TOKEN_NUM_INITIALIZER(struct cmd_setqavg_result, number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_setqavg = {
.f = cmd_setqavg_parsed,
@@ -188,10 +188,10 @@ cmdline_parse_token_string_t cmd_subportstats_subport_string =
"subport");
cmdline_parse_token_num_t cmd_subportstats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_subportstats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_subportstats = {
.f = cmd_subportstats_parsed,
@@ -236,19 +236,19 @@ cmdline_parse_token_string_t cmd_pipestats_port_string =
"port");
cmdline_parse_token_num_t cmd_pipestats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_pipestats_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_pipestats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_pipestats_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_pipestats_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_pipestats = {
.f = cmd_pipestats_parsed,
@@ -299,31 +299,31 @@ cmdline_parse_token_string_t cmd_avg_q_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_q_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_q_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_q_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_q_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_q_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_string_t cmd_avg_q_q_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, q_string,
"q");
cmdline_parse_token_num_t cmd_avg_q_q_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, q_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_q = {
.f = cmd_avg_q_parsed,
@@ -376,25 +376,25 @@ cmdline_parse_token_string_t cmd_avg_tcpipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcpipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcpipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcpipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_tcpipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcpipe_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcpipe = {
.f = cmd_avg_tcpipe_parsed,
@@ -443,19 +443,19 @@ cmdline_parse_token_string_t cmd_avg_pipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_pipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_pipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_pipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_pipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_pipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_pipe = {
.f = cmd_avg_pipe_parsed,
@@ -502,19 +502,19 @@ cmdline_parse_token_string_t cmd_avg_tcsubport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcsubport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcsubport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcsubport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcsubport_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcsubport_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcsubport = {
.f = cmd_avg_tcsubport_parsed,
@@ -559,13 +559,13 @@ cmdline_parse_token_string_t cmd_avg_subport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_subport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_subport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_subport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_subport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_subport = {
.f = cmd_avg_subport_parsed,
diff --git a/examples/quota_watermark/qwctl/commands.c b/examples/quota_watermark/qwctl/commands.c
index a1c646b9f..3f0cef7f1 100644
--- a/examples/quota_watermark/qwctl/commands.c
+++ b/examples/quota_watermark/qwctl/commands.c
@@ -74,7 +74,7 @@ cmdline_parse_token_string_t cmd_set_variable =
TOKEN_STRING_INITIALIZER(struct cmd_set_tokens, variable, NULL);
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, RTE_UINT32);
static void
cmd_set_handler(__attribute__((unused)) void *parsed_result,
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 2d9e7689a..82e1a0a03 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -160,7 +160,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_string_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- lcore_id, UINT8);
+ lcore_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/examples/vm_power_manager/vm_power_cli.c b/examples/vm_power_manager/vm_power_cli.c
index 41e89ff20..98e61a4ac 100644
--- a/examples/vm_power_manager/vm_power_cli.c
+++ b/examples/vm_power_manager/vm_power_cli.c
@@ -155,10 +155,10 @@ cmdline_parse_token_string_t cmd_set_pcpu_vm_name =
vm_name, NULL);
cmdline_parse_token_num_t set_pcpu_vcpu =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- vcpu, UINT8);
+ vcpu, RTE_UINT8);
cmdline_parse_token_num_t set_pcpu_core =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- core, UINT64);
+ core, RTE_UINT64);
cmdline_parse_inst_t cmd_set_pcpu_set = {
@@ -408,7 +408,7 @@ cmdline_parse_token_string_t cmd_show_cpu_freq =
cmdline_parse_token_num_t cmd_show_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_show_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_inst_t cmd_show_cpu_freq_set = {
.f = cmd_show_cpu_freq_parsed,
@@ -457,7 +457,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_num_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/lib/librte_cmdline/cmdline_parse_num.c b/lib/librte_cmdline/cmdline_parse_num.c
index 182ac12f0..37d094893 100644
--- a/lib/librte_cmdline/cmdline_parse_num.c
+++ b/lib/librte_cmdline/cmdline_parse_num.c
@@ -69,23 +69,23 @@ static int
check_res_size(struct cmdline_token_num_data *nd, unsigned ressize)
{
switch (nd->type) {
- case INT8:
- case UINT8:
+ case RTE_INT8:
+ case RTE_UINT8:
if (ressize < sizeof(int8_t))
return -1;
break;
- case INT16:
- case UINT16:
+ case RTE_INT16:
+ case RTE_UINT16:
if (ressize < sizeof(int16_t))
return -1;
break;
- case INT32:
- case UINT32:
+ case RTE_INT32:
+ case RTE_UINT32:
if (ressize < sizeof(int32_t))
return -1;
break;
- case INT64:
- case UINT64:
+ case RTE_INT64:
+ case RTE_UINT64:
if (ressize < sizeof(int64_t))
return -1;
break;
@@ -259,35 +259,35 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
case HEX_OK:
case OCTAL_OK:
case BIN_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX ) {
if (res) *(int8_t *)res = (int8_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= INT16_MAX ) {
+ else if ( nd.type == RTE_INT16 && res1 <= INT16_MAX ) {
if (res) *(int16_t *)res = (int16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= INT32_MAX ) {
+ else if ( nd.type == RTE_INT32 && res1 <= INT32_MAX ) {
if (res) *(int32_t *)res = (int32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= INT64_MAX ) {
+ else if ( nd.type == RTE_INT64 && res1 <= INT64_MAX ) {
if (res) *(int64_t *)res = (int64_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT8 && res1 <= UINT8_MAX ) {
+ else if ( nd.type == RTE_UINT8 && res1 <= UINT8_MAX ) {
if (res) *(uint8_t *)res = (uint8_t) res1;
return buf-srcbuf;
}
- else if (nd.type == UINT16 && res1 <= UINT16_MAX ) {
+ else if (nd.type == RTE_UINT16 && res1 <= UINT16_MAX ) {
if (res) *(uint16_t *)res = (uint16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT32 && res1 <= UINT32_MAX ) {
+ else if ( nd.type == RTE_UINT32 && res1 <= UINT32_MAX ) {
if (res) *(uint32_t *)res = (uint32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT64 ) {
+ else if ( nd.type == RTE_UINT64 ) {
if (res) *(uint64_t *)res = res1;
return buf-srcbuf;
}
@@ -297,19 +297,19 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
break;
case DEC_NEG_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX + 1 ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX + 1 ) {
if (res) *(int8_t *)res = (int8_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
+ else if ( nd.type == RTE_INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
if (res) *(int16_t *)res = (int16_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
+ else if ( nd.type == RTE_INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
if (res) *(int32_t *)res = (int32_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
+ else if ( nd.type == RTE_INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
if (res) *(int64_t *)res = (int64_t) (-res1);
return buf-srcbuf;
}
diff --git a/lib/librte_cmdline/cmdline_parse_num.h b/lib/librte_cmdline/cmdline_parse_num.h
index 58b28cad7..02133bb21 100644
--- a/lib/librte_cmdline/cmdline_parse_num.h
+++ b/lib/librte_cmdline/cmdline_parse_num.h
@@ -14,14 +14,14 @@ extern "C" {
#endif
enum cmdline_numtype {
- UINT8 = 0,
- UINT16,
- UINT32,
- UINT64,
- INT8,
- INT16,
- INT32,
- INT64
+ RTE_UINT8 = 0,
+ RTE_UINT16,
+ RTE_UINT32,
+ RTE_UINT64,
+ RTE_INT8,
+ RTE_INT16,
+ RTE_INT32,
+ RTE_INT64
};
struct cmdline_token_num_data {
--
2.20.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-10 17:16 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark return code functions as experimental
since this value might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/release_19_05.rst | 6 +++
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 50 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..32aae5d3bcfa 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,12 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..6cf4d7abb0bd 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 959ef9ece4b2..dc9f3dc0843d 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int __rte_experimental
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned int
-rte_lcore_to_socket_id(unsigned int lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
@ 2019-04-10 17:16 9% ` Stephen Hemminger
2019-04-10 17:16 9% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark return code functions as experimental
since this value might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/release_19_05.rst | 6 +++
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 50 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..32aae5d3bcfa 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,12 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..6cf4d7abb0bd 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 959ef9ece4b2..dc9f3dc0843d 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int __rte_experimental
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned int
-rte_lcore_to_socket_id(unsigned int lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
@ 2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure less visible
as part of the ABI. This version does not break the ABI (yet)
follow on patch moves lcore_config into eal_private.h
The changes in v2 is to:
- new patch to use unsigned int in lcore.h first
- incorporate feedback from David
- don't include last patch to make it private
(to avoid accidental early merge)
Stephen Hemminger (5):
eal: use unsigned int in rte_lcore.h functions
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 +++---
app/test/test_ring_perf.c | 22 +++++----
app/test/test_stack_perf.c | 20 ++++----
doc/guides/rel_notes/release_19_05.rst | 6 +++
drivers/bus/dpaa/dpaa_bus.c | 6 ++-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 5 +-
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 58 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 136 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
` (2 preceding siblings ...)
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
3 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure less visible
as part of the ABI. This version does not break the ABI (yet)
follow on patch moves lcore_config into eal_private.h
The changes in v2 is to:
- new patch to use unsigned int in lcore.h first
- incorporate feedback from David
- don't include last patch to make it private
(to avoid accidental early merge)
Stephen Hemminger (5):
eal: use unsigned int in rte_lcore.h functions
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 +++---
app/test/test_ring_perf.c | 22 +++++----
app/test/test_stack_perf.c | 20 ++++----
doc/guides/rel_notes/release_19_05.rst | 6 +++
drivers/bus/dpaa/dpaa_bus.c | 6 ++-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 5 +-
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 58 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 136 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
@ 2019-04-10 9:43 4% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-10 9:43 UTC (permalink / raw)
To: Honnappa Nagarahalli, Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: nd
On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote:
> > I guess the short story is that DPDK ABI hasn't really settled down
> > as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive
> > releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature
> > project
> > with a similar intent, a framework for building applications, and
> > which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-
> > integration
> > and re-validation effort for new versions of DPDK. This effort from
> > their
> > perspective may not add value to their consuming project,
> > particular if
> > they are only updating to "stay current".
>
> Even if the ABI did not change, any claim of support with newer
> version needs re-validation. I think, re-integration is the only
> extra effort.
From first-hand experience: re-integration and re-validation are
different in scope and resource requirements.
Validation is usually done by the QA group, and usually doesn't cover
just one library that makes up a part of a product. In other words,
whether the DPDK version changes or not, a new version of a product
will typically undergo full regression testing anyway.
Integration is done by the development group. Any engineering-days that
have to be dedicated to re-integrate a new version of DPDK are
resources taken away from development of new features or bug fixing.
Maintenance costs of OSS components are a sometimes overlooked but
critical part of correctly scoping the opex of a project, and it's
something that product/project managers do look at.
> Why would anyone like to move to newer version just to stay current
> if the newer version does not add any value to them? IMO, this is
> doing work for no benefit.
For many reasons. For example the argument I always use is that while
new version Y might not be needed, new version Z might suddenly become
required for the successful delivery of critical feature A, or to fix
critical bug B.
In my experience, jumping from version X to Y and then Y to Z is always
cheaper and quicker and lower effort than jumping from X to Z, and the
larger the jump, the more work it is.
Another reason is that it's orders of magnitude cheaper to consume
dependencies from the base distribution of choice when building a Linux
product, rather than vendorizing. Doing that has of course drawbacks,
including not being in control of the version of dependencies - so you
don't have a choice, you need to keep up as the base distro moves on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 5:14 9% ` [dpdk-dev] " Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-04-10 9:43 4% ` Luca Boccassi
2019-04-10 9:43 4% ` Luca Boccassi
2 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2019-04-10 9:43 UTC (permalink / raw)
To: Honnappa Nagarahalli, Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: nd
On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote:
> > I guess the short story is that DPDK ABI hasn't really settled down
> > as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive
> > releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature
> > project
> > with a similar intent, a framework for building applications, and
> > which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-
> > integration
> > and re-validation effort for new versions of DPDK. This effort from
> > their
> > perspective may not add value to their consuming project,
> > particular if
> > they are only updating to "stay current".
>
> Even if the ABI did not change, any claim of support with newer
> version needs re-validation. I think, re-integration is the only
> extra effort.
>From first-hand experience: re-integration and re-validation are
different in scope and resource requirements.
Validation is usually done by the QA group, and usually doesn't cover
just one library that makes up a part of a product. In other words,
whether the DPDK version changes or not, a new version of a product
will typically undergo full regression testing anyway.
Integration is done by the development group. Any engineering-days that
have to be dedicated to re-integrate a new version of DPDK are
resources taken away from development of new features or bug fixing.
Maintenance costs of OSS components are a sometimes overlooked but
critical part of correctly scoping the opex of a project, and it's
something that product/project managers do look at.
> Why would anyone like to move to newer version just to stay current
> if the newer version does not add any value to them? IMO, this is
> doing work for no benefit.
For many reasons. For example the argument I always use is that while
new version Y might not be needed, new version Z might suddenly become
required for the successful delivery of critical feature A, or to fix
critical bug B.
In my experience, jumping from version X to Y and then Y to Z is always
cheaper and quicker and lower effort than jumping from X to Z, and the
larger the jump, the more work it is.
Another reason is that it's orders of magnitude cheaper to consume
dependencies from the base distribution of choice when building a Linux
product, rather than vendorizing. Doing that has of course drawbacks,
including not being in control of the version of dependencies - so you
don't have a choice, you need to keep up as the base distro moves on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
2019-04-10 9:16 0% ` Bruce Richardson
@ 2019-04-10 9:16 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-10 9:16 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, John McNamara, Marko Kovacevic, Ferruh Yigit
On Wed, Apr 10, 2019 at 10:36:25AM +0200, Olivier Matz wrote:
> As discussed at techboard, the network definitions, structures
> and functions will be prefixed by 'rte_'.
>
> Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
> Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ba39c2d62..36bc21ff8 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> +* network includes: Network structures, definitions and functions will
> + be prefixed by ``rte_`` to resolve conflicts with libc headers.
> + This change will break many DPDK APIs.
> +
> * meson: The minimum supported version of meson for configuring and building
> DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
> those users with a version earlier than 0.47.1, an updated copy of meson
> --
> 2.11.0
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
@ 2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 9:16 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-10 9:16 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, John McNamara, Marko Kovacevic, Ferruh Yigit
On Wed, Apr 10, 2019 at 10:36:25AM +0200, Olivier Matz wrote:
> As discussed at techboard, the network definitions, structures
> and functions will be prefixed by 'rte_'.
>
> Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
> Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ba39c2d62..36bc21ff8 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> +* network includes: Network structures, definitions and functions will
> + be prefixed by ``rte_`` to resolve conflicts with libc headers.
> + This change will break many DPDK APIs.
> +
> * meson: The minimum supported version of meson for configuring and building
> DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
> those users with a version earlier than 0.47.1, an updated copy of meson
> --
> 2.11.0
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-04-10 9:03 8% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-10 9:03 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard, nd
On Wed, Apr 10, 2019 at 05:14:43AM +0000, Honnappa Nagarahalli wrote:
> >
> > Hi folks,
> >
> > Recently I started a discussion with the DPDK Technical Board on DPDK
> > ABI/API stability. This was born out informal feedback I had received from
> > a number of users of DPDK about ABI churn. In turn this feedback then
> > prompted an ABI analysis of DPDK using tools from abi-laboratory.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> This link can be used to check which structures are not needed to be exposed to the application.
> For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> >
> > I guess the short story is that DPDK ABI hasn't really settled down as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature project
> > with a similar intent, a framework for building applications, and which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-integration
> > and re-validation effort for new versions of DPDK. This effort from their
> > perspective may not add value to their consuming project, particular if
> > they are only updating to "stay current".
> Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
> Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
>
> > 2. The churn encourages users of DPDK to slip versions, putting off
> > reintegration to later, building up technical debt and causing their projects
> > to miss support for new hardware or features.
> > 3. It makes DPDK different to almost every other system library and
> > framework that an operating systems might ship. This makes DPDK trickier
> > to dynamically link against, package and maintain for OS maintainers.
> >
> > In order to address this issue, I have put together the minimal set of
> > concrete proposals below for discussion at the Technical Board next
> > Wednesday.
> >
> > I wanted to share this, as these might not yet be the right proposals,
> > however I am putting them out there for feedback to start the discussion.
> >
> > Thanks,
> >
> > Ray K
> >
> >
> > Experimental API
> > 1. APIs designated as experimental are not considered part of the ABI
> > and may change without warning at any time.
> > 2. APIs designated as experimental must be marked depreciated for a
> > least one quarterly release before removal.
> > 3. APIs designated as experimental will no longer automatically
> > graduate
> > to core after one release, they may stay experimental until their author
> > and the maintainer agree that graduation is appropriate.
> >
> > Core API (non-experimental API)
> > 4. APIs designated as core must be depreciated for a least two years
> > before removal, to facilitate the continued compatibility with LTS releases.
> > A final removal notice will be published to the DPDK Mailing List, and if
> > there are no strong objections only then an API may be removed.
> > 5. APIs designated as core may be changed as follows:-
> > 5.a The change proposer must demonstrated that the change has a
> > supporting use case and could not be achieved in any other way.
> > 5.b ABI version compatibility must be retained, as described below.
> >
> > Shared Libraries
> > 6. DPDK will move to shared libraries & dynamic linking by default, to
> > accommodate greater use of ABI versioning by DPDK consumers.
> +1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
> Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
>
We do sometimes, but not enough. If we mandated ABI compatibility, or made
ABI breaks harder, I think we'd see greater adoption of this versioning
(something I am very much favour of).
/Bruce
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 5:14 9% ` [dpdk-dev] " Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
@ 2019-04-10 9:03 8% ` Bruce Richardson
2019-04-10 9:03 8% ` Bruce Richardson
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
2 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-10 9:03 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard, nd
On Wed, Apr 10, 2019 at 05:14:43AM +0000, Honnappa Nagarahalli wrote:
> >
> > Hi folks,
> >
> > Recently I started a discussion with the DPDK Technical Board on DPDK
> > ABI/API stability. This was born out informal feedback I had received from
> > a number of users of DPDK about ABI churn. In turn this feedback then
> > prompted an ABI analysis of DPDK using tools from abi-laboratory.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> This link can be used to check which structures are not needed to be exposed to the application.
> For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> >
> > I guess the short story is that DPDK ABI hasn't really settled down as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature project
> > with a similar intent, a framework for building applications, and which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-integration
> > and re-validation effort for new versions of DPDK. This effort from their
> > perspective may not add value to their consuming project, particular if
> > they are only updating to "stay current".
> Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
> Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
>
> > 2. The churn encourages users of DPDK to slip versions, putting off
> > reintegration to later, building up technical debt and causing their projects
> > to miss support for new hardware or features.
> > 3. It makes DPDK different to almost every other system library and
> > framework that an operating systems might ship. This makes DPDK trickier
> > to dynamically link against, package and maintain for OS maintainers.
> >
> > In order to address this issue, I have put together the minimal set of
> > concrete proposals below for discussion at the Technical Board next
> > Wednesday.
> >
> > I wanted to share this, as these might not yet be the right proposals,
> > however I am putting them out there for feedback to start the discussion.
> >
> > Thanks,
> >
> > Ray K
> >
> >
> > Experimental API
> > 1. APIs designated as experimental are not considered part of the ABI
> > and may change without warning at any time.
> > 2. APIs designated as experimental must be marked depreciated for a
> > least one quarterly release before removal.
> > 3. APIs designated as experimental will no longer automatically
> > graduate
> > to core after one release, they may stay experimental until their author
> > and the maintainer agree that graduation is appropriate.
> >
> > Core API (non-experimental API)
> > 4. APIs designated as core must be depreciated for a least two years
> > before removal, to facilitate the continued compatibility with LTS releases.
> > A final removal notice will be published to the DPDK Mailing List, and if
> > there are no strong objections only then an API may be removed.
> > 5. APIs designated as core may be changed as follows:-
> > 5.a The change proposer must demonstrated that the change has a
> > supporting use case and could not be achieved in any other way.
> > 5.b ABI version compatibility must be retained, as described below.
> >
> > Shared Libraries
> > 6. DPDK will move to shared libraries & dynamic linking by default, to
> > accommodate greater use of ABI versioning by DPDK consumers.
> +1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
> Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
>
We do sometimes, but not enough. If we mandated ABI compatibility, or made
ABI breaks harder, I think we'd see greater adoption of this versioning
(something I am very much favour of).
/Bruce
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
@ 2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Olivier Matz @ 2019-04-10 8:36 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Marko Kovacevic, Ferruh Yigit
As discussed at techboard, the network definitions, structures
and functions will be prefixed by 'rte_'.
Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ba39c2d62..36bc21ff8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* network includes: Network structures, definitions and functions will
+ be prefixed by ``rte_`` to resolve conflicts with libc headers.
+ This change will break many DPDK APIs.
+
* meson: The minimum supported version of meson for configuring and building
DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
those users with a version earlier than 0.47.1, an updated copy of meson
--
2.11.0
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
@ 2019-04-10 8:36 5% Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Olivier Matz @ 2019-04-10 8:36 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Marko Kovacevic, Ferruh Yigit
As discussed at techboard, the network definitions, structures
and functions will be prefixed by 'rte_'.
Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ba39c2d62..36bc21ff8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* network includes: Network structures, definitions and functions will
+ be prefixed by ``rte_`` to resolve conflicts with libc headers.
+ This change will break many DPDK APIs.
+
* meson: The minimum supported version of meson for configuring and building
DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
those users with a version earlier than 0.47.1, an updated copy of meson
--
2.11.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 8:35 4% ` David Marchand
@ 2019-04-10 8:35 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-04-10 8:35 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 5:52 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
However, there are two use cases that i can think of that are either
> hard or outright not possible without our multiprocess API's. The first
> one is dumping functionality. For example, dpdk_proc_info can display
> info from a currently-running or defunct process - list its
> memzones/mempools/etc. - basically, everything there is to know about
> the shared memory can be known that way. While this isn't a "real" use
> case, it is useful for debugging.
>
On the principle (there might be some corner cases I don't have an idea of)
attaching an existing process is something that can be done with PTRACE_*.
As for dumping post mortem, again, this could be done without dpdk assist.
The only thing that should come from dpdk is the knowledge of where and how
to dump the objects.
> More importantly, our multiprocess model provides resilience. In an
> event of a crash, the entire application is not brought down - instead,
> only the crashed process goes down. It's not /perfect/ resilience, of
> course, and there are caveats (memory leaking, locks, etc.), but you do
> get /some/ resilience that way - your process went down, you spin
> another secondary and you're back up and running again.
>
Never witnessed a recover, and yes I would suspect quite some funny
situations like locks, dirty memory etc...
Okay, thanks for the inputs.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-04-10 8:35 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 5:52 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
However, there are two use cases that i can think of that are either
> hard or outright not possible without our multiprocess API's. The first
> one is dumping functionality. For example, dpdk_proc_info can display
> info from a currently-running or defunct process - list its
> memzones/mempools/etc. - basically, everything there is to know about
> the shared memory can be known that way. While this isn't a "real" use
> case, it is useful for debugging.
>
On the principle (there might be some corner cases I don't have an idea of)
attaching an existing process is something that can be done with PTRACE_*.
As for dumping post mortem, again, this could be done without dpdk assist.
The only thing that should come from dpdk is the knowledge of where and how
to dump the objects.
> More importantly, our multiprocess model provides resilience. In an
> event of a crash, the entire application is not brought down - instead,
> only the crashed process goes down. It's not /perfect/ resilience, of
> course, and there are caveats (memory leaking, locks, etc.), but you do
> get /some/ resilience that way - your process went down, you spin
> another secondary and you're back up and running again.
>
Never witnessed a recover, and yes I would suspect quite some funny
situations like locks, dirty memory etc...
Okay, thanks for the inputs.
--
David Marchand
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC v2 00/14] prefix network structures
2019-04-10 8:32 1% ` [dpdk-dev] [RFC v2 " Olivier Matz
@ 2019-04-10 8:32 1% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-04-10 8:32 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit
This RFC targets 19.08.
The rte_net headers conflict with the libc headers, because
some definitions are duplicated, sometimes with few differences.
This RFC adds the rte_ (or RTE_) prefix to all structures, functions
and defines in rte_net library. This is a big changeset, that will
break the API of many functions, but not the ABI.
This was discussed in [1], and recently requested by the techboard [2].
v2:
* rebase on top of v19.05-rc1
[1] http://mails.dpdk.org/archives/dev/2018-January/087384.html
[2] http://mails.dpdk.org/archives/dev/2019-February/125033.html
Olivier Matz (14):
net: add rte prefix to arp structures
net: add rte prefix to arp defines
net: add rte prefix to ether structures
net: add rte prefix to ether functions
net: add rte prefix to ether defines
net: add rte prefix to esp structure
net: add rte prefix to gre structure
net: add rte prefix to icmp structure
net: add rte prefix to icmp defines
net: add rte prefix to ip structure
net: add rte prefix to ip defines
net: add rte prefix to sctp structure
net: add rte prefix to tcp structure
net: add rte prefix to udp structure
app/pdump/main.c | 2 +-
app/test-acl/main.c | 2 +-
app/test-eventdev/test_perf_common.c | 2 +-
app/test-eventdev/test_pipeline_common.c | 2 +-
app/test-pipeline/pipeline_acl.c | 16 +-
app/test-pipeline/pipeline_hash.c | 12 +-
app/test-pmd/cmdline.c | 90 +++---
app/test-pmd/cmdline_flow.c | 86 +++---
app/test-pmd/config.c | 34 +--
app/test-pmd/csumonly.c | 160 +++++-----
app/test-pmd/flowgen.c | 30 +-
app/test-pmd/icmpecho.c | 120 ++++----
app/test-pmd/ieee1588fwd.c | 18 +-
app/test-pmd/macfwd.c | 12 +-
app/test-pmd/macswap.h | 12 +-
app/test-pmd/macswap_common.h | 4 +-
app/test-pmd/macswap_neon.h | 12 +-
app/test-pmd/macswap_sse.h | 12 +-
app/test-pmd/parameters.c | 6 +-
app/test-pmd/testpmd.c | 22 +-
app/test-pmd/testpmd.h | 30 +-
app/test-pmd/txonly.c | 44 +--
app/test-pmd/util.c | 34 +--
app/test/packet_burst_generator.c | 126 ++++----
app/test/packet_burst_generator.h | 26 +-
app/test/test_acl.c | 8 +-
app/test/test_acl.h | 122 ++++----
app/test/test_cmdline_etheraddr.c | 16 +-
app/test/test_efd.c | 20 +-
app/test/test_event_eth_rx_adapter.c | 2 +-
app/test/test_event_eth_tx_adapter.c | 2 +-
app/test/test_flow_classify.c | 68 ++---
app/test/test_hash.c | 20 +-
app/test/test_ipsec.c | 12 +-
app/test/test_link_bonding.c | 284 +++++++++---------
app/test/test_link_bonding_mode4.c | 116 ++++----
app/test/test_link_bonding_rssconf.c | 6 +-
app/test/test_lpm.c | 76 ++---
app/test/test_lpm_perf.c | 10 +-
app/test/test_member.c | 20 +-
app/test/test_pmd_perf.c | 20 +-
app/test/test_sched.c | 20 +-
app/test/test_table_acl.c | 8 +-
app/test/test_thash.c | 12 +-
app/test/virtual_pmd.c | 6 +-
app/test/virtual_pmd.h | 2 +-
doc/guides/nics/kni.rst | 2 +-
doc/guides/prog_guide/bbdev.rst | 6 +-
.../prog_guide/packet_classif_access_ctrl.rst | 18 +-
doc/guides/prog_guide/rte_flow.rst | 4 +-
doc/guides/sample_app_ug/flow_classify.rst | 28 +-
doc/guides/sample_app_ug/flow_filtering.rst | 6 +-
doc/guides/sample_app_ug/ip_frag.rst | 16 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 16 +-
doc/guides/sample_app_ug/ipv4_multicast.rst | 16 +-
doc/guides/sample_app_ug/l2_forward_job_stats.rst | 6 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 6 +-
doc/guides/sample_app_ug/l3_forward.rst | 12 +-
doc/guides/sample_app_ug/link_status_intr.rst | 6 +-
doc/guides/sample_app_ug/ptpclient.rst | 6 +-
doc/guides/sample_app_ug/rxtx_callbacks.rst | 2 +-
doc/guides/sample_app_ug/server_node_efd.rst | 12 +-
doc/guides/sample_app_ug/skeleton.rst | 4 +-
doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 4 +-
drivers/bus/dpaa/base/fman/fman.c | 2 +-
drivers/bus/dpaa/base/fman/fman_hw.c | 2 +-
drivers/bus/dpaa/include/fman.h | 2 +-
drivers/bus/dpaa/include/netcfg.h | 4 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 6 +-
drivers/net/ark/ark_ethdev.c | 16 +-
drivers/net/ark/ark_ext.h | 4 +-
drivers/net/ark/ark_global.h | 4 +-
drivers/net/atlantic/atl_ethdev.c | 20 +-
drivers/net/atlantic/hw_atl/hw_atl_utils.c | 8 +-
drivers/net/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 +-
drivers/net/avp/avp_ethdev.c | 20 +-
drivers/net/avp/rte_avp_common.h | 2 +-
drivers/net/axgbe/axgbe_dev.c | 4 +-
drivers/net/axgbe/axgbe_ethdev.c | 10 +-
drivers/net/axgbe/axgbe_ethdev.h | 4 +-
drivers/net/axgbe/axgbe_rxtx.c | 2 +-
drivers/net/bnx2x/bnx2x.c | 16 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 4 +-
drivers/net/bnx2x/bnx2x_ethdev.h | 2 +-
drivers/net/bnx2x/bnx2x_vfpf.c | 8 +-
drivers/net/bnx2x/bnx2x_vfpf.h | 2 +-
drivers/net/bnx2x/ecore_sp.h | 2 +-
drivers/net/bnxt/bnxt.h | 4 +-
drivers/net/bnxt/bnxt_ethdev.c | 70 ++---
drivers/net/bnxt/bnxt_filter.c | 4 +-
drivers/net/bnxt/bnxt_filter.h | 8 +-
drivers/net/bnxt/bnxt_flow.c | 26 +-
drivers/net/bnxt/bnxt_hwrm.c | 40 +--
drivers/net/bnxt/bnxt_hwrm.h | 2 +-
drivers/net/bnxt/bnxt_ring.c | 8 +-
drivers/net/bnxt/bnxt_rxq.c | 2 +-
drivers/net/bnxt/bnxt_rxr.c | 2 +-
drivers/net/bnxt/bnxt_vnic.c | 2 +-
drivers/net/bnxt/rte_pmd_bnxt.c | 14 +-
drivers/net/bnxt/rte_pmd_bnxt.h | 4 +-
drivers/net/bonding/rte_eth_bond.h | 2 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 28 +-
drivers/net/bonding/rte_eth_bond_8023ad.h | 10 +-
drivers/net/bonding/rte_eth_bond_8023ad_private.h | 2 +-
drivers/net/bonding/rte_eth_bond_alb.c | 78 ++---
drivers/net/bonding/rte_eth_bond_alb.h | 10 +-
drivers/net/bonding/rte_eth_bond_api.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 2 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 194 ++++++-------
drivers/net/bonding/rte_eth_bond_private.h | 6 +-
drivers/net/cxgbe/base/adapter.h | 6 +-
drivers/net/cxgbe/base/t4_hw.c | 8 +-
drivers/net/cxgbe/cxgbe.h | 4 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 14 +-
drivers/net/cxgbe/cxgbe_filter.h | 2 +-
drivers/net/cxgbe/cxgbe_flow.c | 10 +-
drivers/net/cxgbe/cxgbe_main.c | 4 +-
drivers/net/cxgbe/cxgbe_pfvf.h | 2 +-
drivers/net/cxgbe/cxgbevf_main.c | 2 +-
drivers/net/cxgbe/l2t.c | 8 +-
drivers/net/cxgbe/l2t.h | 2 +-
drivers/net/cxgbe/mps_tcam.c | 14 +-
drivers/net/cxgbe/mps_tcam.h | 4 +-
drivers/net/cxgbe/sge.c | 8 +-
drivers/net/dpaa/dpaa_ethdev.c | 20 +-
drivers/net/dpaa/dpaa_rxtx.c | 22 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 36 +--
drivers/net/dpaa2/dpaa2_flow.c | 18 +-
drivers/net/e1000/e1000_ethdev.h | 4 +-
drivers/net/e1000/em_ethdev.c | 34 +--
drivers/net/e1000/em_rxtx.c | 22 +-
drivers/net/e1000/igb_ethdev.c | 70 ++---
drivers/net/e1000/igb_flow.c | 12 +-
drivers/net/e1000/igb_pf.c | 16 +-
drivers/net/e1000/igb_rxtx.c | 18 +-
drivers/net/ena/ena_ethdev.c | 16 +-
drivers/net/ena/ena_ethdev.h | 2 +-
drivers/net/enetc/base/enetc_hw.h | 4 +-
drivers/net/enetc/enetc_ethdev.c | 6 +-
drivers/net/enic/enic.h | 4 +-
drivers/net/enic/enic_clsf.c | 40 +--
drivers/net/enic/enic_ethdev.c | 28 +-
drivers/net/enic/enic_flow.c | 106 +++----
drivers/net/enic/enic_main.c | 4 +-
drivers/net/enic/enic_res.c | 4 +-
drivers/net/failsafe/failsafe.c | 6 +-
drivers/net/failsafe/failsafe_args.c | 4 +-
drivers/net/failsafe/failsafe_ether.c | 6 +-
drivers/net/failsafe/failsafe_ops.c | 6 +-
drivers/net/failsafe/failsafe_private.h | 4 +-
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 18 +-
drivers/net/i40e/base/i40e_adminq_cmd.h | 4 +-
drivers/net/i40e/base/i40e_common.c | 12 +-
drivers/net/i40e/base/i40e_prototype.h | 4 +-
drivers/net/i40e/i40e_ethdev.c | 136 ++++-----
drivers/net/i40e/i40e_ethdev.h | 22 +-
drivers/net/i40e/i40e_ethdev_vf.c | 62 ++--
drivers/net/i40e/i40e_fdir.c | 126 ++++----
drivers/net/i40e/i40e_flow.c | 58 ++--
drivers/net/i40e/i40e_pf.c | 18 +-
drivers/net/i40e/i40e_rxtx.c | 28 +-
drivers/net/i40e/i40e_vf_representor.c | 2 +-
drivers/net/i40e/rte_pmd_i40e.c | 30 +-
drivers/net/i40e/rte_pmd_i40e.h | 8 +-
drivers/net/iavf/base/iavf_adminq_cmd.h | 4 +-
drivers/net/iavf/base/iavf_common.c | 12 +-
drivers/net/iavf/base/iavf_prototype.h | 4 +-
drivers/net/iavf/iavf.h | 4 +-
drivers/net/iavf/iavf_ethdev.c | 50 ++--
drivers/net/iavf/iavf_rxtx.c | 14 +-
drivers/net/iavf/iavf_vchnl.c | 8 +-
drivers/net/ice/ice_ethdev.c | 62 ++--
drivers/net/ice/ice_ethdev.h | 4 +-
drivers/net/ice/ice_rxtx.c | 28 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 92 +++---
drivers/net/ixgbe/ixgbe_ethdev.h | 4 +-
drivers/net/ixgbe/ixgbe_flow.c | 22 +-
drivers/net/ixgbe/ixgbe_pf.c | 14 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +-
drivers/net/ixgbe/ixgbe_vf_representor.c | 4 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 10 +-
drivers/net/ixgbe/rte_pmd_ixgbe.h | 2 +-
drivers/net/kni/rte_eth_kni.c | 6 +-
drivers/net/liquidio/lio_ethdev.c | 22 +-
drivers/net/mlx4/mlx4.c | 4 +-
drivers/net/mlx4/mlx4.h | 8 +-
drivers/net/mlx4/mlx4_ethdev.c | 8 +-
drivers/net/mlx4/mlx4_flow.c | 14 +-
drivers/net/mlx4/mlx4_rxtx.c | 2 +-
drivers/net/mlx5/mlx5.c | 4 +-
drivers/net/mlx5/mlx5.h | 14 +-
drivers/net/mlx5/mlx5_flow.c | 22 +-
drivers/net/mlx5/mlx5_flow_dv.c | 44 +--
drivers/net/mlx5/mlx5_flow_tcf.c | 66 ++---
drivers/net/mlx5/mlx5_flow_verbs.c | 26 +-
drivers/net/mlx5/mlx5_mac.c | 18 +-
drivers/net/mlx5/mlx5_nl.c | 28 +-
drivers/net/mlx5/mlx5_rxtx.c | 6 +-
drivers/net/mlx5/mlx5_rxtx.h | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 8 +-
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 10 +-
drivers/net/mlx5/mlx5_trigger.c | 6 +-
drivers/net/mvneta/mvneta_ethdev.c | 22 +-
drivers/net/mvneta/mvneta_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_ethdev.c | 22 +-
drivers/net/mvpp2/mrvl_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_flow.c | 4 +-
drivers/net/netvsc/hn_ethdev.c | 4 +-
drivers/net/netvsc/hn_nvs.c | 2 +-
drivers/net/netvsc/hn_rndis.c | 2 +-
drivers/net/netvsc/hn_rxtx.c | 12 +-
drivers/net/netvsc/hn_var.h | 4 +-
drivers/net/netvsc/hn_vf.c | 8 +-
drivers/net/nfp/nfp_net.c | 20 +-
drivers/net/nfp/nfp_net_pmd.h | 2 +-
drivers/net/null/rte_eth_null.c | 6 +-
drivers/net/octeontx/octeontx_ethdev.c | 8 +-
drivers/net/octeontx/octeontx_ethdev.h | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 22 +-
drivers/net/qede/base/bcm_osal.h | 2 +-
drivers/net/qede/base/ecore_dev.c | 4 +-
drivers/net/qede/qede_ethdev.c | 58 ++--
drivers/net/qede/qede_ethdev.h | 6 +-
drivers/net/qede/qede_filter.c | 66 ++---
drivers/net/qede/qede_if.h | 4 +-
drivers/net/qede/qede_main.c | 6 +-
drivers/net/qede/qede_rxtx.c | 32 +-
drivers/net/qede/qede_rxtx.h | 2 +-
drivers/net/ring/rte_eth_ring.c | 4 +-
drivers/net/sfc/sfc.h | 2 +-
drivers/net/sfc/sfc_ef10_tx.c | 4 +-
drivers/net/sfc/sfc_ethdev.c | 20 +-
drivers/net/sfc/sfc_flow.c | 12 +-
drivers/net/sfc/sfc_port.c | 8 +-
drivers/net/sfc/sfc_tso.c | 4 +-
drivers/net/sfc/sfc_tso.h | 4 +-
drivers/net/softnic/parser.c | 18 +-
drivers/net/softnic/parser.h | 2 +-
drivers/net/softnic/rte_eth_softnic.c | 2 +-
drivers/net/softnic/rte_eth_softnic_flow.c | 4 +-
drivers/net/softnic/rte_eth_softnic_pipeline.c | 40 +--
drivers/net/szedata2/rte_eth_szedata2.c | 8 +-
drivers/net/tap/rte_eth_tap.c | 60 ++--
drivers/net/tap/rte_eth_tap.h | 2 +-
drivers/net/tap/tap_bpf_program.c | 14 +-
drivers/net/tap/tap_flow.c | 12 +-
drivers/net/thunderx/base/nicvf_mbox.c | 4 +-
drivers/net/thunderx/base/nicvf_plat.h | 2 +-
drivers/net/thunderx/nicvf_ethdev.c | 18 +-
drivers/net/thunderx/nicvf_struct.h | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 16 +-
drivers/net/vhost/rte_eth_vhost.c | 12 +-
drivers/net/virtio/virtio_ethdev.c | 72 ++---
drivers/net/virtio/virtio_pci.h | 4 +-
drivers/net/virtio/virtio_rxtx.c | 32 +-
drivers/net/virtio/virtio_user/vhost_kernel_tap.c | 2 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 6 +-
drivers/net/virtio/virtio_user/virtio_user_dev.h | 2 +-
drivers/net/virtio/virtio_user_ethdev.c | 8 +-
drivers/net/virtio/virtqueue.h | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 +-
drivers/net/vmxnet3/vmxnet3_ethdev.h | 2 +-
drivers/net/vmxnet3/vmxnet3_rxtx.c | 44 +--
examples/bbdev_app/main.c | 40 +--
examples/bond/main.c | 78 ++---
examples/distributor/main.c | 4 +-
examples/ethtool/ethtool-app/ethapp.c | 8 +-
examples/ethtool/ethtool-app/main.c | 10 +-
examples/ethtool/lib/rte_ethtool.c | 8 +-
examples/ethtool/lib/rte_ethtool.h | 6 +-
examples/eventdev_pipeline/main.c | 4 +-
examples/eventdev_pipeline/pipeline_common.h | 10 +-
examples/flow_classify/flow_classify.c | 30 +-
examples/flow_filtering/main.c | 10 +-
examples/ip_fragmentation/main.c | 64 ++--
examples/ip_pipeline/cli.c | 4 +-
examples/ip_pipeline/kni.c | 2 +-
examples/ip_pipeline/parser.c | 18 +-
examples/ip_pipeline/parser.h | 2 +-
examples/ip_pipeline/pipeline.c | 40 +--
examples/ip_reassembly/main.c | 50 ++--
examples/ipsec-secgw/esp.c | 42 +--
examples/ipsec-secgw/ipsec-secgw.c | 42 +--
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/parser.c | 4 +-
examples/ipsec-secgw/sa.c | 16 +-
examples/ipv4_multicast/main.c | 58 ++--
examples/kni/main.c | 14 +-
examples/l2fwd-cat/l2fwd-cat.c | 4 +-
examples/l2fwd-crypto/main.c | 26 +-
examples/l2fwd-jobstats/main.c | 8 +-
examples/l2fwd-keepalive/main.c | 8 +-
examples/l2fwd/main.c | 8 +-
examples/l3fwd-acl/main.c | 102 +++----
examples/l3fwd-power/main.c | 100 +++----
examples/l3fwd-vf/main.c | 68 ++---
examples/l3fwd/l3fwd.h | 8 +-
examples/l3fwd/l3fwd_altivec.h | 14 +-
examples/l3fwd/l3fwd_common.h | 4 +-
examples/l3fwd/l3fwd_em.c | 44 +--
examples/l3fwd/l3fwd_em.h | 20 +-
examples/l3fwd/l3fwd_em_hlm.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_neon.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_sse.h | 16 +-
examples/l3fwd/l3fwd_em_sequential.h | 16 +-
examples/l3fwd/l3fwd_lpm.c | 50 ++--
examples/l3fwd/l3fwd_lpm.h | 20 +-
examples/l3fwd/l3fwd_lpm_altivec.h | 20 +-
examples/l3fwd/l3fwd_lpm_neon.h | 30 +-
examples/l3fwd/l3fwd_lpm_sse.h | 20 +-
examples/l3fwd/l3fwd_neon.h | 14 +-
examples/l3fwd/l3fwd_sse.h | 14 +-
examples/l3fwd/main.c | 20 +-
examples/link_status_interrupt/main.c | 8 +-
examples/load_balancer/runtime.c | 6 +-
.../client_server_mp/mp_server/main.c | 2 +-
examples/packet_ordering/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 322 ++++++++++-----------
examples/ptpclient/ptpclient.c | 32 +-
examples/qos_meter/main.c | 4 +-
examples/qos_sched/init.c | 2 +-
examples/quota_watermark/qw/main.c | 8 +-
examples/rxtx_callbacks/main.c | 4 +-
examples/server_node_efd/node/node.c | 6 +-
examples/server_node_efd/server/main.c | 8 +-
examples/skeleton/basicfwd.c | 4 +-
examples/tep_termination/main.c | 2 +-
examples/tep_termination/main.h | 2 +-
examples/tep_termination/vxlan.c | 108 +++----
examples/tep_termination/vxlan.h | 8 +-
examples/tep_termination/vxlan_setup.c | 30 +-
examples/tep_termination/vxlan_setup.h | 2 +-
examples/vhost/main.c | 40 +--
examples/vhost/main.h | 2 +-
examples/vm_power_manager/channel_monitor.c | 12 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/main.c | 6 +-
examples/vmdq/main.c | 12 +-
examples/vmdq_dcb/main.c | 12 +-
lib/librte_ethdev/rte_class_eth.c | 4 +-
lib/librte_ethdev/rte_eth_ctrl.h | 12 +-
lib/librte_ethdev/rte_ethdev.c | 58 ++--
lib/librte_ethdev/rte_ethdev.h | 14 +-
lib/librte_ethdev/rte_ethdev_core.h | 12 +-
lib/librte_ethdev/rte_flow.h | 32 +-
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 32 +-
lib/librte_gro/gro_tcp4.c | 26 +-
lib/librte_gro/gro_tcp4.h | 22 +-
lib/librte_gro/gro_vxlan_tcp4.c | 64 ++--
lib/librte_gro/gro_vxlan_tcp4.h | 6 +-
lib/librte_gso/gso_common.h | 16 +-
lib/librte_gso/gso_tcp4.c | 12 +-
lib/librte_gso/gso_tunnel_tcp4.c | 14 +-
lib/librte_gso/gso_udp4.c | 8 +-
lib/librte_gso/rte_gso.h | 8 +-
lib/librte_hash/rte_thash.h | 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 12 +-
lib/librte_ip_frag/rte_ipv4_fragmentation.c | 42 +--
lib/librte_ip_frag/rte_ipv4_reassembly.c | 14 +-
lib/librte_ip_frag/rte_ipv6_fragmentation.c | 26 +-
lib/librte_ip_frag/rte_ipv6_reassembly.c | 6 +-
lib/librte_ipsec/crypto.h | 2 +-
lib/librte_ipsec/esp_inb.c | 10 +-
lib/librte_ipsec/esp_outb.c | 8 +-
lib/librte_ipsec/iph.h | 8 +-
lib/librte_ipsec/sa.c | 8 +-
lib/librte_kni/rte_kni.c | 4 +-
lib/librte_kni/rte_kni.h | 2 +-
lib/librte_net/rte_arp.c | 32 +-
lib/librte_net/rte_arp.h | 36 +--
lib/librte_net/rte_esp.h | 2 +-
lib/librte_net/rte_ether.h | 182 ++++++------
lib/librte_net/rte_gre.h | 2 +-
lib/librte_net/rte_icmp.h | 6 +-
lib/librte_net/rte_ip.h | 72 ++---
lib/librte_net/rte_net.c | 94 +++---
lib/librte_net/rte_net.h | 22 +-
lib/librte_net/rte_sctp.h | 2 +-
lib/librte_net/rte_tcp.h | 2 +-
lib/librte_net/rte_udp.h | 2 +-
lib/librte_pipeline/rte_table_action.c | 224 +++++++-------
lib/librte_pipeline/rte_table_action.h | 4 +-
lib/librte_port/rte_port_ras.c | 8 +-
lib/librte_port/rte_port_source_sink.c | 6 +-
lib/librte_vhost/vhost.h | 2 +-
lib/librte_vhost/virtio_net.c | 42 +--
388 files changed, 4145 insertions(+), 4145 deletions(-)
--
2.11.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [RFC v2 00/14] prefix network structures
@ 2019-04-10 8:32 1% ` Olivier Matz
2019-04-10 8:32 1% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-04-10 8:32 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit
This RFC targets 19.08.
The rte_net headers conflict with the libc headers, because
some definitions are duplicated, sometimes with few differences.
This RFC adds the rte_ (or RTE_) prefix to all structures, functions
and defines in rte_net library. This is a big changeset, that will
break the API of many functions, but not the ABI.
This was discussed in [1], and recently requested by the techboard [2].
v2:
* rebase on top of v19.05-rc1
[1] http://mails.dpdk.org/archives/dev/2018-January/087384.html
[2] http://mails.dpdk.org/archives/dev/2019-February/125033.html
Olivier Matz (14):
net: add rte prefix to arp structures
net: add rte prefix to arp defines
net: add rte prefix to ether structures
net: add rte prefix to ether functions
net: add rte prefix to ether defines
net: add rte prefix to esp structure
net: add rte prefix to gre structure
net: add rte prefix to icmp structure
net: add rte prefix to icmp defines
net: add rte prefix to ip structure
net: add rte prefix to ip defines
net: add rte prefix to sctp structure
net: add rte prefix to tcp structure
net: add rte prefix to udp structure
app/pdump/main.c | 2 +-
app/test-acl/main.c | 2 +-
app/test-eventdev/test_perf_common.c | 2 +-
app/test-eventdev/test_pipeline_common.c | 2 +-
app/test-pipeline/pipeline_acl.c | 16 +-
app/test-pipeline/pipeline_hash.c | 12 +-
app/test-pmd/cmdline.c | 90 +++---
app/test-pmd/cmdline_flow.c | 86 +++---
app/test-pmd/config.c | 34 +--
app/test-pmd/csumonly.c | 160 +++++-----
app/test-pmd/flowgen.c | 30 +-
app/test-pmd/icmpecho.c | 120 ++++----
app/test-pmd/ieee1588fwd.c | 18 +-
app/test-pmd/macfwd.c | 12 +-
app/test-pmd/macswap.h | 12 +-
app/test-pmd/macswap_common.h | 4 +-
app/test-pmd/macswap_neon.h | 12 +-
app/test-pmd/macswap_sse.h | 12 +-
app/test-pmd/parameters.c | 6 +-
app/test-pmd/testpmd.c | 22 +-
app/test-pmd/testpmd.h | 30 +-
app/test-pmd/txonly.c | 44 +--
app/test-pmd/util.c | 34 +--
app/test/packet_burst_generator.c | 126 ++++----
app/test/packet_burst_generator.h | 26 +-
app/test/test_acl.c | 8 +-
app/test/test_acl.h | 122 ++++----
app/test/test_cmdline_etheraddr.c | 16 +-
app/test/test_efd.c | 20 +-
app/test/test_event_eth_rx_adapter.c | 2 +-
app/test/test_event_eth_tx_adapter.c | 2 +-
app/test/test_flow_classify.c | 68 ++---
app/test/test_hash.c | 20 +-
app/test/test_ipsec.c | 12 +-
app/test/test_link_bonding.c | 284 +++++++++---------
app/test/test_link_bonding_mode4.c | 116 ++++----
app/test/test_link_bonding_rssconf.c | 6 +-
app/test/test_lpm.c | 76 ++---
app/test/test_lpm_perf.c | 10 +-
app/test/test_member.c | 20 +-
app/test/test_pmd_perf.c | 20 +-
app/test/test_sched.c | 20 +-
app/test/test_table_acl.c | 8 +-
app/test/test_thash.c | 12 +-
app/test/virtual_pmd.c | 6 +-
app/test/virtual_pmd.h | 2 +-
doc/guides/nics/kni.rst | 2 +-
doc/guides/prog_guide/bbdev.rst | 6 +-
.../prog_guide/packet_classif_access_ctrl.rst | 18 +-
doc/guides/prog_guide/rte_flow.rst | 4 +-
doc/guides/sample_app_ug/flow_classify.rst | 28 +-
doc/guides/sample_app_ug/flow_filtering.rst | 6 +-
doc/guides/sample_app_ug/ip_frag.rst | 16 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 16 +-
doc/guides/sample_app_ug/ipv4_multicast.rst | 16 +-
doc/guides/sample_app_ug/l2_forward_job_stats.rst | 6 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 6 +-
doc/guides/sample_app_ug/l3_forward.rst | 12 +-
doc/guides/sample_app_ug/link_status_intr.rst | 6 +-
doc/guides/sample_app_ug/ptpclient.rst | 6 +-
doc/guides/sample_app_ug/rxtx_callbacks.rst | 2 +-
doc/guides/sample_app_ug/server_node_efd.rst | 12 +-
doc/guides/sample_app_ug/skeleton.rst | 4 +-
doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 4 +-
drivers/bus/dpaa/base/fman/fman.c | 2 +-
drivers/bus/dpaa/base/fman/fman_hw.c | 2 +-
drivers/bus/dpaa/include/fman.h | 2 +-
drivers/bus/dpaa/include/netcfg.h | 4 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 6 +-
drivers/net/ark/ark_ethdev.c | 16 +-
drivers/net/ark/ark_ext.h | 4 +-
drivers/net/ark/ark_global.h | 4 +-
drivers/net/atlantic/atl_ethdev.c | 20 +-
drivers/net/atlantic/hw_atl/hw_atl_utils.c | 8 +-
drivers/net/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 +-
drivers/net/avp/avp_ethdev.c | 20 +-
drivers/net/avp/rte_avp_common.h | 2 +-
drivers/net/axgbe/axgbe_dev.c | 4 +-
drivers/net/axgbe/axgbe_ethdev.c | 10 +-
drivers/net/axgbe/axgbe_ethdev.h | 4 +-
drivers/net/axgbe/axgbe_rxtx.c | 2 +-
drivers/net/bnx2x/bnx2x.c | 16 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 4 +-
drivers/net/bnx2x/bnx2x_ethdev.h | 2 +-
drivers/net/bnx2x/bnx2x_vfpf.c | 8 +-
drivers/net/bnx2x/bnx2x_vfpf.h | 2 +-
drivers/net/bnx2x/ecore_sp.h | 2 +-
drivers/net/bnxt/bnxt.h | 4 +-
drivers/net/bnxt/bnxt_ethdev.c | 70 ++---
drivers/net/bnxt/bnxt_filter.c | 4 +-
drivers/net/bnxt/bnxt_filter.h | 8 +-
drivers/net/bnxt/bnxt_flow.c | 26 +-
drivers/net/bnxt/bnxt_hwrm.c | 40 +--
drivers/net/bnxt/bnxt_hwrm.h | 2 +-
drivers/net/bnxt/bnxt_ring.c | 8 +-
drivers/net/bnxt/bnxt_rxq.c | 2 +-
drivers/net/bnxt/bnxt_rxr.c | 2 +-
drivers/net/bnxt/bnxt_vnic.c | 2 +-
drivers/net/bnxt/rte_pmd_bnxt.c | 14 +-
drivers/net/bnxt/rte_pmd_bnxt.h | 4 +-
drivers/net/bonding/rte_eth_bond.h | 2 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 28 +-
drivers/net/bonding/rte_eth_bond_8023ad.h | 10 +-
drivers/net/bonding/rte_eth_bond_8023ad_private.h | 2 +-
drivers/net/bonding/rte_eth_bond_alb.c | 78 ++---
drivers/net/bonding/rte_eth_bond_alb.h | 10 +-
drivers/net/bonding/rte_eth_bond_api.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 2 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 194 ++++++-------
drivers/net/bonding/rte_eth_bond_private.h | 6 +-
drivers/net/cxgbe/base/adapter.h | 6 +-
drivers/net/cxgbe/base/t4_hw.c | 8 +-
drivers/net/cxgbe/cxgbe.h | 4 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 14 +-
drivers/net/cxgbe/cxgbe_filter.h | 2 +-
drivers/net/cxgbe/cxgbe_flow.c | 10 +-
drivers/net/cxgbe/cxgbe_main.c | 4 +-
drivers/net/cxgbe/cxgbe_pfvf.h | 2 +-
drivers/net/cxgbe/cxgbevf_main.c | 2 +-
drivers/net/cxgbe/l2t.c | 8 +-
drivers/net/cxgbe/l2t.h | 2 +-
drivers/net/cxgbe/mps_tcam.c | 14 +-
drivers/net/cxgbe/mps_tcam.h | 4 +-
drivers/net/cxgbe/sge.c | 8 +-
drivers/net/dpaa/dpaa_ethdev.c | 20 +-
drivers/net/dpaa/dpaa_rxtx.c | 22 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 36 +--
drivers/net/dpaa2/dpaa2_flow.c | 18 +-
drivers/net/e1000/e1000_ethdev.h | 4 +-
drivers/net/e1000/em_ethdev.c | 34 +--
drivers/net/e1000/em_rxtx.c | 22 +-
drivers/net/e1000/igb_ethdev.c | 70 ++---
drivers/net/e1000/igb_flow.c | 12 +-
drivers/net/e1000/igb_pf.c | 16 +-
drivers/net/e1000/igb_rxtx.c | 18 +-
drivers/net/ena/ena_ethdev.c | 16 +-
drivers/net/ena/ena_ethdev.h | 2 +-
drivers/net/enetc/base/enetc_hw.h | 4 +-
drivers/net/enetc/enetc_ethdev.c | 6 +-
drivers/net/enic/enic.h | 4 +-
drivers/net/enic/enic_clsf.c | 40 +--
drivers/net/enic/enic_ethdev.c | 28 +-
drivers/net/enic/enic_flow.c | 106 +++----
drivers/net/enic/enic_main.c | 4 +-
drivers/net/enic/enic_res.c | 4 +-
drivers/net/failsafe/failsafe.c | 6 +-
drivers/net/failsafe/failsafe_args.c | 4 +-
drivers/net/failsafe/failsafe_ether.c | 6 +-
drivers/net/failsafe/failsafe_ops.c | 6 +-
drivers/net/failsafe/failsafe_private.h | 4 +-
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 18 +-
drivers/net/i40e/base/i40e_adminq_cmd.h | 4 +-
drivers/net/i40e/base/i40e_common.c | 12 +-
drivers/net/i40e/base/i40e_prototype.h | 4 +-
drivers/net/i40e/i40e_ethdev.c | 136 ++++-----
drivers/net/i40e/i40e_ethdev.h | 22 +-
drivers/net/i40e/i40e_ethdev_vf.c | 62 ++--
drivers/net/i40e/i40e_fdir.c | 126 ++++----
drivers/net/i40e/i40e_flow.c | 58 ++--
drivers/net/i40e/i40e_pf.c | 18 +-
drivers/net/i40e/i40e_rxtx.c | 28 +-
drivers/net/i40e/i40e_vf_representor.c | 2 +-
drivers/net/i40e/rte_pmd_i40e.c | 30 +-
drivers/net/i40e/rte_pmd_i40e.h | 8 +-
drivers/net/iavf/base/iavf_adminq_cmd.h | 4 +-
drivers/net/iavf/base/iavf_common.c | 12 +-
drivers/net/iavf/base/iavf_prototype.h | 4 +-
drivers/net/iavf/iavf.h | 4 +-
drivers/net/iavf/iavf_ethdev.c | 50 ++--
drivers/net/iavf/iavf_rxtx.c | 14 +-
drivers/net/iavf/iavf_vchnl.c | 8 +-
drivers/net/ice/ice_ethdev.c | 62 ++--
drivers/net/ice/ice_ethdev.h | 4 +-
drivers/net/ice/ice_rxtx.c | 28 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 92 +++---
drivers/net/ixgbe/ixgbe_ethdev.h | 4 +-
drivers/net/ixgbe/ixgbe_flow.c | 22 +-
drivers/net/ixgbe/ixgbe_pf.c | 14 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +-
drivers/net/ixgbe/ixgbe_vf_representor.c | 4 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 10 +-
drivers/net/ixgbe/rte_pmd_ixgbe.h | 2 +-
drivers/net/kni/rte_eth_kni.c | 6 +-
drivers/net/liquidio/lio_ethdev.c | 22 +-
drivers/net/mlx4/mlx4.c | 4 +-
drivers/net/mlx4/mlx4.h | 8 +-
drivers/net/mlx4/mlx4_ethdev.c | 8 +-
drivers/net/mlx4/mlx4_flow.c | 14 +-
drivers/net/mlx4/mlx4_rxtx.c | 2 +-
drivers/net/mlx5/mlx5.c | 4 +-
drivers/net/mlx5/mlx5.h | 14 +-
drivers/net/mlx5/mlx5_flow.c | 22 +-
drivers/net/mlx5/mlx5_flow_dv.c | 44 +--
drivers/net/mlx5/mlx5_flow_tcf.c | 66 ++---
drivers/net/mlx5/mlx5_flow_verbs.c | 26 +-
drivers/net/mlx5/mlx5_mac.c | 18 +-
drivers/net/mlx5/mlx5_nl.c | 28 +-
drivers/net/mlx5/mlx5_rxtx.c | 6 +-
drivers/net/mlx5/mlx5_rxtx.h | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 8 +-
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 10 +-
drivers/net/mlx5/mlx5_trigger.c | 6 +-
drivers/net/mvneta/mvneta_ethdev.c | 22 +-
drivers/net/mvneta/mvneta_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_ethdev.c | 22 +-
drivers/net/mvpp2/mrvl_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_flow.c | 4 +-
drivers/net/netvsc/hn_ethdev.c | 4 +-
drivers/net/netvsc/hn_nvs.c | 2 +-
drivers/net/netvsc/hn_rndis.c | 2 +-
drivers/net/netvsc/hn_rxtx.c | 12 +-
drivers/net/netvsc/hn_var.h | 4 +-
drivers/net/netvsc/hn_vf.c | 8 +-
drivers/net/nfp/nfp_net.c | 20 +-
drivers/net/nfp/nfp_net_pmd.h | 2 +-
drivers/net/null/rte_eth_null.c | 6 +-
drivers/net/octeontx/octeontx_ethdev.c | 8 +-
drivers/net/octeontx/octeontx_ethdev.h | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 22 +-
drivers/net/qede/base/bcm_osal.h | 2 +-
drivers/net/qede/base/ecore_dev.c | 4 +-
drivers/net/qede/qede_ethdev.c | 58 ++--
drivers/net/qede/qede_ethdev.h | 6 +-
drivers/net/qede/qede_filter.c | 66 ++---
drivers/net/qede/qede_if.h | 4 +-
drivers/net/qede/qede_main.c | 6 +-
drivers/net/qede/qede_rxtx.c | 32 +-
drivers/net/qede/qede_rxtx.h | 2 +-
drivers/net/ring/rte_eth_ring.c | 4 +-
drivers/net/sfc/sfc.h | 2 +-
drivers/net/sfc/sfc_ef10_tx.c | 4 +-
drivers/net/sfc/sfc_ethdev.c | 20 +-
drivers/net/sfc/sfc_flow.c | 12 +-
drivers/net/sfc/sfc_port.c | 8 +-
drivers/net/sfc/sfc_tso.c | 4 +-
drivers/net/sfc/sfc_tso.h | 4 +-
drivers/net/softnic/parser.c | 18 +-
drivers/net/softnic/parser.h | 2 +-
drivers/net/softnic/rte_eth_softnic.c | 2 +-
drivers/net/softnic/rte_eth_softnic_flow.c | 4 +-
drivers/net/softnic/rte_eth_softnic_pipeline.c | 40 +--
drivers/net/szedata2/rte_eth_szedata2.c | 8 +-
drivers/net/tap/rte_eth_tap.c | 60 ++--
drivers/net/tap/rte_eth_tap.h | 2 +-
drivers/net/tap/tap_bpf_program.c | 14 +-
drivers/net/tap/tap_flow.c | 12 +-
drivers/net/thunderx/base/nicvf_mbox.c | 4 +-
drivers/net/thunderx/base/nicvf_plat.h | 2 +-
drivers/net/thunderx/nicvf_ethdev.c | 18 +-
drivers/net/thunderx/nicvf_struct.h | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 16 +-
drivers/net/vhost/rte_eth_vhost.c | 12 +-
drivers/net/virtio/virtio_ethdev.c | 72 ++---
drivers/net/virtio/virtio_pci.h | 4 +-
drivers/net/virtio/virtio_rxtx.c | 32 +-
drivers/net/virtio/virtio_user/vhost_kernel_tap.c | 2 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 6 +-
drivers/net/virtio/virtio_user/virtio_user_dev.h | 2 +-
drivers/net/virtio/virtio_user_ethdev.c | 8 +-
drivers/net/virtio/virtqueue.h | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 +-
drivers/net/vmxnet3/vmxnet3_ethdev.h | 2 +-
drivers/net/vmxnet3/vmxnet3_rxtx.c | 44 +--
examples/bbdev_app/main.c | 40 +--
examples/bond/main.c | 78 ++---
examples/distributor/main.c | 4 +-
examples/ethtool/ethtool-app/ethapp.c | 8 +-
examples/ethtool/ethtool-app/main.c | 10 +-
examples/ethtool/lib/rte_ethtool.c | 8 +-
examples/ethtool/lib/rte_ethtool.h | 6 +-
examples/eventdev_pipeline/main.c | 4 +-
examples/eventdev_pipeline/pipeline_common.h | 10 +-
examples/flow_classify/flow_classify.c | 30 +-
examples/flow_filtering/main.c | 10 +-
examples/ip_fragmentation/main.c | 64 ++--
examples/ip_pipeline/cli.c | 4 +-
examples/ip_pipeline/kni.c | 2 +-
examples/ip_pipeline/parser.c | 18 +-
examples/ip_pipeline/parser.h | 2 +-
examples/ip_pipeline/pipeline.c | 40 +--
examples/ip_reassembly/main.c | 50 ++--
examples/ipsec-secgw/esp.c | 42 +--
examples/ipsec-secgw/ipsec-secgw.c | 42 +--
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/parser.c | 4 +-
examples/ipsec-secgw/sa.c | 16 +-
examples/ipv4_multicast/main.c | 58 ++--
examples/kni/main.c | 14 +-
examples/l2fwd-cat/l2fwd-cat.c | 4 +-
examples/l2fwd-crypto/main.c | 26 +-
examples/l2fwd-jobstats/main.c | 8 +-
examples/l2fwd-keepalive/main.c | 8 +-
examples/l2fwd/main.c | 8 +-
examples/l3fwd-acl/main.c | 102 +++----
examples/l3fwd-power/main.c | 100 +++----
examples/l3fwd-vf/main.c | 68 ++---
examples/l3fwd/l3fwd.h | 8 +-
examples/l3fwd/l3fwd_altivec.h | 14 +-
examples/l3fwd/l3fwd_common.h | 4 +-
examples/l3fwd/l3fwd_em.c | 44 +--
examples/l3fwd/l3fwd_em.h | 20 +-
examples/l3fwd/l3fwd_em_hlm.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_neon.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_sse.h | 16 +-
examples/l3fwd/l3fwd_em_sequential.h | 16 +-
examples/l3fwd/l3fwd_lpm.c | 50 ++--
examples/l3fwd/l3fwd_lpm.h | 20 +-
examples/l3fwd/l3fwd_lpm_altivec.h | 20 +-
examples/l3fwd/l3fwd_lpm_neon.h | 30 +-
examples/l3fwd/l3fwd_lpm_sse.h | 20 +-
examples/l3fwd/l3fwd_neon.h | 14 +-
examples/l3fwd/l3fwd_sse.h | 14 +-
examples/l3fwd/main.c | 20 +-
examples/link_status_interrupt/main.c | 8 +-
examples/load_balancer/runtime.c | 6 +-
.../client_server_mp/mp_server/main.c | 2 +-
examples/packet_ordering/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 322 ++++++++++-----------
examples/ptpclient/ptpclient.c | 32 +-
examples/qos_meter/main.c | 4 +-
examples/qos_sched/init.c | 2 +-
examples/quota_watermark/qw/main.c | 8 +-
examples/rxtx_callbacks/main.c | 4 +-
examples/server_node_efd/node/node.c | 6 +-
examples/server_node_efd/server/main.c | 8 +-
examples/skeleton/basicfwd.c | 4 +-
examples/tep_termination/main.c | 2 +-
examples/tep_termination/main.h | 2 +-
examples/tep_termination/vxlan.c | 108 +++----
examples/tep_termination/vxlan.h | 8 +-
examples/tep_termination/vxlan_setup.c | 30 +-
examples/tep_termination/vxlan_setup.h | 2 +-
examples/vhost/main.c | 40 +--
examples/vhost/main.h | 2 +-
examples/vm_power_manager/channel_monitor.c | 12 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/main.c | 6 +-
examples/vmdq/main.c | 12 +-
examples/vmdq_dcb/main.c | 12 +-
lib/librte_ethdev/rte_class_eth.c | 4 +-
lib/librte_ethdev/rte_eth_ctrl.h | 12 +-
lib/librte_ethdev/rte_ethdev.c | 58 ++--
lib/librte_ethdev/rte_ethdev.h | 14 +-
lib/librte_ethdev/rte_ethdev_core.h | 12 +-
lib/librte_ethdev/rte_flow.h | 32 +-
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 32 +-
lib/librte_gro/gro_tcp4.c | 26 +-
lib/librte_gro/gro_tcp4.h | 22 +-
lib/librte_gro/gro_vxlan_tcp4.c | 64 ++--
lib/librte_gro/gro_vxlan_tcp4.h | 6 +-
lib/librte_gso/gso_common.h | 16 +-
lib/librte_gso/gso_tcp4.c | 12 +-
lib/librte_gso/gso_tunnel_tcp4.c | 14 +-
lib/librte_gso/gso_udp4.c | 8 +-
lib/librte_gso/rte_gso.h | 8 +-
lib/librte_hash/rte_thash.h | 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 12 +-
lib/librte_ip_frag/rte_ipv4_fragmentation.c | 42 +--
lib/librte_ip_frag/rte_ipv4_reassembly.c | 14 +-
lib/librte_ip_frag/rte_ipv6_fragmentation.c | 26 +-
lib/librte_ip_frag/rte_ipv6_reassembly.c | 6 +-
lib/librte_ipsec/crypto.h | 2 +-
lib/librte_ipsec/esp_inb.c | 10 +-
lib/librte_ipsec/esp_outb.c | 8 +-
lib/librte_ipsec/iph.h | 8 +-
lib/librte_ipsec/sa.c | 8 +-
lib/librte_kni/rte_kni.c | 4 +-
lib/librte_kni/rte_kni.h | 2 +-
lib/librte_net/rte_arp.c | 32 +-
lib/librte_net/rte_arp.h | 36 +--
lib/librte_net/rte_esp.h | 2 +-
lib/librte_net/rte_ether.h | 182 ++++++------
lib/librte_net/rte_gre.h | 2 +-
lib/librte_net/rte_icmp.h | 6 +-
lib/librte_net/rte_ip.h | 72 ++---
lib/librte_net/rte_net.c | 94 +++---
lib/librte_net/rte_net.h | 22 +-
lib/librte_net/rte_sctp.h | 2 +-
lib/librte_net/rte_tcp.h | 2 +-
lib/librte_net/rte_udp.h | 2 +-
lib/librte_pipeline/rte_table_action.c | 224 +++++++-------
lib/librte_pipeline/rte_table_action.h | 4 +-
lib/librte_port/rte_port_ras.c | 8 +-
lib/librte_port/rte_port_source_sink.c | 6 +-
lib/librte_vhost/vhost.h | 2 +-
lib/librte_vhost/virtio_net.c | 42 +--
388 files changed, 4145 insertions(+), 4145 deletions(-)
--
2.11.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 5:14 9% ` [dpdk-dev] " Honnappa Nagarahalli
@ 2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
2 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-10 5:14 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: Honnappa Nagarahalli, nd, nd
>
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received from
> a number of users of DPDK about ABI churn. In turn this feedback then
> prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
This link can be used to check which structures are not needed to be exposed to the application.
For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> I guess the short story is that DPDK ABI hasn't really settled down as the
> project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive releases
> since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant re-integration
> and re-validation effort for new versions of DPDK. This effort from their
> perspective may not add value to their consuming project, particular if
> they are only updating to "stay current".
Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their projects
> to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS releases.
> A final removal notice will be published to the DPDK Mailing List, and if
> there are no strong objections only then an API may be removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
+1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
<snip>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
@ 2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-10 5:14 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: Honnappa Nagarahalli, nd, nd
>
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received from
> a number of users of DPDK about ABI churn. In turn this feedback then
> prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
This link can be used to check which structures are not needed to be exposed to the application.
For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> I guess the short story is that DPDK ABI hasn't really settled down as the
> project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive releases
> since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant re-integration
> and re-validation effort for new versions of DPDK. This effort from their
> perspective may not add value to their consuming project, particular if
> they are only updating to "stay current".
Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their projects
> to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS releases.
> A final removal notice will be published to the DPDK Mailing List, and if
> there are no strong objections only then an API may be removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
+1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
<snip>
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission
2019-04-09 17:36 4% [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission Rami Rosen
@ 2019-04-09 17:36 4% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-04-09 17:36 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, pablo.de.lara.guarch, akhil.goyal, john.mcnamara,
marko.kovacevic, Rami Rosen, stable
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for new network ethernet
PMDs it should be dpdk-next-net, and for new crypto PMDs
it should be dpdk-next-crypto. Though this may seem obvious, it
is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
doc/guides/contributing/patches.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..4dde8e724 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* If you add a new network PMD you should prepare the initial submission against dpdk-next-net repo.
+
+* If you add a new crypto PMD you should prepare the initial submission against dpdk-next-crypto repo.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission
@ 2019-04-09 17:36 4% Rami Rosen
2019-04-09 17:36 4% ` Rami Rosen
0 siblings, 1 reply; 200+ results
From: Rami Rosen @ 2019-04-09 17:36 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, pablo.de.lara.guarch, akhil.goyal, john.mcnamara,
marko.kovacevic, Rami Rosen, stable
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for new network ethernet
PMDs it should be dpdk-next-net, and for new crypto PMDs
it should be dpdk-next-crypto. Though this may seem obvious, it
is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
doc/guides/contributing/patches.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..4dde8e724 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* If you add a new network PMD you should prepare the initial submission against dpdk-next-net repo.
+
+* If you add a new crypto PMD you should prepare the initial submission against dpdk-next-crypto repo.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-09 9:42 4% ` Ray Kinsella
@ 2019-04-09 9:42 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-09 9:42 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 14:38, Burakov, Anatoly wrote:
> On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>>
>>
>> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> [SNIP]
>> [SNIP]
[SNIP]
>>
>
> Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
> specification" i don't mean there literally should be a document with a
> formal specification :)
When I hear the word specification I think encyclopedia-like stacks of
paper.
>
> Rather, i'm thinking more along the lines of, let's take a look at what
> we have, and think of ways we can reduce the amount of code and improve
> things without causing major inconveniences to great majority of users.
> As in, if we want to "break once more and then never again", then maybe
> instead of small incremental fixes here and there, we could actually do
> a more drastic change that keeps perhaps 90% users happy instead of
> 100%, but which reduces maintenance/validation effort from 100% down to
> 30%.
Agreed - all I would propose on top of this is that we give ourselves a
real deadline.
The DPDK API has been iterating since 2012 and while we can spare a few
more months to do tidy-up and get it right, we _do_ need to draw a line
in the sand at the same time.
>
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
> However, what *could* be realistic is to trim down complexity in EAL
> init and system code in general - to me (again, a concrete proposal!),
> that would be dropping igb_uio and supporting upstream kernel modules
> only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
> support and legacy mem modes, and perhaps bumping kernel version and
> removing some compatibility code as well. This would remove potentially
> thousands of lines of code and keep EAL cleaner and more maintainable:
> right now, we have two different hotplug mechanisms (UIO and VFIO), lots
> of different memory/interrupt modes, etc., for no reason that is readily
> apparent to me.
>
> So, as you can see, an effort to review and delineate what we want to
> support would be necessary if we want to ease the maintenance burden for
> either myself or anyone that inherits this code, as well as reducing the
> number of moving parts and, as a consequence, validation effort and
> amount of bugs. We can't simply do it in a random release "just
> because", but if we were to "break once more and then never again",
> perhaps this is something that could be considered.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-09 9:42 4% ` Ray Kinsella
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-09 9:42 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 14:38, Burakov, Anatoly wrote:
> On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>>
>>
>> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> [SNIP]
>> [SNIP]
[SNIP]
>>
>
> Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
> specification" i don't mean there literally should be a document with a
> formal specification :)
When I hear the word specification I think encyclopedia-like stacks of
paper.
>
> Rather, i'm thinking more along the lines of, let's take a look at what
> we have, and think of ways we can reduce the amount of code and improve
> things without causing major inconveniences to great majority of users.
> As in, if we want to "break once more and then never again", then maybe
> instead of small incremental fixes here and there, we could actually do
> a more drastic change that keeps perhaps 90% users happy instead of
> 100%, but which reduces maintenance/validation effort from 100% down to
> 30%.
Agreed - all I would propose on top of this is that we give ourselves a
real deadline.
The DPDK API has been iterating since 2012 and while we can spare a few
more months to do tidy-up and get it right, we _do_ need to draw a line
in the sand at the same time.
>
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
> However, what *could* be realistic is to trim down complexity in EAL
> init and system code in general - to me (again, a concrete proposal!),
> that would be dropping igb_uio and supporting upstream kernel modules
> only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
> support and legacy mem modes, and perhaps bumping kernel version and
> removing some compatibility code as well. This would remove potentially
> thousands of lines of code and keep EAL cleaner and more maintainable:
> right now, we have two different hotplug mechanisms (UIO and VFIO), lots
> of different memory/interrupt modes, etc., for no reason that is readily
> apparent to me.
>
> So, as you can see, an effort to review and delineate what we want to
> support would be necessary if we want to ease the maintenance burden for
> either myself or anyone that inherits this code, as well as reducing the
> number of moving parts and, as a consequence, validation effort and
> amount of bugs. We can't simply do it in a random release "just
> because", but if we were to "break once more and then never again",
> perhaps this is something that could be considered.
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-08 18:25 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
THIS BREAKS ABI OF PREVIOUS RELEASES.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7687fe650f64..bc416bc8c19f 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f6688327cad3..2f175f58ed42 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-08 18:25 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Most of these functions are not marked as experimental since
we want applications to convert over asap. The one exception is
the return_code, which is only used by some tests now and not
clear that it is even that useful.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 52 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..4beea5705be7 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..c3cf5a06269d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7687fe650f64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
@@ -193,7 +215,7 @@ rte_lcore_to_socket_id(unsigned lcore_id)
* True if the given lcore is enabled; false otherwise.
*/
static inline int
-rte_lcore_is_enabled(unsigned lcore_id)
+rte_lcore_is_enabled(unsigned int lcore_id)
{
struct rte_config *cfg = rte_eal_get_configuration();
if (lcore_id >= RTE_MAX_LCORE)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
THIS BREAKS ABI OF PREVIOUS RELEASES.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7687fe650f64..bc416bc8c19f 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f6688327cad3..2f175f58ed42 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
@ 2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Most of these functions are not marked as experimental since
we want applications to convert over asap. The one exception is
the return_code, which is only used by some tests now and not
clear that it is even that useful.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 52 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..4beea5705be7 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..c3cf5a06269d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7687fe650f64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
@@ -193,7 +215,7 @@ rte_lcore_to_socket_id(unsigned lcore_id)
* True if the given lcore is enabled; false otherwise.
*/
static inline int
-rte_lcore_is_enabled(unsigned lcore_id)
+rte_lcore_is_enabled(unsigned int lcore_id)
{
struct rte_config *cfg = rte_eal_get_configuration();
if (lcore_id >= RTE_MAX_LCORE)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v1 0/5] make lcore_config internal
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
@ 2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure
internal to EAL and not part of the ABI. It supersedes
earlier RFC.
The first 4 would go into current release, and the
last would go into later release to make it fully
internal.
The same should be done for rte_config, but that
is more difficult.
Stephen Hemminger (5):
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
eal: make lcore_config private
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 ++---
app/test/test_ring_perf.c | 22 ++++---
app/test/test_stack_perf.c | 20 +++---
doc/guides/rel_notes/release_19_05.rst | 7 +++
drivers/bus/dpaa/dpaa_bus.c | 6 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 4 +-
lib/librte_eal/common/eal_common_launch.c | 2 +
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++
lib/librte_eal/common/eal_private.h | 22 +++++++
lib/librte_eal/common/include/rte_lcore.h | 76 +++++++++++------------
lib/librte_eal/common/rte_service.c | 2 +
lib/librte_eal/rte_eal_version.map | 12 +++-
14 files changed, 159 insertions(+), 73 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1 0/5] make lcore_config internal
@ 2019-04-08 18:25 3% Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure
internal to EAL and not part of the ABI. It supersedes
earlier RFC.
The first 4 would go into current release, and the
last would go into later release to make it fully
internal.
The same should be done for rte_config, but that
is more difficult.
Stephen Hemminger (5):
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
eal: make lcore_config private
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 ++---
app/test/test_ring_perf.c | 22 ++++---
app/test/test_stack_perf.c | 20 +++---
doc/guides/rel_notes/release_19_05.rst | 7 +++
drivers/bus/dpaa/dpaa_bus.c | 6 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 4 +-
lib/librte_eal/common/eal_common_launch.c | 2 +
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++
lib/librte_eal/common/eal_private.h | 22 +++++++
lib/librte_eal/common/include/rte_lcore.h | 76 +++++++++++------------
lib/librte_eal/common/rte_service.c | 2 +
lib/librte_eal/rte_eal_version.map | 12 +++-
14 files changed, 159 insertions(+), 73 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:49 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
@ 2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:49 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:50 4% ` Burakov, Anatoly
@ 2019-04-08 15:50 4% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:50 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
` (2 preceding siblings ...)
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:50 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:13 4% ` Stephen Hemminger
@ 2019-04-08 15:13 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 15:13 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, Ray Kinsella, Thomas Monjalon, techboard,
Bruce Richardson, dev, Kevin Traynor
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
>
> > On 08-Apr-19 2:58 PM, David Marchand wrote:
> > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> > >
> > > As a concrete proposal, my number one dream would be to see
> > > multiprocess
> > > gone. I also recall desire for "DPDK to be more lightweight", and i
> > > maintain that DPDK *cannot* be lightweight if we are to support
> > > multiprocess - we can have one or the other, but not both. However,
> > > realistically, i don't think dropping multiprocess is ever going to
> > > happen - not only it is too entrenched in DPDK use cases, it is
> > > actually
> > > quite useful despite its flaws.
> > >
> > >
> > > Well, honestly, I'd like to hear about this.
> > > What are the real usecases for multi process support?
> > > Do we have even a single opensource project that uses it?
> > >
> >
> > I'm aware of a few closed source usages of multiprocess. I also think
> > current versions of collectd rely on secondary process (there's been a
> > Telemetry API added to avoid that, but AFAIK the support for Telemetry
> > is not upstream in collectd yet), and so do/would any dump-style
> > applications - in fact, we ourselves include one such application in our
> > codebase (pdump, proc-info, etc.).
> >
>
> Sorry, I don't want to highjack this thread, I can start a separate thread
> if people feel like it.
> If we go with stabilisation, we must be careful that we want to support the
> features.
>
> So about multiprocess, again, in those closed source projects you know of,
> what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is not
> that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
>
>
Yes, there are several closed source applications using multi-process.
But the problem with that is no one tests with all the drivers, api's and
configurations in DPDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
@ 2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 15:13 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, Ray Kinsella, Thomas Monjalon, techboard,
Bruce Richardson, dev, Kevin Traynor
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
>
> > On 08-Apr-19 2:58 PM, David Marchand wrote:
> > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> > >
> > > As a concrete proposal, my number one dream would be to see
> > > multiprocess
> > > gone. I also recall desire for "DPDK to be more lightweight", and i
> > > maintain that DPDK *cannot* be lightweight if we are to support
> > > multiprocess - we can have one or the other, but not both. However,
> > > realistically, i don't think dropping multiprocess is ever going to
> > > happen - not only it is too entrenched in DPDK use cases, it is
> > > actually
> > > quite useful despite its flaws.
> > >
> > >
> > > Well, honestly, I'd like to hear about this.
> > > What are the real usecases for multi process support?
> > > Do we have even a single opensource project that uses it?
> > >
> >
> > I'm aware of a few closed source usages of multiprocess. I also think
> > current versions of collectd rely on secondary process (there's been a
> > Telemetry API added to avoid that, but AFAIK the support for Telemetry
> > is not upstream in collectd yet), and so do/would any dump-style
> > applications - in fact, we ourselves include one such application in our
> > codebase (pdump, proc-info, etc.).
> >
>
> Sorry, I don't want to highjack this thread, I can start a separate thread
> if people feel like it.
> If we go with stabilisation, we must be careful that we want to support the
> features.
>
> So about multiprocess, again, in those closed source projects you know of,
> what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is not
> that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
>
>
Yes, there are several closed source applications using multi-process.
But the problem with that is no one tests with all the drivers, api's and
configurations in DPDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
@ 2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-04-08 14:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight", and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both. However,
> > realistically, i don't think dropping multiprocess is ever going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in our
> codebase (pdump, proc-info, etc.).
>
Sorry, I don't want to highjack this thread, I can start a separate thread
if people feel like it.
If we go with stabilisation, we must be careful that we want to support the
features.
So about multiprocess, again, in those closed source projects you know of,
what are the usecases?
For what we provide in dpdk pdump, proc-info, referring to oneself is not
that convincing to me as I don't use those tools.
I don't see what we could not achieve the same with a control thread
running in the dpdk process and handling commands.
It would be open to the outside via a more standard channel, like a UNIX
socket or something like this.
If we need to declare a dynamic channel, it can be constructed as an
extension of the existing standard channel: we can open something like a
POSIX shm and push things in it.
Was this explored ?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
@ 2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: David Marchand @ 2019-04-08 14:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight", and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both. However,
> > realistically, i don't think dropping multiprocess is ever going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in our
> codebase (pdump, proc-info, etc.).
>
Sorry, I don't want to highjack this thread, I can start a separate thread
if people feel like it.
If we go with stabilisation, we must be careful that we want to support the
features.
So about multiprocess, again, in those closed source projects you know of,
what are the usecases?
For what we provide in dpdk pdump, proc-info, referring to oneself is not
that convincing to me as I don't use those tools.
I don't see what we could not achieve the same with a control thread
running in the dpdk process and handling commands.
It would be open to the outside via a more standard channel, like a UNIX
socket or something like this.
If we need to declare a dynamic channel, it can be constructed as an
extension of the existing standard channel: we can open something like a
POSIX shm and push things in it.
Was this explored ?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:02 4% ` Burakov, Anatoly
@ 2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 14:02 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 2:58 PM, David Marchand wrote:
> On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> As a concrete proposal, my number one dream would be to see
> multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is
> actually
> quite useful despite its flaws.
>
>
> Well, honestly, I'd like to hear about this.
> What are the real usecases for multi process support?
> Do we have even a single opensource project that uses it?
>
I'm aware of a few closed source usages of multiprocess. I also think
current versions of collectd rely on secondary process (there's been a
Telemetry API added to avoid that, but AFAIK the support for Telemetry
is not upstream in collectd yet), and so do/would any dump-style
applications - in fact, we ourselves include one such application in our
codebase (pdump, proc-info, etc.).
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 14:02 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 2:58 PM, David Marchand wrote:
> On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> As a concrete proposal, my number one dream would be to see
> multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is
> actually
> quite useful despite its flaws.
>
>
> Well, honestly, I'd like to hear about this.
> What are the real usecases for multi process support?
> Do we have even a single opensource project that uses it?
>
I'm aware of a few closed source usages of multiprocess. I also think
current versions of collectd rely on secondary process (there's been a
Telemetry API added to avoid that, but AFAIK the support for Telemetry
is not upstream in collectd yet), and so do/would any dump-style
applications - in fact, we ourselves include one such application in our
codebase (pdump, proc-info, etc.).
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-08 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
Well, honestly, I'd like to hear about this.
What are the real usecases for multi process support?
Do we have even a single opensource project that uses it?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
@ 2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-04-08 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
Well, honestly, I'd like to hear about this.
What are the real usecases for multi process support?
Do we have even a single opensource project that uses it?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
@ 2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 13:38 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>
>
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
>
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
>
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
>
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
>
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
>
Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
specification" i don't mean there literally should be a document with a
formal specification :)
Rather, i'm thinking more along the lines of, let's take a look at what
we have, and think of ways we can reduce the amount of code and improve
things without causing major inconveniences to great majority of users.
As in, if we want to "break once more and then never again", then maybe
instead of small incremental fixes here and there, we could actually do
a more drastic change that keeps perhaps 90% users happy instead of
100%, but which reduces maintenance/validation effort from 100% down to 30%.
As a concrete proposal, my number one dream would be to see multiprocess
gone. I also recall desire for "DPDK to be more lightweight", and i
maintain that DPDK *cannot* be lightweight if we are to support
multiprocess - we can have one or the other, but not both. However,
realistically, i don't think dropping multiprocess is ever going to
happen - not only it is too entrenched in DPDK use cases, it is actually
quite useful despite its flaws.
However, what *could* be realistic is to trim down complexity in EAL
init and system code in general - to me (again, a concrete proposal!),
that would be dropping igb_uio and supporting upstream kernel modules
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
support and legacy mem modes, and perhaps bumping kernel version and
removing some compatibility code as well. This would remove potentially
thousands of lines of code and keep EAL cleaner and more maintainable:
right now, we have two different hotplug mechanisms (UIO and VFIO), lots
of different memory/interrupt modes, etc., for no reason that is readily
apparent to me.
So, as you can see, an effort to review and delineate what we want to
support would be necessary if we want to ease the maintenance burden for
either myself or anyone that inherits this code, as well as reducing the
number of moving parts and, as a consequence, validation effort and
amount of bugs. We can't simply do it in a random release "just
because", but if we were to "break once more and then never again",
perhaps this is something that could be considered.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
@ 2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 13:38 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>
>
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
>
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
>
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
>
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
>
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
>
Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
specification" i don't mean there literally should be a document with a
formal specification :)
Rather, i'm thinking more along the lines of, let's take a look at what
we have, and think of ways we can reduce the amount of code and improve
things without causing major inconveniences to great majority of users.
As in, if we want to "break once more and then never again", then maybe
instead of small incremental fixes here and there, we could actually do
a more drastic change that keeps perhaps 90% users happy instead of
100%, but which reduces maintenance/validation effort from 100% down to 30%.
As a concrete proposal, my number one dream would be to see multiprocess
gone. I also recall desire for "DPDK to be more lightweight", and i
maintain that DPDK *cannot* be lightweight if we are to support
multiprocess - we can have one or the other, but not both. However,
realistically, i don't think dropping multiprocess is ever going to
happen - not only it is too entrenched in DPDK use cases, it is actually
quite useful despite its flaws.
However, what *could* be realistic is to trim down complexity in EAL
init and system code in general - to me (again, a concrete proposal!),
that would be dropping igb_uio and supporting upstream kernel modules
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
support and legacy mem modes, and perhaps bumping kernel version and
removing some compatibility code as well. This would remove potentially
thousands of lines of code and keep EAL cleaner and more maintainable:
right now, we have two different hotplug mechanisms (UIO and VFIO), lots
of different memory/interrupt modes, etc., for no reason that is readily
apparent to me.
So, as you can see, an effort to review and delineate what we want to
support would be necessary if we want to ease the maintenance burden for
either myself or anyone that inherits this code, as well as reducing the
number of moving parts and, as a consequence, validation effort and
amount of bugs. We can't simply do it in a random release "just
because", but if we were to "break once more and then never again",
perhaps this is something that could be considered.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:00 4% ` Ray Kinsella
@ 2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 13:00 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 11:15, Burakov, Anatoly wrote:
> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>> [SNIP]
[SNIP]
>
> My worry here is that some API's get more attention than others, but
> requirements for freezing the API/ABI are applicable to all of them.
>
> Everyone loves discussing specifics of mbufs and dev API's, and I have
> no doubt that DPDK community can arrive at a consensus with regards to
> mbuf format etc. in a timely manner, since everyone has a vested
> interest in those covering their use cases.
> I have way less confidence
> in us possibly having saner and more maintainable platform
> initialization code,
I think you are right, however its that same lack of enthusiasm that
would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
specification effort becoming an endless process, as it would always be
low on DPDK contributors priority list.
Instead I recommend we set an API freeze date to focus peoples minds,
advertise what it means and contributors will respond and look after the
areas they care/are responsible for.
> simply because any attempt to change those will
> likely be met with "please keep all of the old stuff working", which
> gets us right back to where we started.
>
And to be honest that is a fair enough expectation from them, right?
To Stephen's if we need to break it, let's do it once more and then
never again.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 13:00 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 11:15, Burakov, Anatoly wrote:
> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>> [SNIP]
[SNIP]
>
> My worry here is that some API's get more attention than others, but
> requirements for freezing the API/ABI are applicable to all of them.
>
> Everyone loves discussing specifics of mbufs and dev API's, and I have
> no doubt that DPDK community can arrive at a consensus with regards to
> mbuf format etc. in a timely manner, since everyone has a vested
> interest in those covering their use cases.
> I have way less confidence
> in us possibly having saner and more maintainable platform
> initialization code,
I think you are right, however its that same lack of enthusiasm that
would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
specification effort becoming an endless process, as it would always be
low on DPDK contributors priority list.
Instead I recommend we set an API freeze date to focus peoples minds,
advertise what it means and contributors will respond and look after the
areas they care/are responsible for.
> simply because any attempt to change those will
> likely be met with "please keep all of the old stuff working", which
> gets us right back to where we started.
>
And to be honest that is a fair enough expectation from them, right?
To Stephen's if we need to break it, let's do it once more and then
never again.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 10:15 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
>> 04/04/2019 16:07, Burakov, Anatoly:
>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
>>> So, if we are to cement our core API - we have to make a concrete effort
>>> to specify what goes and what stays, if we want it to be maintainable.
>>> The DPDK 1.0 specification, if you will :)
>>
>> "DPDK 1.0 specification", that's a great project name :-)
>>
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
>
My worry here is that some API's get more attention than others, but
requirements for freezing the API/ABI are applicable to all of them.
Everyone loves discussing specifics of mbufs and dev API's, and I have
no doubt that DPDK community can arrive at a consensus with regards to
mbuf format etc. in a timely manner, since everyone has a vested
interest in those covering their use cases. I have way less confidence
in us possibly having saner and more maintainable platform
initialization code, simply because any attempt to change those will
likely be met with "please keep all of the old stuff working", which
gets us right back to where we started.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
@ 2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-14 0:42 9% ` Neil Horman
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 10:15 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
>> 04/04/2019 16:07, Burakov, Anatoly:
>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
>>> So, if we are to cement our core API - we have to make a concrete effort
>>> to specify what goes and what stays, if we want it to be maintainable.
>>> The DPDK 1.0 specification, if you will :)
>>
>> "DPDK 1.0 specification", that's a great project name :-)
>>
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
>
My worry here is that some API's get more attention than others, but
requirements for freezing the API/ABI are applicable to all of them.
Everyone loves discussing specifics of mbufs and dev API's, and I have
no doubt that DPDK community can arrive at a consensus with regards to
mbuf format etc. in a timely manner, since everyone has a vested
interest in those covering their use cases. I have way less confidence
in us possibly having saner and more maintainable platform
initialization code, simply because any attempt to change those will
likely be met with "please keep all of the old stuff working", which
gets us right back to where we started.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
@ 2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-14 0:42 9% ` Neil Horman
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 9:04 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 07/04/2019 10:48, Thomas Monjalon wrote:
> 04/04/2019 16:07, Burakov, Anatoly:
>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>> So, if we are to cement our core API - we have to make a concrete effort
>> to specify what goes and what stays, if we want it to be maintainable.
>> The DPDK 1.0 specification, if you will :)
>
> "DPDK 1.0 specification", that's a great project name :-)
>
Honestly - I would say that I am nervous of this.
The definition of a DPDK 1.0 specification as a gate to API stability,
feels like a "great plan tomorrow" instead of a "good plan" today. I
think that getting people to dedicate time to such a specification might
prove problematic and I could see this effort being very time consuming.
It might never get completed.
My preference would be to instead adopt a well-publicised community
timeline for adopting more conservative API maintenance rules.
Perhaps we could give ourselves as a community a time-limited window in
which to address concerns around the API before they become hardened -
perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
to 9 months.
We then would know the timeline when niggles like exposure of internal
structures and mbuf structure needed to be sorted by and could
prioritize accordingly.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
@ 2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 9:04 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 07/04/2019 10:48, Thomas Monjalon wrote:
> 04/04/2019 16:07, Burakov, Anatoly:
>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>> So, if we are to cement our core API - we have to make a concrete effort
>> to specify what goes and what stays, if we want it to be maintainable.
>> The DPDK 1.0 specification, if you will :)
>
> "DPDK 1.0 specification", that's a great project name :-)
>
Honestly - I would say that I am nervous of this.
The definition of a DPDK 1.0 specification as a gate to API stability,
feels like a "great plan tomorrow" instead of a "good plan" today. I
think that getting people to dedicate time to such a specification might
prove problematic and I could see this effort being very time consuming.
It might never get completed.
My preference would be to instead adopt a well-publicised community
timeline for adopting more conservative API maintenance rules.
Perhaps we could give ourselves as a community a time-limited window in
which to address concerns around the API before they become hardened -
perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
to 9 months.
We then would know the timeline when niggles like exposure of internal
structures and mbuf structure needed to be sorted by and could
prioritize accordingly.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:48 4% ` Thomas Monjalon
@ 2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:48 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: techboard, Ray Kinsella, Bruce Richardson, dev, Kevin Traynor
04/04/2019 16:07, Burakov, Anatoly:
> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > On 04/04/2019 11:54, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >> Actually, I think we *do* need to constrain the pace of development for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project - it
> >> should just start acting like it.
> >
> > I 100% agree.
> >
> > If you break your users stuff regularly enough, they will eventually
> > start looking around for an alternative that doesn't break their stuff
> > quiet so regularly.
> >
> > We often use the pace of innovation in DPDK as justification for ABI/API
> > breakages, but that approach is a real rarity among the Open Source
> > community. I can't think of any mature project off-hand that share's it.
> >
> > I would ask is Linux any less innovative because they offer a stable API
> > and have an absolute commitment to never breaking userspace? Would Linux
> > have ever been as popular as it is today it they broke userspace every
> > quarter?
> >
> > They reality is that they (Linux) find workarounds and compromise
> > because there is an uber-maintainer Linus who had a strong ethos from
> > the start not to break their users stuff - we need the same ethos in DPDK.
> >
> >>
> >> Now, in terms of features like the memory rework, that is indeed a case
> >> that there was no alternative other than a massive ABI break. However, for
> >> that rework there was a strong need for improvement in that area that we
> >> can make the case for an ABI break to support it - and it is of a scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are of
> >> that scale.
> >
> > I would also be inclined to agree with Bruce's points on memory rework
> > was somewhat of an outlier, we don't see many like it.
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should reduce
> >> the scope for ABI breaks.
> >> 2. Once done, I think we should commit to having an ABI break only in the
> >> rarest of circumstances, and only with very large justification. I want us
> >> to get to the point where DPDK releases can immediately be picked up by all
> >> linux distros and rolled out because they are ABI compatible.
> >
> > The work that Anatoly describes removing APIs that exposed internal
> > structures and Stephen H's RFC similarly are good examples of the kind
> > of work required to prepare for this change. We need to take a good look
> > at the API and reduce the number of unnecessary internal structures
> > exposed.
> >
> > I never expected it going to to be a big bang - but is a definite
> > direction we need to move towards over the next few release.
>
> ...in this case, we have to think long and hard about the fabled EAL
> rework/split, and in general *specifying* what is it that we want to
> support, and the use cases that we want to target. Right now there is a
> huge mountain of technical debt and kludges and workarounds that has
> accumulated over the years, and it exists precisely because "every
> change breaks someone's workflow".
>
> For example, just in memory subsystem alone, we have legacy mem, because
> some use cases require huge amounts of contiguous memory, and not
> everyone is using VFIO; there's all of the 32-bit related workarounds
> and hacks; there's the single-file-segments stuff that could have been
> the default if not for the fact that we support kernels that don't
> support fallocate(); there are two different ways of doing in-memory
> mode, because not all kernels support memfd's; there is a gargantuan
> pile of workarounds (and "known issues", and just code in general) all
> over the DPDK codebase just to support our multiprocess model and all of
> the various warts that come with it.
>
> In fact, i would even go as far as to say that *most* of EAL ABI breaks
> have been due to the fact that we store data in shared memory because of
> multiprocess - so there is simply no way we can change these internal
> data structures without ABI breaks, because even if they're not exposed
> through user-facing API, they are still exposed by virtue of secondary
> processes basically having an ABI contract with primary process instances.
>
> So, if we are to cement our core API - we have to make a concrete effort
> to specify what goes and what stays, if we want it to be maintainable.
> The DPDK 1.0 specification, if you will :)
"DPDK 1.0 specification", that's a great project name :-)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
@ 2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:48 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: techboard, Ray Kinsella, Bruce Richardson, dev, Kevin Traynor
04/04/2019 16:07, Burakov, Anatoly:
> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > On 04/04/2019 11:54, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >> Actually, I think we *do* need to constrain the pace of development for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project - it
> >> should just start acting like it.
> >
> > I 100% agree.
> >
> > If you break your users stuff regularly enough, they will eventually
> > start looking around for an alternative that doesn't break their stuff
> > quiet so regularly.
> >
> > We often use the pace of innovation in DPDK as justification for ABI/API
> > breakages, but that approach is a real rarity among the Open Source
> > community. I can't think of any mature project off-hand that share's it.
> >
> > I would ask is Linux any less innovative because they offer a stable API
> > and have an absolute commitment to never breaking userspace? Would Linux
> > have ever been as popular as it is today it they broke userspace every
> > quarter?
> >
> > They reality is that they (Linux) find workarounds and compromise
> > because there is an uber-maintainer Linus who had a strong ethos from
> > the start not to break their users stuff - we need the same ethos in DPDK.
> >
> >>
> >> Now, in terms of features like the memory rework, that is indeed a case
> >> that there was no alternative other than a massive ABI break. However, for
> >> that rework there was a strong need for improvement in that area that we
> >> can make the case for an ABI break to support it - and it is of a scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are of
> >> that scale.
> >
> > I would also be inclined to agree with Bruce's points on memory rework
> > was somewhat of an outlier, we don't see many like it.
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should reduce
> >> the scope for ABI breaks.
> >> 2. Once done, I think we should commit to having an ABI break only in the
> >> rarest of circumstances, and only with very large justification. I want us
> >> to get to the point where DPDK releases can immediately be picked up by all
> >> linux distros and rolled out because they are ABI compatible.
> >
> > The work that Anatoly describes removing APIs that exposed internal
> > structures and Stephen H's RFC similarly are good examples of the kind
> > of work required to prepare for this change. We need to take a good look
> > at the API and reduce the number of unnecessary internal structures
> > exposed.
> >
> > I never expected it going to to be a big bang - but is a definite
> > direction we need to move towards over the next few release.
>
> ...in this case, we have to think long and hard about the fabled EAL
> rework/split, and in general *specifying* what is it that we want to
> support, and the use cases that we want to target. Right now there is a
> huge mountain of technical debt and kludges and workarounds that has
> accumulated over the years, and it exists precisely because "every
> change breaks someone's workflow".
>
> For example, just in memory subsystem alone, we have legacy mem, because
> some use cases require huge amounts of contiguous memory, and not
> everyone is using VFIO; there's all of the 32-bit related workarounds
> and hacks; there's the single-file-segments stuff that could have been
> the default if not for the fact that we support kernels that don't
> support fallocate(); there are two different ways of doing in-memory
> mode, because not all kernels support memfd's; there is a gargantuan
> pile of workarounds (and "known issues", and just code in general) all
> over the DPDK codebase just to support our multiprocess model and all of
> the various warts that come with it.
>
> In fact, i would even go as far as to say that *most* of EAL ABI breaks
> have been due to the fact that we store data in shared memory because of
> multiprocess - so there is simply no way we can change these internal
> data structures without ABI breaks, because even if they're not exposed
> through user-facing API, they are still exposed by virtue of secondary
> processes basically having an ABI contract with primary process instances.
>
> So, if we are to cement our core API - we have to make a concrete effort
> to specify what goes and what stays, if we want it to be maintainable.
> The DPDK 1.0 specification, if you will :)
"DPDK 1.0 specification", that's a great project name :-)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:37 4% ` Thomas Monjalon
@ 2019-04-07 9:37 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:37 UTC (permalink / raw)
To: techboard
Cc: Ray Kinsella, Bruce Richardson, Luca Boccassi, Burakov, Anatoly,
dev, Kevin Traynor
05/04/2019 15:25, Ray Kinsella:
> On 04/04/2019 14:10, Bruce Richardson wrote:
> > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> >> On 04/04/2019 13:02, Luca Boccassi wrote:
> >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >>
> > I would be too, with certain exceptions - rte_mbuf for one. Any structures
> > that are used by applications cannot be made opaque, as apps do not want to
> > pay the cost of having to call a function every time they want to access
> > something from one of those structures.
>
> These the layout of these structures really must become sacrosanct.
> As Stephen points out, there may be room for a one more change - fool me
> once - to future poof the structure but after, that these structure will
> become very hard to change.
Yes, looks like a good plan.
> > Thankfully for us, we have plenty of other structures that we can work on
> > in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> > we work through those first, allowing us to hone our ABI-break avoidance
> > skills.
+1 to work on obvious cases first.
I think we should not wait too much to improve mbuf
with some dynamically registered fields, because it may be
long to achieve such an important feature and make everybody happy.
Note: we may have to sacrifice a few cycles for some features
like distributor or IPsec.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
@ 2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:37 UTC (permalink / raw)
To: techboard
Cc: Ray Kinsella, Bruce Richardson, Luca Boccassi, Burakov, Anatoly,
dev, Kevin Traynor
05/04/2019 15:25, Ray Kinsella:
> On 04/04/2019 14:10, Bruce Richardson wrote:
> > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> >> On 04/04/2019 13:02, Luca Boccassi wrote:
> >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >>
> > I would be too, with certain exceptions - rte_mbuf for one. Any structures
> > that are used by applications cannot be made opaque, as apps do not want to
> > pay the cost of having to call a function every time they want to access
> > something from one of those structures.
>
> These the layout of these structures really must become sacrosanct.
> As Stephen points out, there may be room for a one more change - fool me
> once - to future poof the structure but after, that these structure will
> become very hard to change.
Yes, looks like a good plan.
> > Thankfully for us, we have plenty of other structures that we can work on
> > in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> > we work through those first, allowing us to hone our ABI-break avoidance
> > skills.
+1 to work on obvious cases first.
I think we should not wait too much to improve mbuf
with some dynamically registered fields, because it may be
long to achieve such an important feature and make everybody happy.
Note: we may have to sacrifice a few cycles for some features
like distributor or IPsec.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
2019-04-05 20:30 3% [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
@ 2019-04-05 20:30 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-05 20:30 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The symbols in the EXPERIMENTAL were close to alphabetic
order but running sort showed several mistakes.
This has no impact on code, API, ABI or otherwise.
Purely for humans.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/rte_eal_version.map | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..33f2c303a361 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -277,6 +277,14 @@ EXPERIMENTAL {
rte_class_unregister;
rte_ctrl_thread_create;
rte_delay_us_sleep;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dev_dma_map;
rte_dev_dma_unmap;
rte_dev_event_callback_process;
@@ -289,14 +297,6 @@ EXPERIMENTAL {
rte_dev_is_probed;
rte_dev_iterator_init;
rte_dev_iterator_next;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
rte_eal_cleanup;
rte_extmem_attach;
rte_extmem_detach;
@@ -306,19 +306,19 @@ EXPERIMENTAL {
rte_fbarray_destroy;
rte_fbarray_detach;
rte_fbarray_dump_metadata;
- rte_fbarray_find_idx;
rte_fbarray_find_biggest_free;
rte_fbarray_find_biggest_used;
+ rte_fbarray_find_contig_free;
+ rte_fbarray_find_contig_used;
+ rte_fbarray_find_idx;
rte_fbarray_find_next_free;
- rte_fbarray_find_next_used;
rte_fbarray_find_next_n_free;
rte_fbarray_find_next_n_used;
+ rte_fbarray_find_next_used;
rte_fbarray_find_prev_free;
- rte_fbarray_find_prev_used;
rte_fbarray_find_prev_n_free;
rte_fbarray_find_prev_n_used;
- rte_fbarray_find_contig_free;
- rte_fbarray_find_contig_used;
+ rte_fbarray_find_prev_used;
rte_fbarray_find_rev_biggest_free;
rte_fbarray_find_rev_biggest_used;
rte_fbarray_find_rev_contig_free;
@@ -346,24 +346,24 @@ EXPERIMENTAL {
rte_mem_event_callback_register;
rte_mem_event_callback_unregister;
rte_mem_iova2virt;
- rte_mem_set_dma_mask;
- rte_mem_virt2memseg;
- rte_mem_virt2memseg_list;
rte_memseg_contig_walk;
rte_memseg_contig_walk_thread_unsafe;
rte_memseg_get_fd;
rte_memseg_get_fd_offset;
- rte_memseg_get_fd_thread_unsafe;
rte_memseg_get_fd_offset_thread_unsafe;
+ rte_memseg_get_fd_thread_unsafe;
rte_memseg_list_walk;
rte_memseg_list_walk_thread_unsafe;
rte_memseg_walk;
rte_memseg_walk_thread_unsafe;
+ rte_mem_set_dma_mask;
+ rte_mem_virt2memseg;
+ rte_mem_virt2memseg_list;
rte_mp_action_register;
rte_mp_action_unregister;
rte_mp_reply;
- rte_mp_request_sync;
rte_mp_request_async;
+ rte_mp_request_sync;
rte_mp_sendmsg;
rte_option_register;
rte_realloc_socket;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
@ 2019-04-05 20:30 3% Stephen Hemminger
2019-04-05 20:30 3% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-05 20:30 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The symbols in the EXPERIMENTAL were close to alphabetic
order but running sort showed several mistakes.
This has no impact on code, API, ABI or otherwise.
Purely for humans.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/rte_eal_version.map | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..33f2c303a361 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -277,6 +277,14 @@ EXPERIMENTAL {
rte_class_unregister;
rte_ctrl_thread_create;
rte_delay_us_sleep;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dev_dma_map;
rte_dev_dma_unmap;
rte_dev_event_callback_process;
@@ -289,14 +297,6 @@ EXPERIMENTAL {
rte_dev_is_probed;
rte_dev_iterator_init;
rte_dev_iterator_next;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
rte_eal_cleanup;
rte_extmem_attach;
rte_extmem_detach;
@@ -306,19 +306,19 @@ EXPERIMENTAL {
rte_fbarray_destroy;
rte_fbarray_detach;
rte_fbarray_dump_metadata;
- rte_fbarray_find_idx;
rte_fbarray_find_biggest_free;
rte_fbarray_find_biggest_used;
+ rte_fbarray_find_contig_free;
+ rte_fbarray_find_contig_used;
+ rte_fbarray_find_idx;
rte_fbarray_find_next_free;
- rte_fbarray_find_next_used;
rte_fbarray_find_next_n_free;
rte_fbarray_find_next_n_used;
+ rte_fbarray_find_next_used;
rte_fbarray_find_prev_free;
- rte_fbarray_find_prev_used;
rte_fbarray_find_prev_n_free;
rte_fbarray_find_prev_n_used;
- rte_fbarray_find_contig_free;
- rte_fbarray_find_contig_used;
+ rte_fbarray_find_prev_used;
rte_fbarray_find_rev_biggest_free;
rte_fbarray_find_rev_biggest_used;
rte_fbarray_find_rev_contig_free;
@@ -346,24 +346,24 @@ EXPERIMENTAL {
rte_mem_event_callback_register;
rte_mem_event_callback_unregister;
rte_mem_iova2virt;
- rte_mem_set_dma_mask;
- rte_mem_virt2memseg;
- rte_mem_virt2memseg_list;
rte_memseg_contig_walk;
rte_memseg_contig_walk_thread_unsafe;
rte_memseg_get_fd;
rte_memseg_get_fd_offset;
- rte_memseg_get_fd_thread_unsafe;
rte_memseg_get_fd_offset_thread_unsafe;
+ rte_memseg_get_fd_thread_unsafe;
rte_memseg_list_walk;
rte_memseg_list_walk_thread_unsafe;
rte_memseg_walk;
rte_memseg_walk_thread_unsafe;
+ rte_mem_set_dma_mask;
+ rte_mem_virt2memseg;
+ rte_mem_virt2memseg_list;
rte_mp_action_register;
rte_mp_action_unregister;
rte_mp_reply;
- rte_mp_request_sync;
rte_mp_request_async;
+ rte_mp_request_sync;
rte_mp_sendmsg;
rte_option_register;
rte_realloc_socket;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] power: fix non thread-safe power env modification
2019-04-05 14:35 4% ` [dpdk-dev] [PATCH] " Hajkowski
@ 2019-04-05 14:35 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-04-05 14:35 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable, Anatoly Burakov
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] power: fix non thread-safe power env modification
@ 2019-04-05 14:35 4% ` Hajkowski
2019-04-05 14:35 4% ` Hajkowski
0 siblings, 1 reply; 200+ results
From: Hajkowski @ 2019-04-05 14:35 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable, Anatoly Burakov
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:30 4% ` Ray Kinsella
@ 2019-04-05 13:30 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:30 UTC (permalink / raw)
To: Kevin Traynor, Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 21:13, Kevin Traynor wrote:
> On 04/04/2019 20:08, Wiles, Keith wrote:
>>
>>
>>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>>
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>> <snip>
>>>
>>>>
>>>> My thoughts on the matter are:
>>>> 1. I think we really need to do work to start hiding more of our data
>>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>>> the scope for ABI breaks.
>>>> 2. Once done, I think we should commit to having an ABI break only in the
>>>> rarest of circumstances, and only with very large justification. I want us
>>>> to get to the point where DPDK releases can immediately be picked up by all
>>>> linux distros and rolled out because they are ABI compatible.
>>>>
>>>
>>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>>> APIs at transition from experimental to core). Just as a way to get more
>>> eyeballs and scrutiny on them.
>>
>> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>>
>
> We'll only find out if they are bad when they need ABI breaks later :-)
>
> My point is a good way to avoid future ABI breaks is to have more
> reviews on the APIs in the first place. Techboard approval might be one
> way, or 3 acks or something else.
+1 on this ... an API break should invite a higher level of scrutiny.
>
>>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>>> me as a plan where we end up with the same number of ABI breaks as before,
>>>> just balled into one release.
>>>>
>>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>>> case that each distro will only ship one version of DPDK, or is it possible
>>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>>
>>>
>>> It would probably double validation and maintenance, so it would require
>>> a lot of extra effort.
>>>
>>>>
>>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>>> similar.
>>>>
>>>> Regards,
>>>> /Bruce
>>>>
>>>
>>
>> Regards,
>> Keith
>>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
@ 2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:30 4% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-05 13:30 UTC (permalink / raw)
To: Kevin Traynor, Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 21:13, Kevin Traynor wrote:
> On 04/04/2019 20:08, Wiles, Keith wrote:
>>
>>
>>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>>
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>> <snip>
>>>
>>>>
>>>> My thoughts on the matter are:
>>>> 1. I think we really need to do work to start hiding more of our data
>>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>>> the scope for ABI breaks.
>>>> 2. Once done, I think we should commit to having an ABI break only in the
>>>> rarest of circumstances, and only with very large justification. I want us
>>>> to get to the point where DPDK releases can immediately be picked up by all
>>>> linux distros and rolled out because they are ABI compatible.
>>>>
>>>
>>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>>> APIs at transition from experimental to core). Just as a way to get more
>>> eyeballs and scrutiny on them.
>>
>> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>>
>
> We'll only find out if they are bad when they need ABI breaks later :-)
>
> My point is a good way to avoid future ABI breaks is to have more
> reviews on the APIs in the first place. Techboard approval might be one
> way, or 3 acks or something else.
+1 on this ... an API break should invite a higher level of scrutiny.
>
>>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>>> me as a plan where we end up with the same number of ABI breaks as before,
>>>> just balled into one release.
>>>>
>>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>>> case that each distro will only ship one version of DPDK, or is it possible
>>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>>
>>>
>>> It would probably double validation and maintenance, so it would require
>>> a lot of extra effort.
>>>
>>>>
>>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>>> similar.
>>>>
>>>> Regards,
>>>> /Bruce
>>>>
>>>
>>
>> Regards,
>> Keith
>>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:29 4% ` Ray Kinsella
@ 2019-04-05 13:29 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:29 UTC (permalink / raw)
To: Wiles, Keith, Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
@ 2019-04-05 13:29 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-05 13:29 UTC (permalink / raw)
To: Wiles, Keith, Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:25 4% ` Ray Kinsella
@ 2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:25 UTC (permalink / raw)
To: Bruce Richardson
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On 04/04/2019 14:10, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>>
>>
>> On 04/04/2019 13:02, Luca Boccassi wrote:
>>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>
> I would be too, with certain exceptions - rte_mbuf for one. Any structures
> that are used by applications cannot be made opaque, as apps do not want to
> pay the cost of having to call a function every time they want to access
> something from one of those structures.
These the layout of these structures really must become sacrosanct.
As Stephen points out, there may be room for a one more change - fool me
once - to future poof the structure but after, that these structure will
become very hard to change.
>
> Thankfully for us, we have plenty of other structures that we can work on
> in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> we work through those first, allowing us to hone our ABI-break avoidance
> skills.
>
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
@ 2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:25 UTC (permalink / raw)
To: Bruce Richardson
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On 04/04/2019 14:10, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>>
>>
>> On 04/04/2019 13:02, Luca Boccassi wrote:
>>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>
> I would be too, with certain exceptions - rte_mbuf for one. Any structures
> that are used by applications cannot be made opaque, as apps do not want to
> pay the cost of having to call a function every time they want to access
> something from one of those structures.
These the layout of these structures really must become sacrosanct.
As Stephen points out, there may be room for a one more change - fool me
once - to future poof the structure but after, that these structure will
become very hard to change.
>
> Thankfully for us, we have plenty of other structures that we can work on
> in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> we work through those first, allowing us to hone our ABI-break avoidance
> skills.
>
> /Bruce
>
^ permalink raw reply [relevance 4%]
Results 8401-8600 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2018-10-24 8:18 [dpdk-dev] [RFC 00/14] prefix network structures Olivier Matz
2019-04-10 8:32 1% ` [dpdk-dev] [RFC v2 " Olivier Matz
2019-04-10 8:32 1% ` Olivier Matz
2018-11-22 3:30 [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library Honnappa Nagarahalli
2019-04-12 20:20 ` [dpdk-dev] [PATCH v5 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-04-12 20:20 ` [dpdk-dev] [PATCH v5 1/3] rcu: " Honnappa Nagarahalli
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:18 0% ` Thomas Monjalon
2019-04-17 14:18 0% ` Thomas Monjalon
2019-03-04 11:18 [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes David Marchand
2019-03-11 17:22 ` Ferruh Yigit
2019-04-12 15:07 ` Thomas Monjalon
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:57 0% ` Ferruh Yigit
2019-04-12 15:57 0% ` Ferruh Yigit
2019-03-06 17:20 [dpdk-dev] [PATCH v4 0/2] Timer library changes Erik Gabriel Carrillo
2019-04-15 21:41 5% ` [dpdk-dev] [PATCH v5 " Erik Gabriel Carrillo
2019-04-15 21:41 5% ` Erik Gabriel Carrillo
2019-03-14 15:12 [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes David Marchand
2019-03-19 17:18 ` [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API Ferruh Yigit
2019-03-26 9:29 ` David Marchand
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
2019-04-12 16:05 0% ` Stephen Hemminger
2019-03-18 11:56 [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification Hajkowski
2019-04-05 14:35 4% ` [dpdk-dev] [PATCH] " Hajkowski
2019-04-05 14:35 4% ` Hajkowski
2019-04-03 15:42 [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
2019-04-04 9:29 ` Burakov, Anatoly
2019-04-04 10:54 ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 12:02 ` Luca Boccassi
2019-04-04 13:05 ` Ray Kinsella
2019-04-04 13:10 ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-04 16:56 ` Kevin Traynor
2019-04-04 19:08 ` Wiles, Keith
2019-04-04 20:13 ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2019-04-04 12:52 ` Ray Kinsella
2019-04-04 14:07 ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-09 9:42 4% ` Ray Kinsella
2019-04-09 9:42 4% ` Ray Kinsella
2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
2019-04-15 9:10 4% ` Bruce Richardson
2019-04-10 5:14 9% ` [dpdk-dev] " Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10 9:03 8% ` Bruce Richardson
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
2019-04-10 9:43 4% ` Luca Boccassi
2019-04-05 8:17 [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
2019-04-05 11:22 ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-05 20:30 3% [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
2019-04-05 20:30 3% ` Stephen Hemminger
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-10 17:16 9% ` Stephen Hemminger
2019-04-09 17:36 4% [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission Rami Rosen
2019-04-09 17:36 4% ` Rami Rosen
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 11:18 [dpdk-dev] [PATCH 00/10] add MACSEC hw offload to atlantic PMD Igor Russkikh
2019-04-10 11:18 ` [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops Igor Russkikh
2019-04-12 18:26 ` Ferruh Yigit
2019-04-13 7:24 ` Igor Russkikh
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
2019-04-16 10:19 0% ` Igor Russkikh
2019-04-10 11:26 [dpdk-dev] [PATCH v3 0/3] add actions to modify header fields Dekel Peled
2019-04-10 11:50 ` [dpdk-dev] [PATCH v4 " Dekel Peled
2019-04-10 11:50 ` [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP " Dekel Peled
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-22 7:15 0% ` Dekel Peled
2019-04-22 7:15 0% ` Dekel Peled
2019-04-11 10:41 1% [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums Bruce Richardson
2019-04-11 10:41 1% ` Bruce Richardson
2019-04-12 10:13 4% [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission Rami Rosen
2019-04-12 10:13 4% ` Rami Rosen
2019-04-12 10:26 4% [dpdk-dev] [PATCH V3] " Rami Rosen
2019-04-12 10:26 4% ` Rami Rosen
2019-04-17 5:12 9% [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
2019-04-23 14:19 4% ` Ray Kinsella
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 8:49 4% ` Bruce Richardson
2019-04-24 8:49 4% ` Bruce Richardson
2019-04-18 10:58 3% [dpdk-dev] DPDK Release Status Meeting 18/4/2019 Ferruh Yigit
2019-04-18 10:58 3% ` Ferruh Yigit
2019-04-18 20:41 5% [dpdk-dev] DPDK techboard minutes (2019-04-10) Olivier Matz
2019-04-18 20:41 5% ` Olivier Matz
2019-04-19 21:21 [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR Mattias Rönnblom
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-24 11:37 0% ` Neil Horman
2019-04-24 11:37 0% ` Neil Horman
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
2019-04-23 23:16 3% [dpdk-dev] DPDK Windows Community call - 18 April 2019 Ranjit Menon
2019-04-23 23:16 3% ` Ranjit Menon
2019-04-24 8:18 20% [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh Peng Huang
2019-04-24 8:18 20% ` Peng Huang
2019-04-24 8:56 4% ` Bruce Richardson
2019-04-24 8:56 4% ` Bruce Richardson
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).