* [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
Even if rare, the check script should handle removing a section.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 8da7650..d5fad04 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -32,6 +32,7 @@ build_map_changes()
# symbol rule below
/^.*{/ {
gsub("+", "");
+ gsub("-", "");
if (in_map == 1) {
sec=$(NF-1); in_sec=1;
}
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
We have an incorrect variable name in this log.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index d5fad04..9ada81e 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -98,7 +98,7 @@ check_for_rule_violations()
then
# Just inform the user of this occurrence, but
# don't flag it as an error
- echo -n "INFO: symbol $syname is added but "
+ echo -n "INFO: symbol $symname is added but "
echo -n "patch has insuficient context "
echo -n "to determine the section name "
echo -n "please ensure the version is "
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
Even if rare, the check script should handle removing a section.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 8da7650..d5fad04 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -32,6 +32,7 @@ build_map_changes()
# symbol rule below
/^.*{/ {
gsub("+", "");
+ gsub("-", "");
if (in_map == 1) {
sec=$(NF-1); in_sec=1;
}
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
2 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
The incriminated commit broke the detection of new symbols skipping the
EXPERIMENTAL step before entering a stable abi section.
sed won't return an error, check a null output instead.
Fixes: 3630757803ab ("devtools: accept experimental symbol promotion")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 9ada81e..116c311 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -111,15 +111,24 @@ check_for_rule_violations()
# A symbol can not enter a non experimental
# section directly
- if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
+ if [ -z "$oldsecname" ]
then
- echo -n "ERROR: symbol $symname "
- echo -n "is added in the $secname "
- echo -n "section, but is expected to "
- echo -n "be added in the EXPERIMENTAL "
- echo "section of the version map"
- ret=1
- continue
+ if [ "$secname" = 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname has "
+ echo -n "been added to the "
+ echo -n "EXPERIMENTAL section of the "
+ echo "version map"
+ continue
+ else
+ echo -n "ERROR: symbol $symname "
+ echo -n "is added in the $secname "
+ echo -n "section, but is expected to "
+ echo -n "be added in the EXPERIMENTAL "
+ echo "section of the version map"
+ ret=1
+ continue
+ fi
fi
# This symbol is moving inside a section, nothing to do
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
We have an incorrect variable name in this log.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index d5fad04..9ada81e 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -98,7 +98,7 @@ check_for_rule_violations()
then
# Just inform the user of this occurrence, but
# don't flag it as an error
- echo -n "INFO: symbol $syname is added but "
+ echo -n "INFO: symbol $symname is added but "
echo -n "patch has insuficient context "
echo -n "to determine the section name "
echo -n "please ensure the version is "
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-03 7:56 0% ` Burakov, Anatoly
@ 2019-05-03 7:56 0% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-03 7:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On 02-May-19 7:54 PM, Stephen Hemminger wrote:
> On Thu, 2 May 2019 16:53:50 +0100
> "Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
>
>> On 02-May-19 3:13 PM, Reshma Pattan wrote:
>>> gcc 9 on Fedora 30 gives an error
>>> "taking address of packed member may result in an
>>> unaligned pointer value" for -Waddress-of-packed-member.
>>>
>>> Report it as warning instead of error to fix the build.
>>>
>>> Snippet of build before fix
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>> 768 | cur_msl = &mcfg->memsegs[msl_idx];
>>> | ^~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Snippet of build after fix
>>> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
>>> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Waddress-of-packed-member]
>>> 685 | msl = &mcfg->memsegs[msl_idx];
>>>
>>
>> Fixing these would require an ABI break, because these are exposed
>> externally. Should we submit a deprecation notice for EAL?
>
>
> Ideally mem config and related structures would not be exposed in the
> API. Like lcore_config and eal_config it should be eal_private
>
In a perfect world, that would've been the case. However, these are in
shared memory structures that are used for multiprocess synchronization.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-02 18:54 0% ` Stephen Hemminger
@ 2019-05-03 7:56 0% ` Burakov, Anatoly
2019-05-03 7:56 0% ` Burakov, Anatoly
1 sibling, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-05-03 7:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On 02-May-19 7:54 PM, Stephen Hemminger wrote:
> On Thu, 2 May 2019 16:53:50 +0100
> "Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
>
>> On 02-May-19 3:13 PM, Reshma Pattan wrote:
>>> gcc 9 on Fedora 30 gives an error
>>> "taking address of packed member may result in an
>>> unaligned pointer value" for -Waddress-of-packed-member.
>>>
>>> Report it as warning instead of error to fix the build.
>>>
>>> Snippet of build before fix
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>> 768 | cur_msl = &mcfg->memsegs[msl_idx];
>>> | ^~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Snippet of build after fix
>>> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
>>> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Waddress-of-packed-member]
>>> 685 | msl = &mcfg->memsegs[msl_idx];
>>>
>>
>> Fixing these would require an ABI break, because these are exposed
>> externally. Should we submit a deprecation notice for EAL?
>
>
> Ideally mem config and related structures would not be exposed in the
> API. Like lcore_config and eal_config it should be eal_private
>
In a perfect world, that would've been the case. However, these are in
shared memory structures that are used for multiprocess synchronization.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-05-03 7:22 0% ` David Marchand
@ 2019-05-03 7:22 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 7:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Apr 10, 2019 at 7:16 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> 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);
>
This is new from v2.
Please remove this __rte_experimental tag.
> /**
> * 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;
> +
>
19.05 inherits from 18.11 not 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
>
And with these two changes, renewing my tag.
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [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
@ 2019-05-03 7:22 0% ` David Marchand
2019-05-03 7:22 0% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-05-03 7:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Apr 10, 2019 at 7:16 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> 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);
>
This is new from v2.
Please remove this __rte_experimental tag.
> /**
> * 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;
> +
>
19.05 inherits from 18.11 not 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
>
And with these two changes, renewing my tag.
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
@ 2019-05-02 23:15 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-02 23:15 UTC (permalink / raw)
To: dev
On Wed, 10 Apr 2019 10:15:58 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> 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(-)
>
Why is this patchset still stuck in the queue?
The parts with deprecation and accessor functions should really go in 19.05
but since it has sat around for so long, it is probably too late.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 " 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-05-02 23:15 0% ` Stephen Hemminger
2019-05-02 23:15 0% ` Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-05-02 23:15 UTC (permalink / raw)
To: dev
On Wed, 10 Apr 2019 10:15:58 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> 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(-)
>
Why is this patchset still stuck in the queue?
The parts with deprecation and accessor functions should really go in 19.05
but since it has sat around for so long, it is probably too late.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 18:54 0% ` Stephen Hemminger
@ 2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-03 7:56 0% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-02 18:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On Thu, 2 May 2019 16:53:50 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 02-May-19 3:13 PM, Reshma Pattan wrote:
> > gcc 9 on Fedora 30 gives an error
> > "taking address of packed member may result in an
> > unaligned pointer value" for -Waddress-of-packed-member.
> >
> > Report it as warning instead of error to fix the build.
> >
> > Snippet of build before fix
> > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Werror=address-of-packed-member]
> > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Snippet of build after fix
> > ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> > ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Waddress-of-packed-member]
> > 685 | msl = &mcfg->memsegs[msl_idx];
> >
>
> Fixing these would require an ABI break, because these are exposed
> externally. Should we submit a deprecation notice for EAL?
Ideally mem config and related structures would not be exposed in the
API. Like lcore_config and eal_config it should be eal_private
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 15:53 3% ` Burakov, Anatoly
@ 2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-03 7:56 0% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-05-02 18:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On Thu, 2 May 2019 16:53:50 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 02-May-19 3:13 PM, Reshma Pattan wrote:
> > gcc 9 on Fedora 30 gives an error
> > "taking address of packed member may result in an
> > unaligned pointer value" for -Waddress-of-packed-member.
> >
> > Report it as warning instead of error to fix the build.
> >
> > Snippet of build before fix
> > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Werror=address-of-packed-member]
> > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Snippet of build after fix
> > ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> > ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Waddress-of-packed-member]
> > 685 | msl = &mcfg->memsegs[msl_idx];
> >
>
> Fixing these would require an ABI break, because these are exposed
> externally. Should we submit a deprecation notice for EAL?
Ideally mem config and related structures would not be exposed in the
API. Like lcore_config and eal_config it should be eal_private
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 15:53 3% ` Burakov, Anatoly
@ 2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 18:54 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-02 15:53 UTC (permalink / raw)
To: Reshma Pattan, dev; +Cc: david.marchand, bruce.richardson
On 02-May-19 3:13 PM, Reshma Pattan wrote:
> gcc 9 on Fedora 30 gives an error
> "taking address of packed member may result in an
> unaligned pointer value" for -Waddress-of-packed-member.
>
> Report it as warning instead of error to fix the build.
>
> Snippet of build before fix
> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Werror=address-of-packed-member]
> 768 | cur_msl = &mcfg->memsegs[msl_idx];
> | ^~~~~~~~~~~~~~~~~~~~~~~
>
> Snippet of build after fix
> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Waddress-of-packed-member]
> 685 | msl = &mcfg->memsegs[msl_idx];
>
Fixing these would require an ABI break, because these are exposed
externally. Should we submit a deprecation notice for EAL?
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
@ 2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 18:54 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-02 15:53 UTC (permalink / raw)
To: Reshma Pattan, dev; +Cc: david.marchand, bruce.richardson
On 02-May-19 3:13 PM, Reshma Pattan wrote:
> gcc 9 on Fedora 30 gives an error
> "taking address of packed member may result in an
> unaligned pointer value" for -Waddress-of-packed-member.
>
> Report it as warning instead of error to fix the build.
>
> Snippet of build before fix
> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Werror=address-of-packed-member]
> 768 | cur_msl = &mcfg->memsegs[msl_idx];
> | ^~~~~~~~~~~~~~~~~~~~~~~
>
> Snippet of build after fix
> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Waddress-of-packed-member]
> 685 | msl = &mcfg->memsegs[msl_idx];
>
Fixing these would require an ABI break, because these are exposed
externally. Should we submit a deprecation notice for EAL?
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-05-01 23:47 4% ` Thomas Monjalon
@ 2019-05-01 23:47 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-01 23:47 UTC (permalink / raw)
To: Peng Huang; +Cc: dev, Neil Horman, qi.z.zhang, qiming.yang, wenzhuo.lu, stable
24/04/2019 14:08, Neil Horman:
> 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: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks and welcome!
^ permalink raw reply [relevance 4%]
* 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
@ 2019-05-01 23:47 4% ` Thomas Monjalon
2019-05-01 23:47 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-05-01 23:47 UTC (permalink / raw)
To: Peng Huang; +Cc: dev, Neil Horman, qi.z.zhang, qiming.yang, wenzhuo.lu, stable
24/04/2019 14:08, Neil Horman:
> 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: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks and welcome!
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-30 8:52 9% ` Thomas Monjalon
@ 2019-04-30 8:52 9% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-30 8:52 UTC (permalink / raw)
To: dev
Cc: Ray Kinsella, Burakov, Anatoly, Bruce Richardson,
Honnappa Nagarahalli, Stephen Hemminger, Ananyev, Konstantin, nd
24/04/2019 14:22, Ray Kinsella:
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
> > 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.
Yes, that's why we keep the split in libraries.
So we can update LPM library version while keeping the same ethdev
version to allow applications to load the shared library of the same
name without any re-compilation. In this case, the need for
re-compilation is only for applications using LPM.
But this model is not convenient for distributions because they
manage DPDK as one package. It means they have to re-compile all
applications if one LPM ABI is broken, even if it is experimental.
Should the libraries be split in packages?
> 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.
As said above, experimental level does not solve ABI stability.
If we break an experimental API, the ABI is broken, requiring
to re-compile the application.
> I would also propose more use of ABI Versioning to enable evolution of
> DPDK while preserving backward compatibility.
Yes, if all other obvious versioning issues are solved,
we can walk the extra mile of better using ABI versioning.
> > Perhaps limiting DPDK's scope would help with this as well.
>
> I agree.
Yes, either split the project in more limited scope areas,
or split the packages.
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:54 4% ` Burakov, Anatoly
@ 2019-04-30 8:52 9% ` Thomas Monjalon
2019-04-30 8:52 9% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-30 8:52 UTC (permalink / raw)
To: dev
Cc: Ray Kinsella, Burakov, Anatoly, Bruce Richardson,
Honnappa Nagarahalli, Stephen Hemminger, Ananyev, Konstantin, nd
24/04/2019 14:22, Ray Kinsella:
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
> > 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.
Yes, that's why we keep the split in libraries.
So we can update LPM library version while keeping the same ethdev
version to allow applications to load the shared library of the same
name without any re-compilation. In this case, the need for
re-compilation is only for applications using LPM.
But this model is not convenient for distributions because they
manage DPDK as one package. It means they have to re-compile all
applications if one LPM ABI is broken, even if it is experimental.
Should the libraries be split in packages?
> 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.
As said above, experimental level does not solve ABI stability.
If we break an experimental API, the ABI is broken, requiring
to re-compile the application.
> I would also propose more use of ABI Versioning to enable evolution of
> DPDK while preserving backward compatibility.
Yes, if all other obvious versioning issues are solved,
we can walk the extra mile of better using ABI versioning.
> > Perhaps limiting DPDK's scope would help with this as well.
>
> I agree.
Yes, either split the project in more limited scope areas,
or split the packages.
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 17:19 4% ` Ferruh Yigit
@ 2019-04-29 17:19 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 17:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On 4/29/2019 5:24 PM, Stephen Hemminger wrote:
> On Mon, 29 Apr 2019 10:28:36 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
>>>
>>>
>>>> +* kni: Modify function return value for the sake of removing rte_panic
>>>> + from the init sequence in version 19.08.
>>>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>>>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>>>> + to return ``int``
>>>
>>> This is not a public API really so no deprecation needed.
>>> It is just an include file used internally by library and the driver.
>>>
>
> This does introduce the possibility of kernel/library version mismatch.
> You might want to add a magic number to shared data structure.
>
Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
perhaps it would be a problem if the content of the fifo changed but it is not
the case.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 16:24 4% ` Stephen Hemminger
@ 2019-04-29 17:19 4% ` Ferruh Yigit
2019-04-29 17:19 4% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-29 17:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On 4/29/2019 5:24 PM, Stephen Hemminger wrote:
> On Mon, 29 Apr 2019 10:28:36 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
>>>
>>>
>>>> +* kni: Modify function return value for the sake of removing rte_panic
>>>> + from the init sequence in version 19.08.
>>>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>>>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>>>> + to return ``int``
>>>
>>> This is not a public API really so no deprecation needed.
>>> It is just an include file used internally by library and the driver.
>>>
>
> This does introduce the possibility of kernel/library version mismatch.
> You might want to add a magic number to shared data structure.
>
Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
perhaps it would be a problem if the content of the fifo changed but it is not
the case.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 16:24 4% ` Stephen Hemminger
@ 2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 17:19 4% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-29 16:24 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Mon, 29 Apr 2019 10:28:36 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> >
> >> +* kni: Modify function return value for the sake of removing rte_panic
> >> + from the init sequence in version 19.08.
> >> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> >> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> >> + to return ``int``
> >
> > This is not a public API really so no deprecation needed.
> > It is just an include file used internally by library and the driver.
> >
This does introduce the possibility of kernel/library version mismatch.
You might want to add a magic number to shared data structure.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 9:28 4% ` Ferruh Yigit
@ 2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 17:19 4% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-29 16:24 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Mon, 29 Apr 2019 10:28:36 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> >
> >> +* kni: Modify function return value for the sake of removing rte_panic
> >> + from the init sequence in version 19.08.
> >> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> >> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> >> + to return ``int``
> >
> > This is not a public API really so no deprecation needed.
> > It is just an include file used internally by library and the driver.
> >
This does introduce the possibility of kernel/library version mismatch.
You might want to add a magic number to shared data structure.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 9:28 4% ` Ferruh Yigit
@ 2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 16:24 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 9:28 UTC (permalink / raw)
To: Stephen Hemminger, Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ranjit.menon, anand.rawat,
pallavi.kadam, harini.ramakrishnan, cathal.ohare, arnonw
On 4/28/2019 5:23 PM, Stephen Hemminger wrote:
> On Sun, 28 Apr 2019 17:58:48 +0300
> Arnon Warshavsky <arnon@qwilt.com> wrote:
>
> These deprecation notices are unnecessary. These are not public API's.
+1
>
>> +* eal: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_eal/common/eal_thread.h`` replace
>> + ``void eal_thread_init_master(unsigned lcore_id)``
>> + to return ``int``
>
> This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
>
>
>> +* kni: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>> + to return ``int``
>
> This is not a public API really so no deprecation needed.
> It is just an include file used internally by library and the driver.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-28 16:23 4% ` Stephen Hemminger
@ 2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 16:24 4% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 9:28 UTC (permalink / raw)
To: Stephen Hemminger, Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ranjit.menon, anand.rawat,
pallavi.kadam, harini.ramakrishnan, cathal.ohare, arnonw
On 4/28/2019 5:23 PM, Stephen Hemminger wrote:
> On Sun, 28 Apr 2019 17:58:48 +0300
> Arnon Warshavsky <arnon@qwilt.com> wrote:
>
> These deprecation notices are unnecessary. These are not public API's.
+1
>
>> +* eal: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_eal/common/eal_thread.h`` replace
>> + ``void eal_thread_init_master(unsigned lcore_id)``
>> + to return ``int``
>
> This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
>
>
>> +* kni: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>> + to return ``int``
>
> This is not a public API really so no deprecation needed.
> It is just an include file used internally by library and the driver.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
2019-04-29 4:07 0% ` lin li
@ 2019-04-29 4:07 0% ` lin li
0 siblings, 0 replies; 200+ results
From: lin li @ 2019-04-29 4:07 UTC (permalink / raw)
To: Tiwei Bie
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
Tiwei Bie <tiwei.bie@intel.com> 于2019年4月28日周日 下午7:18写道：
>
> On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> > From: lilin24 <lilin24@baidu.com>
> >
> > This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> > and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> > buffer between qemu and backend.
> >
> > Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> > shared buffer from backend. Then qemu should send it back
> > through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
> >
> > This shared buffer is used to process inflight I/O when backend
> > reconnect.
> >
> > Signed-off-by: lilin24 <lilin24@baidu.com>
>
> You need to use your real name here.
>
> > Signed-off-by: Ni Xun <nixun@baidu.com>
> > Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> >
> > v2:
> > - add set&clr inflight entry function
> > v3:
> > - simplified some function implementations
> >
> > ---
>
> You can put change logs here (i.e. after ---).
>
> > lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> > lib/librte_vhost/vhost.c | 42 ++++++++
> > lib/librte_vhost/vhost.h | 11 ++
> > lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user.h | 16 ++-
> > 5 files changed, 351 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> > index d2c0c93f4..bc25591a8 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -71,6 +71,10 @@ extern "C" {
> > #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> > #endif
> >
> > +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> > +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> > +#endif
> > +
> > /** Indicate whether protocol features negotiation is supported. */
> > #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> > #define VHOST_USER_F_PROTOCOL_FEATURES 30
> > @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> > struct rte_vhost_mem_region regions[];
> > };
> >
> > +typedef struct VhostUserInflightEntry {
> > + uint8_t inflight;
> > +} VhostUserInflightEntry;
> > +
> > +typedef struct VhostInflightInfo {
> > + uint16_t version;
> > + uint16_t last_inflight_io;
> > + uint16_t used_idx;
> > + VhostUserInflightEntry desc[0];
> > +} VhostInflightInfo;
>
> Is there any details on above structure? Why does it not match
> QueueRegionSplit or QueueRegionPacked structures described in
> qemu/docs/interop/vhost-user.txt?
Qemu have its vhost-user backend，qemu did the submission of IO in it.
The implementation of dpdk is more general. It is just to mark inflight entry.
The submission of inflight entry is handle over to different backends.
They have their own ways to handle it, such as spdk.
So there are some differences in data structure.
>
> > +
> > struct rte_vhost_vring {
> > struct vring_desc *desc;
> > struct vring_avail *avail;
> > struct vring_used *used;
> > uint64_t log_guest_addr;
> >
> > + VhostInflightInfo *inflight;
> > + int inflight_flag;
> > +
> > /** Deprecated, use rte_vhost_vring_call() instead. */
> > int callfd;
> >
> > @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > int rte_vhost_vring_call(int vid, uint16_t vring_idx);
> >
> > /**
> > + * set inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> > + uint16_t idx);
> > +
> > +/**
> > + * clear inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param last_used_idx
> > + * next free used_idx
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx);
> > +
> > +/**
> > + * set last inflight io index.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> > + uint16_t idx);
>
> New APIs should be experimental and also need to be
> added in rte_vhost_version.map file.
>
> > +
> > +/**
> > * Get vhost RX queue avail count.
> > *
> > * @param vid
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> > index 163f4595e..9ba692935 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> > close(vq->callfd);
> > if (vq->kickfd >= 0)
> > close(vq->kickfd);
> > + if (vq->inflight)
> > + vq->inflight = NULL;
> > }
> >
> > /*
> > @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > vring->kickfd = vq->kickfd;
> > vring->size = vq->size;
> >
> > + vring->inflight = vq->inflight;
> > +
> > + vring->inflight_flag = vq->inflight_flag;
> > + vq->inflight_flag = 0;
>
> This will break the ABI. Better to introduce a new API to do this.
>
> > +
> > return 0;
> > }
> >
> > @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> > return 0;
> > }
> >
> > +void
> > +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > + if (unlikely(!inflight))
> > + return;
> > + inflight->desc[idx].inflight = 1;
> > +}
> > +
> > +void
> > +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + rte_compiler_barrier();
> > + inflight->desc[idx].inflight = 0;
> > + rte_compiler_barrier();
> > + inflight->used_idx = last_used_idx;
> > +}
> > +
> > +void
> > +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + inflight->last_inflight_io = idx;
> > +}
>
> The rte_vhost_vring is used to return information to apps.
>
> IIUC, you want to update vq->inflight. So the rte_vhost_vring
> param should be replaced by vid + vring_idx.
>
> > +
> > uint16_t
> > rte_vhost_avail_entries(int vid, uint16_t queue_id)
> > {
> > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> > index e9138dfab..537d74c71 100644
> > --- a/lib/librte_vhost/vhost.h
> > +++ b/lib/librte_vhost/vhost.h
> > @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> > /* Physical address of used ring, for logging */
> > uint64_t log_guest_addr;
> >
> > + /* Inflight share memory info */
> > + VhostInflightInfo *inflight;
> > + bool inflight_flag;
> > +
> > uint16_t nr_zmbuf;
> > uint16_t zmbuf_size;
> > uint16_t last_zmbuf_idx;
> > @@ -286,6 +290,12 @@ struct guest_page {
> > uint64_t size;
> > };
> >
> > +typedef struct VuDevInflightInfo {
> > + int fd;
> > + void *addr;
> > + uint64_t size;
> > +} VuDevInflightInfo;
>
> Please follow DPDK's coding style when defining internal structure.
>
> > +
> > /**
> > * Device structure contains all configuration information relating
> > * to the device.
> > @@ -303,6 +313,7 @@ struct virtio_net {
> > uint32_t nr_vring;
> > int dequeue_zero_copy;
> > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> > + VuDevInflightInfo inflight_info;
> > #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> > char ifname[IF_NAME_SZ];
> > uint64_t log_size;
> > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> [...]
> > +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> > +{
> > + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> > + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> > +}
> > +
> > +static int
> > +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd;
> > + uint64_t mmap_size;
> > + void *addr;
> > + uint16_t num_queues, queue_size;
> > + struct virtio_net *dev = *pdev;
> > +
> > + if (msg->size != sizeof(msg->payload.inflight)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Invalid get_inflight_fd message size is %d",
> > + msg->size);
> > + msg->payload.inflight.mmap_size = 0;
>
> In this case, you can't touch the payload.
>
> > + return 0;
>
> And an error should be returned.
>
> > + }
> > +
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> > + msg->payload.inflight.num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> > + msg->payload.inflight.queue_size);
> > + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> > +
> > + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> > + if (!addr) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> > + msg->payload.inflight.mmap_size = 0;
> > + return 0;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > + memset(addr, 0, mmap_size);
> > +
> > + dev->inflight_info.addr = addr;
> > + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> > + dev->inflight_info.fd = msg->fds[0] = fd;
> > + msg->payload.inflight.mmap_offset = 0;
> > + msg->fd_num = 1;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_size: %lu\n",
> > + msg->payload.inflight.mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_offset: %lu\n",
> > + msg->payload.inflight.mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight fd: %d\n", msg->fds[0]);
> > +
> > + return RTE_VHOST_MSG_RESULT_REPLY;
> > +}
> > +
> > +static int
> > +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd, i;
> > + uint64_t mmap_size, mmap_offset;
> > + uint16_t num_queues, queue_size;
> > + uint32_t pervq_inflight_size;
> > + void *rc;
> > + struct vhost_virtqueue *vq;
> > + struct virtio_net *dev = *pdev;
> > +
> > + fd = msg->fds[0];
> > + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> > + msg->size, fd);
> > + return -1;
>
> Ditto.
>
> > + }
> > +
> > + mmap_size = msg->payload.inflight.mmap_size;
> > + mmap_offset = msg->payload.inflight.mmap_offset;
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > + pervq_inflight_size = get_pervq_shm_size(queue_size);
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd num_queues: %u\n", num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd queue_size: %u\n", queue_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd fd: %d\n", fd);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd pervq_inflight_size: %d\n",
> > + pervq_inflight_size);
> > +
> > + if (dev->inflight_info.addr)
> > + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> > +
> > + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> > + fd, mmap_offset);
>
> Why call it rc? Maybe addr is a better name?
In some scenarios, shared memory is reallocated or resized by qemu, so
again mmap is needed.
>
> > + if (rc == MAP_FAILED) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> > + return -1;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > +
> > + if (dev->inflight_info.fd)
> > + close(dev->inflight_info.fd);
> > +
> > + dev->inflight_info.fd = fd;
> > + dev->inflight_info.addr = rc;
> > + dev->inflight_info.size = mmap_size;
> > +
> > + for (i = 0; i < num_queues; i++) {
> > + vq = dev->virtqueue[i];
> > + vq->inflight = (VhostInflightInfo *)rc;
> > + rc = (void *)((char *)rc + pervq_inflight_size);
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > static int
> > vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> > }
> >
> > static int
> > +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> > +{
> > + uint16_t i = 0;
> > +
> > + if ((!vq->inflight))
> > + return RTE_VHOST_MSG_RESULT_ERR;
>
> Should check whether the feature is negotiated first.
>
> > +
> > + if (!vq->inflight->version) {
> > + vq->inflight->version = INFLIGHT_VERSION;
> > + return RTE_VHOST_MSG_RESULT_OK;
> > + }
> > +
> > + for (i = 0; i < vq->size; i++) {
> > + if (vq->inflight->desc[i].inflight == 1) {
> > + vq->inflight_flag = 1;
> > + break;
> > + }
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > +static int
> > vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > {
> > @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > close(vq->kickfd);
> > vq->kickfd = file.fd;
> >
> > + if (vhost_check_queue_inflights(vq)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Failed to inflights for vq: %d\n", file.index);
> > + return RTE_VHOST_MSG_RESULT_ERR;
> > + }
> > +
> > return RTE_VHOST_MSG_RESULT_OK;
> > }
> >
> > @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> > [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> > [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> > [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> > + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> > + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> > };
> >
> >
> > diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> > index 2a650fe4b..35f969b1b 100644
> > --- a/lib/librte_vhost/vhost_user.h
> > +++ b/lib/librte_vhost/vhost_user.h
> > @@ -23,7 +23,8 @@
> > (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> > - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> > + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> > + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
>
> It will advertise this feature for builtin net and crypto
> backends. It's probably not what you intended.
>
Indeed, this feature is mainly used for spdk-like backends. You mean
this function is disabled by default？
> >
> > typedef enum VhostUserRequest {
> > VHOST_USER_NONE = 0,
> > @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> > VHOST_USER_POSTCOPY_ADVISE = 28,
> > VHOST_USER_POSTCOPY_LISTEN = 29,
> > VHOST_USER_POSTCOPY_END = 30,
> > - VHOST_USER_MAX = 31
> > + VHOST_USER_GET_INFLIGHT_FD = 31,
> > + VHOST_USER_SET_INFLIGHT_FD = 32,
> > + VHOST_USER_MAX = 33
> > } VhostUserRequest;
> >
> > typedef enum VhostUserSlaveRequest {
> > @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> > uint64_t offset;
> > } VhostUserVringArea;
> >
> > +typedef struct VhostUserInflight {
> > + uint64_t mmap_size;
> > + uint64_t mmap_offset;
> > + uint16_t num_queues;
> > + uint16_t queue_size;
> > +} VhostUserInflight;
> > +
> > typedef struct VhostUserMsg {
> > union {
> > uint32_t master; /* a VhostUserRequest value */
> > @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> > struct vhost_vring_addr addr;
> > VhostUserMemory memory;
> > VhostUserLog log;
> > + VhostUserInflight inflight;
> > struct vhost_iotlb_msg iotlb;
> > VhostUserCryptoSessionParam crypto_session;
> > VhostUserVringArea area;
> > @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> > /* vhost_user.c */
> > int vhost_user_msg_handler(int vid, int fd);
> > int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> > +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
> >
> > /* socket.c */
> > int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> > --
> > 2.11.0
> >
Thank you for your comments. They will be revised in the next version.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-28 11:17 3% ` Tiwei Bie
@ 2019-04-29 4:07 0% ` lin li
2019-04-29 4:07 0% ` lin li
1 sibling, 1 reply; 200+ results
From: lin li @ 2019-04-29 4:07 UTC (permalink / raw)
To: Tiwei Bie
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
Tiwei Bie <tiwei.bie@intel.com> 于2019年4月28日周日 下午7:18写道：
>
> On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> > From: lilin24 <lilin24@baidu.com>
> >
> > This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> > and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> > buffer between qemu and backend.
> >
> > Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> > shared buffer from backend. Then qemu should send it back
> > through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
> >
> > This shared buffer is used to process inflight I/O when backend
> > reconnect.
> >
> > Signed-off-by: lilin24 <lilin24@baidu.com>
>
> You need to use your real name here.
>
> > Signed-off-by: Ni Xun <nixun@baidu.com>
> > Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> >
> > v2:
> > - add set&clr inflight entry function
> > v3:
> > - simplified some function implementations
> >
> > ---
>
> You can put change logs here (i.e. after ---).
>
> > lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> > lib/librte_vhost/vhost.c | 42 ++++++++
> > lib/librte_vhost/vhost.h | 11 ++
> > lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user.h | 16 ++-
> > 5 files changed, 351 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> > index d2c0c93f4..bc25591a8 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -71,6 +71,10 @@ extern "C" {
> > #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> > #endif
> >
> > +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> > +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> > +#endif
> > +
> > /** Indicate whether protocol features negotiation is supported. */
> > #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> > #define VHOST_USER_F_PROTOCOL_FEATURES 30
> > @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> > struct rte_vhost_mem_region regions[];
> > };
> >
> > +typedef struct VhostUserInflightEntry {
> > + uint8_t inflight;
> > +} VhostUserInflightEntry;
> > +
> > +typedef struct VhostInflightInfo {
> > + uint16_t version;
> > + uint16_t last_inflight_io;
> > + uint16_t used_idx;
> > + VhostUserInflightEntry desc[0];
> > +} VhostInflightInfo;
>
> Is there any details on above structure? Why does it not match
> QueueRegionSplit or QueueRegionPacked structures described in
> qemu/docs/interop/vhost-user.txt?
Qemu have its vhost-user backend，qemu did the submission of IO in it.
The implementation of dpdk is more general. It is just to mark inflight entry.
The submission of inflight entry is handle over to different backends.
They have their own ways to handle it, such as spdk.
So there are some differences in data structure.
>
> > +
> > struct rte_vhost_vring {
> > struct vring_desc *desc;
> > struct vring_avail *avail;
> > struct vring_used *used;
> > uint64_t log_guest_addr;
> >
> > + VhostInflightInfo *inflight;
> > + int inflight_flag;
> > +
> > /** Deprecated, use rte_vhost_vring_call() instead. */
> > int callfd;
> >
> > @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > int rte_vhost_vring_call(int vid, uint16_t vring_idx);
> >
> > /**
> > + * set inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> > + uint16_t idx);
> > +
> > +/**
> > + * clear inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param last_used_idx
> > + * next free used_idx
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx);
> > +
> > +/**
> > + * set last inflight io index.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> > + uint16_t idx);
>
> New APIs should be experimental and also need to be
> added in rte_vhost_version.map file.
>
> > +
> > +/**
> > * Get vhost RX queue avail count.
> > *
> > * @param vid
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> > index 163f4595e..9ba692935 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> > close(vq->callfd);
> > if (vq->kickfd >= 0)
> > close(vq->kickfd);
> > + if (vq->inflight)
> > + vq->inflight = NULL;
> > }
> >
> > /*
> > @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > vring->kickfd = vq->kickfd;
> > vring->size = vq->size;
> >
> > + vring->inflight = vq->inflight;
> > +
> > + vring->inflight_flag = vq->inflight_flag;
> > + vq->inflight_flag = 0;
>
> This will break the ABI. Better to introduce a new API to do this.
>
> > +
> > return 0;
> > }
> >
> > @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> > return 0;
> > }
> >
> > +void
> > +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > + if (unlikely(!inflight))
> > + return;
> > + inflight->desc[idx].inflight = 1;
> > +}
> > +
> > +void
> > +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + rte_compiler_barrier();
> > + inflight->desc[idx].inflight = 0;
> > + rte_compiler_barrier();
> > + inflight->used_idx = last_used_idx;
> > +}
> > +
> > +void
> > +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + inflight->last_inflight_io = idx;
> > +}
>
> The rte_vhost_vring is used to return information to apps.
>
> IIUC, you want to update vq->inflight. So the rte_vhost_vring
> param should be replaced by vid + vring_idx.
>
> > +
> > uint16_t
> > rte_vhost_avail_entries(int vid, uint16_t queue_id)
> > {
> > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> > index e9138dfab..537d74c71 100644
> > --- a/lib/librte_vhost/vhost.h
> > +++ b/lib/librte_vhost/vhost.h
> > @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> > /* Physical address of used ring, for logging */
> > uint64_t log_guest_addr;
> >
> > + /* Inflight share memory info */
> > + VhostInflightInfo *inflight;
> > + bool inflight_flag;
> > +
> > uint16_t nr_zmbuf;
> > uint16_t zmbuf_size;
> > uint16_t last_zmbuf_idx;
> > @@ -286,6 +290,12 @@ struct guest_page {
> > uint64_t size;
> > };
> >
> > +typedef struct VuDevInflightInfo {
> > + int fd;
> > + void *addr;
> > + uint64_t size;
> > +} VuDevInflightInfo;
>
> Please follow DPDK's coding style when defining internal structure.
>
> > +
> > /**
> > * Device structure contains all configuration information relating
> > * to the device.
> > @@ -303,6 +313,7 @@ struct virtio_net {
> > uint32_t nr_vring;
> > int dequeue_zero_copy;
> > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> > + VuDevInflightInfo inflight_info;
> > #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> > char ifname[IF_NAME_SZ];
> > uint64_t log_size;
> > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> [...]
> > +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> > +{
> > + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> > + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> > +}
> > +
> > +static int
> > +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd;
> > + uint64_t mmap_size;
> > + void *addr;
> > + uint16_t num_queues, queue_size;
> > + struct virtio_net *dev = *pdev;
> > +
> > + if (msg->size != sizeof(msg->payload.inflight)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Invalid get_inflight_fd message size is %d",
> > + msg->size);
> > + msg->payload.inflight.mmap_size = 0;
>
> In this case, you can't touch the payload.
>
> > + return 0;
>
> And an error should be returned.
>
> > + }
> > +
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> > + msg->payload.inflight.num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> > + msg->payload.inflight.queue_size);
> > + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> > +
> > + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> > + if (!addr) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> > + msg->payload.inflight.mmap_size = 0;
> > + return 0;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > + memset(addr, 0, mmap_size);
> > +
> > + dev->inflight_info.addr = addr;
> > + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> > + dev->inflight_info.fd = msg->fds[0] = fd;
> > + msg->payload.inflight.mmap_offset = 0;
> > + msg->fd_num = 1;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_size: %lu\n",
> > + msg->payload.inflight.mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_offset: %lu\n",
> > + msg->payload.inflight.mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight fd: %d\n", msg->fds[0]);
> > +
> > + return RTE_VHOST_MSG_RESULT_REPLY;
> > +}
> > +
> > +static int
> > +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd, i;
> > + uint64_t mmap_size, mmap_offset;
> > + uint16_t num_queues, queue_size;
> > + uint32_t pervq_inflight_size;
> > + void *rc;
> > + struct vhost_virtqueue *vq;
> > + struct virtio_net *dev = *pdev;
> > +
> > + fd = msg->fds[0];
> > + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> > + msg->size, fd);
> > + return -1;
>
> Ditto.
>
> > + }
> > +
> > + mmap_size = msg->payload.inflight.mmap_size;
> > + mmap_offset = msg->payload.inflight.mmap_offset;
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > + pervq_inflight_size = get_pervq_shm_size(queue_size);
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd num_queues: %u\n", num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd queue_size: %u\n", queue_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd fd: %d\n", fd);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd pervq_inflight_size: %d\n",
> > + pervq_inflight_size);
> > +
> > + if (dev->inflight_info.addr)
> > + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> > +
> > + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> > + fd, mmap_offset);
>
> Why call it rc? Maybe addr is a better name?
In some scenarios, shared memory is reallocated or resized by qemu, so
again mmap is needed.
>
> > + if (rc == MAP_FAILED) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> > + return -1;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > +
> > + if (dev->inflight_info.fd)
> > + close(dev->inflight_info.fd);
> > +
> > + dev->inflight_info.fd = fd;
> > + dev->inflight_info.addr = rc;
> > + dev->inflight_info.size = mmap_size;
> > +
> > + for (i = 0; i < num_queues; i++) {
> > + vq = dev->virtqueue[i];
> > + vq->inflight = (VhostInflightInfo *)rc;
> > + rc = (void *)((char *)rc + pervq_inflight_size);
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > static int
> > vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> > }
> >
> > static int
> > +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> > +{
> > + uint16_t i = 0;
> > +
> > + if ((!vq->inflight))
> > + return RTE_VHOST_MSG_RESULT_ERR;
>
> Should check whether the feature is negotiated first.
>
> > +
> > + if (!vq->inflight->version) {
> > + vq->inflight->version = INFLIGHT_VERSION;
> > + return RTE_VHOST_MSG_RESULT_OK;
> > + }
> > +
> > + for (i = 0; i < vq->size; i++) {
> > + if (vq->inflight->desc[i].inflight == 1) {
> > + vq->inflight_flag = 1;
> > + break;
> > + }
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > +static int
> > vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > {
> > @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > close(vq->kickfd);
> > vq->kickfd = file.fd;
> >
> > + if (vhost_check_queue_inflights(vq)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Failed to inflights for vq: %d\n", file.index);
> > + return RTE_VHOST_MSG_RESULT_ERR;
> > + }
> > +
> > return RTE_VHOST_MSG_RESULT_OK;
> > }
> >
> > @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> > [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> > [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> > [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> > + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> > + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> > };
> >
> >
> > diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> > index 2a650fe4b..35f969b1b 100644
> > --- a/lib/librte_vhost/vhost_user.h
> > +++ b/lib/librte_vhost/vhost_user.h
> > @@ -23,7 +23,8 @@
> > (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> > - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> > + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> > + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
>
> It will advertise this feature for builtin net and crypto
> backends. It's probably not what you intended.
>
Indeed, this feature is mainly used for spdk-like backends. You mean
this function is disabled by default？
> >
> > typedef enum VhostUserRequest {
> > VHOST_USER_NONE = 0,
> > @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> > VHOST_USER_POSTCOPY_ADVISE = 28,
> > VHOST_USER_POSTCOPY_LISTEN = 29,
> > VHOST_USER_POSTCOPY_END = 30,
> > - VHOST_USER_MAX = 31
> > + VHOST_USER_GET_INFLIGHT_FD = 31,
> > + VHOST_USER_SET_INFLIGHT_FD = 32,
> > + VHOST_USER_MAX = 33
> > } VhostUserRequest;
> >
> > typedef enum VhostUserSlaveRequest {
> > @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> > uint64_t offset;
> > } VhostUserVringArea;
> >
> > +typedef struct VhostUserInflight {
> > + uint64_t mmap_size;
> > + uint64_t mmap_offset;
> > + uint16_t num_queues;
> > + uint16_t queue_size;
> > +} VhostUserInflight;
> > +
> > typedef struct VhostUserMsg {
> > union {
> > uint32_t master; /* a VhostUserRequest value */
> > @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> > struct vhost_vring_addr addr;
> > VhostUserMemory memory;
> > VhostUserLog log;
> > + VhostUserInflight inflight;
> > struct vhost_iotlb_msg iotlb;
> > VhostUserCryptoSessionParam crypto_session;
> > VhostUserVringArea area;
> > @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> > /* vhost_user.c */
> > int vhost_user_msg_handler(int vid, int fd);
> > int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> > +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
> >
> > /* socket.c */
> > int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> > --
> > 2.11.0
> >
Thank you for your comments. They will be revised in the next version.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 16:23 4% ` Stephen Hemminger
@ 2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-29 9:28 4% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-28 16:23 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Sun, 28 Apr 2019 17:58:48 +0300
Arnon Warshavsky <arnon@qwilt.com> wrote:
These deprecation notices are unnecessary. These are not public API's.
> +* eal: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_eal/common/eal_thread.h`` replace
> + ``void eal_thread_init_master(unsigned lcore_id)``
> + to return ``int``
This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
> +* kni: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> + to return ``int``
This is not a public API really so no deprecation needed.
It is just an include file used internally by library and the driver.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 14:58 4% [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni Arnon Warshavsky
2019-04-28 14:58 4% ` Arnon Warshavsky
@ 2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-29 9:28 4% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-28 16:23 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Sun, 28 Apr 2019 17:58:48 +0300
Arnon Warshavsky <arnon@qwilt.com> wrote:
These deprecation notices are unnecessary. These are not public API's.
> +* eal: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_eal/common/eal_thread.h`` replace
> + ``void eal_thread_init_master(unsigned lcore_id)``
> + to return ``int``
This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
> +* kni: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> + to return ``int``
This is not a public API really so no deprecation needed.
It is just an include file used internally by library and the driver.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 14:58 4% [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni Arnon Warshavsky
@ 2019-04-28 14:58 4% ` Arnon Warshavsky
2019-04-28 16:23 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Arnon Warshavsky @ 2019-04-28 14:58 UTC (permalink / raw)
To: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare
Cc: arnonw, Arnon Warshavsky
For the purpose of removing instances of rte_panic
from the init sequence, some void functions need to change
to return an error code.The planned modifications of 19.08
require to change one eal function and one kni function.
Signed-off-by: Arnon Warshavsky <arnon@qwilt.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..c4ab9a2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,12 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_eal/common/eal_thread.h`` replace
+ ``void eal_thread_init_master(unsigned lcore_id)``
+ to return ``int``
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
@@ -65,6 +71,12 @@ Deprecation Notices
kernel modules in DPDK. As a result users won't be able to use ``ethtool``
via ``igb`` & ``ixgbe`` anymore.
+* kni: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_kni/rte_kni_fifo.h`` replace
+ ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
+ to return ``int``
+
* cryptodev: New member in ``rte_cryptodev_config`` to allow applications to
disable features supported by the crypto device. Only the following features
would be allowed to be disabled this way,
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
@ 2019-04-28 14:58 4% Arnon Warshavsky
2019-04-28 14:58 4% ` Arnon Warshavsky
2019-04-28 16:23 4% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Arnon Warshavsky @ 2019-04-28 14:58 UTC (permalink / raw)
To: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare
Cc: arnonw, Arnon Warshavsky
For the purpose of removing instances of rte_panic
from the init sequence, some void functions need to change
to return an error code.The planned modifications of 19.08
require to change one eal function and one kni function.
Signed-off-by: Arnon Warshavsky <arnon@qwilt.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..c4ab9a2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,12 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_eal/common/eal_thread.h`` replace
+ ``void eal_thread_init_master(unsigned lcore_id)``
+ to return ``int``
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
@@ -65,6 +71,12 @@ Deprecation Notices
kernel modules in DPDK. As a result users won't be able to use ``ethtool``
via ``igb`` & ``ixgbe`` anymore.
+* kni: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_kni/rte_kni_fifo.h`` replace
+ ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
+ to return ``int``
+
* cryptodev: New member in ``rte_cryptodev_config`` to allow applications to
disable features supported by the crypto device. Only the following features
would be allowed to be disabled this way,
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
2019-04-28 11:17 3% ` Tiwei Bie
@ 2019-04-28 11:17 3% ` Tiwei Bie
2019-04-29 4:07 0% ` lin li
1 sibling, 0 replies; 200+ results
From: Tiwei Bie @ 2019-04-28 11:17 UTC (permalink / raw)
To: Li Lin
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> From: lilin24 <lilin24@baidu.com>
>
> This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> buffer between qemu and backend.
>
> Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> shared buffer from backend. Then qemu should send it back
> through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
>
> This shared buffer is used to process inflight I/O when backend
> reconnect.
>
> Signed-off-by: lilin24 <lilin24@baidu.com>
You need to use your real name here.
> Signed-off-by: Ni Xun <nixun@baidu.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
>
> v2:
> - add set&clr inflight entry function
> v3:
> - simplified some function implementations
>
> ---
You can put change logs here (i.e. after ---).
> lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> lib/librte_vhost/vhost.c | 42 ++++++++
> lib/librte_vhost/vhost.h | 11 ++
> lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user.h | 16 ++-
> 5 files changed, 351 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> index d2c0c93f4..bc25591a8 100644
> --- a/lib/librte_vhost/rte_vhost.h
> +++ b/lib/librte_vhost/rte_vhost.h
> @@ -71,6 +71,10 @@ extern "C" {
> #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> #endif
>
> +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> +#endif
> +
> /** Indicate whether protocol features negotiation is supported. */
> #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> #define VHOST_USER_F_PROTOCOL_FEATURES 30
> @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> struct rte_vhost_mem_region regions[];
> };
>
> +typedef struct VhostUserInflightEntry {
> + uint8_t inflight;
> +} VhostUserInflightEntry;
> +
> +typedef struct VhostInflightInfo {
> + uint16_t version;
> + uint16_t last_inflight_io;
> + uint16_t used_idx;
> + VhostUserInflightEntry desc[0];
> +} VhostInflightInfo;
Is there any details on above structure? Why does it not match
QueueRegionSplit or QueueRegionPacked structures described in
qemu/docs/interop/vhost-user.txt?
> +
> struct rte_vhost_vring {
> struct vring_desc *desc;
> struct vring_avail *avail;
> struct vring_used *used;
> uint64_t log_guest_addr;
>
> + VhostInflightInfo *inflight;
> + int inflight_flag;
> +
> /** Deprecated, use rte_vhost_vring_call() instead. */
> int callfd;
>
> @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> int rte_vhost_vring_call(int vid, uint16_t vring_idx);
>
> /**
> + * set inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> + uint16_t idx);
> +
> +/**
> + * clear inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param last_used_idx
> + * next free used_idx
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx);
> +
> +/**
> + * set last inflight io index.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> + uint16_t idx);
New APIs should be experimental and also need to be
added in rte_vhost_version.map file.
> +
> +/**
> * Get vhost RX queue avail count.
> *
> * @param vid
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index 163f4595e..9ba692935 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> close(vq->callfd);
> if (vq->kickfd >= 0)
> close(vq->kickfd);
> + if (vq->inflight)
> + vq->inflight = NULL;
> }
>
> /*
> @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> vring->kickfd = vq->kickfd;
> vring->size = vq->size;
>
> + vring->inflight = vq->inflight;
> +
> + vring->inflight_flag = vq->inflight_flag;
> + vq->inflight_flag = 0;
This will break the ABI. Better to introduce a new API to do this.
> +
> return 0;
> }
>
> @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> return 0;
> }
>
> +void
> +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> + if (unlikely(!inflight))
> + return;
> + inflight->desc[idx].inflight = 1;
> +}
> +
> +void
> +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + rte_compiler_barrier();
> + inflight->desc[idx].inflight = 0;
> + rte_compiler_barrier();
> + inflight->used_idx = last_used_idx;
> +}
> +
> +void
> +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + inflight->last_inflight_io = idx;
> +}
The rte_vhost_vring is used to return information to apps.
IIUC, you want to update vq->inflight. So the rte_vhost_vring
param should be replaced by vid + vring_idx.
> +
> uint16_t
> rte_vhost_avail_entries(int vid, uint16_t queue_id)
> {
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index e9138dfab..537d74c71 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> /* Physical address of used ring, for logging */
> uint64_t log_guest_addr;
>
> + /* Inflight share memory info */
> + VhostInflightInfo *inflight;
> + bool inflight_flag;
> +
> uint16_t nr_zmbuf;
> uint16_t zmbuf_size;
> uint16_t last_zmbuf_idx;
> @@ -286,6 +290,12 @@ struct guest_page {
> uint64_t size;
> };
>
> +typedef struct VuDevInflightInfo {
> + int fd;
> + void *addr;
> + uint64_t size;
> +} VuDevInflightInfo;
Please follow DPDK's coding style when defining internal structure.
> +
> /**
> * Device structure contains all configuration information relating
> * to the device.
> @@ -303,6 +313,7 @@ struct virtio_net {
> uint32_t nr_vring;
> int dequeue_zero_copy;
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> + VuDevInflightInfo inflight_info;
> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> char ifname[IF_NAME_SZ];
> uint64_t log_size;
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
[...]
> +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> +{
> + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> +}
> +
> +static int
> +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd;
> + uint64_t mmap_size;
> + void *addr;
> + uint16_t num_queues, queue_size;
> + struct virtio_net *dev = *pdev;
> +
> + if (msg->size != sizeof(msg->payload.inflight)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Invalid get_inflight_fd message size is %d",
> + msg->size);
> + msg->payload.inflight.mmap_size = 0;
In this case, you can't touch the payload.
> + return 0;
And an error should be returned.
> + }
> +
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> +
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> + msg->payload.inflight.num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> + msg->payload.inflight.queue_size);
> + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> +
> + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> + if (!addr) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> + msg->payload.inflight.mmap_size = 0;
> + return 0;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> + memset(addr, 0, mmap_size);
> +
> + dev->inflight_info.addr = addr;
> + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> + dev->inflight_info.fd = msg->fds[0] = fd;
> + msg->payload.inflight.mmap_offset = 0;
> + msg->fd_num = 1;
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_size: %lu\n",
> + msg->payload.inflight.mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_offset: %lu\n",
> + msg->payload.inflight.mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight fd: %d\n", msg->fds[0]);
> +
> + return RTE_VHOST_MSG_RESULT_REPLY;
> +}
> +
> +static int
> +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd, i;
> + uint64_t mmap_size, mmap_offset;
> + uint16_t num_queues, queue_size;
> + uint32_t pervq_inflight_size;
> + void *rc;
> + struct vhost_virtqueue *vq;
> + struct virtio_net *dev = *pdev;
> +
> + fd = msg->fds[0];
> + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> + msg->size, fd);
> + return -1;
Ditto.
> + }
> +
> + mmap_size = msg->payload.inflight.mmap_size;
> + mmap_offset = msg->payload.inflight.mmap_offset;
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> + pervq_inflight_size = get_pervq_shm_size(queue_size);
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd num_queues: %u\n", num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd queue_size: %u\n", queue_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd fd: %d\n", fd);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd pervq_inflight_size: %d\n",
> + pervq_inflight_size);
> +
> + if (dev->inflight_info.addr)
> + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> +
> + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> + fd, mmap_offset);
Why call it rc? Maybe addr is a better name?
> + if (rc == MAP_FAILED) {
> + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> + return -1;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> +
> + if (dev->inflight_info.fd)
> + close(dev->inflight_info.fd);
> +
> + dev->inflight_info.fd = fd;
> + dev->inflight_info.addr = rc;
> + dev->inflight_info.size = mmap_size;
> +
> + for (i = 0; i < num_queues; i++) {
> + vq = dev->virtqueue[i];
> + vq->inflight = (VhostInflightInfo *)rc;
> + rc = (void *)((char *)rc + pervq_inflight_size);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> static int
> vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> }
>
> static int
> +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> +{
> + uint16_t i = 0;
> +
> + if ((!vq->inflight))
> + return RTE_VHOST_MSG_RESULT_ERR;
Should check whether the feature is negotiated first.
> +
> + if (!vq->inflight->version) {
> + vq->inflight->version = INFLIGHT_VERSION;
> + return RTE_VHOST_MSG_RESULT_OK;
> + }
> +
> + for (i = 0; i < vq->size; i++) {
> + if (vq->inflight->desc[i].inflight == 1) {
> + vq->inflight_flag = 1;
> + break;
> + }
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> +static int
> vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> {
> @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> close(vq->kickfd);
> vq->kickfd = file.fd;
>
> + if (vhost_check_queue_inflights(vq)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Failed to inflights for vq: %d\n", file.index);
> + return RTE_VHOST_MSG_RESULT_ERR;
> + }
> +
> return RTE_VHOST_MSG_RESULT_OK;
> }
>
> @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> };
>
>
> diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> index 2a650fe4b..35f969b1b 100644
> --- a/lib/librte_vhost/vhost_user.h
> +++ b/lib/librte_vhost/vhost_user.h
> @@ -23,7 +23,8 @@
> (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
It will advertise this feature for builtin net and crypto
backends. It's probably not what you intended.
>
> typedef enum VhostUserRequest {
> VHOST_USER_NONE = 0,
> @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> VHOST_USER_POSTCOPY_ADVISE = 28,
> VHOST_USER_POSTCOPY_LISTEN = 29,
> VHOST_USER_POSTCOPY_END = 30,
> - VHOST_USER_MAX = 31
> + VHOST_USER_GET_INFLIGHT_FD = 31,
> + VHOST_USER_SET_INFLIGHT_FD = 32,
> + VHOST_USER_MAX = 33
> } VhostUserRequest;
>
> typedef enum VhostUserSlaveRequest {
> @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> uint64_t offset;
> } VhostUserVringArea;
>
> +typedef struct VhostUserInflight {
> + uint64_t mmap_size;
> + uint64_t mmap_offset;
> + uint16_t num_queues;
> + uint16_t queue_size;
> +} VhostUserInflight;
> +
> typedef struct VhostUserMsg {
> union {
> uint32_t master; /* a VhostUserRequest value */
> @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> struct vhost_vring_addr addr;
> VhostUserMemory memory;
> VhostUserLog log;
> + VhostUserInflight inflight;
> struct vhost_iotlb_msg iotlb;
> VhostUserCryptoSessionParam crypto_session;
> VhostUserVringArea area;
> @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> /* vhost_user.c */
> int vhost_user_msg_handler(int vid, int fd);
> int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
>
> /* socket.c */
> int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> --
> 2.11.0
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
@ 2019-04-28 11:17 3% ` Tiwei Bie
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-29 4:07 0% ` lin li
0 siblings, 2 replies; 200+ results
From: Tiwei Bie @ 2019-04-28 11:17 UTC (permalink / raw)
To: Li Lin
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> From: lilin24 <lilin24@baidu.com>
>
> This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> buffer between qemu and backend.
>
> Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> shared buffer from backend. Then qemu should send it back
> through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
>
> This shared buffer is used to process inflight I/O when backend
> reconnect.
>
> Signed-off-by: lilin24 <lilin24@baidu.com>
You need to use your real name here.
> Signed-off-by: Ni Xun <nixun@baidu.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
>
> v2:
> - add set&clr inflight entry function
> v3:
> - simplified some function implementations
>
> ---
You can put change logs here (i.e. after ---).
> lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> lib/librte_vhost/vhost.c | 42 ++++++++
> lib/librte_vhost/vhost.h | 11 ++
> lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user.h | 16 ++-
> 5 files changed, 351 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> index d2c0c93f4..bc25591a8 100644
> --- a/lib/librte_vhost/rte_vhost.h
> +++ b/lib/librte_vhost/rte_vhost.h
> @@ -71,6 +71,10 @@ extern "C" {
> #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> #endif
>
> +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> +#endif
> +
> /** Indicate whether protocol features negotiation is supported. */
> #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> #define VHOST_USER_F_PROTOCOL_FEATURES 30
> @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> struct rte_vhost_mem_region regions[];
> };
>
> +typedef struct VhostUserInflightEntry {
> + uint8_t inflight;
> +} VhostUserInflightEntry;
> +
> +typedef struct VhostInflightInfo {
> + uint16_t version;
> + uint16_t last_inflight_io;
> + uint16_t used_idx;
> + VhostUserInflightEntry desc[0];
> +} VhostInflightInfo;
Is there any details on above structure? Why does it not match
QueueRegionSplit or QueueRegionPacked structures described in
qemu/docs/interop/vhost-user.txt?
> +
> struct rte_vhost_vring {
> struct vring_desc *desc;
> struct vring_avail *avail;
> struct vring_used *used;
> uint64_t log_guest_addr;
>
> + VhostInflightInfo *inflight;
> + int inflight_flag;
> +
> /** Deprecated, use rte_vhost_vring_call() instead. */
> int callfd;
>
> @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> int rte_vhost_vring_call(int vid, uint16_t vring_idx);
>
> /**
> + * set inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> + uint16_t idx);
> +
> +/**
> + * clear inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param last_used_idx
> + * next free used_idx
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx);
> +
> +/**
> + * set last inflight io index.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> + uint16_t idx);
New APIs should be experimental and also need to be
added in rte_vhost_version.map file.
> +
> +/**
> * Get vhost RX queue avail count.
> *
> * @param vid
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index 163f4595e..9ba692935 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> close(vq->callfd);
> if (vq->kickfd >= 0)
> close(vq->kickfd);
> + if (vq->inflight)
> + vq->inflight = NULL;
> }
>
> /*
> @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> vring->kickfd = vq->kickfd;
> vring->size = vq->size;
>
> + vring->inflight = vq->inflight;
> +
> + vring->inflight_flag = vq->inflight_flag;
> + vq->inflight_flag = 0;
This will break the ABI. Better to introduce a new API to do this.
> +
> return 0;
> }
>
> @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> return 0;
> }
>
> +void
> +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> + if (unlikely(!inflight))
> + return;
> + inflight->desc[idx].inflight = 1;
> +}
> +
> +void
> +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + rte_compiler_barrier();
> + inflight->desc[idx].inflight = 0;
> + rte_compiler_barrier();
> + inflight->used_idx = last_used_idx;
> +}
> +
> +void
> +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + inflight->last_inflight_io = idx;
> +}
The rte_vhost_vring is used to return information to apps.
IIUC, you want to update vq->inflight. So the rte_vhost_vring
param should be replaced by vid + vring_idx.
> +
> uint16_t
> rte_vhost_avail_entries(int vid, uint16_t queue_id)
> {
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index e9138dfab..537d74c71 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> /* Physical address of used ring, for logging */
> uint64_t log_guest_addr;
>
> + /* Inflight share memory info */
> + VhostInflightInfo *inflight;
> + bool inflight_flag;
> +
> uint16_t nr_zmbuf;
> uint16_t zmbuf_size;
> uint16_t last_zmbuf_idx;
> @@ -286,6 +290,12 @@ struct guest_page {
> uint64_t size;
> };
>
> +typedef struct VuDevInflightInfo {
> + int fd;
> + void *addr;
> + uint64_t size;
> +} VuDevInflightInfo;
Please follow DPDK's coding style when defining internal structure.
> +
> /**
> * Device structure contains all configuration information relating
> * to the device.
> @@ -303,6 +313,7 @@ struct virtio_net {
> uint32_t nr_vring;
> int dequeue_zero_copy;
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> + VuDevInflightInfo inflight_info;
> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> char ifname[IF_NAME_SZ];
> uint64_t log_size;
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
[...]
> +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> +{
> + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> +}
> +
> +static int
> +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd;
> + uint64_t mmap_size;
> + void *addr;
> + uint16_t num_queues, queue_size;
> + struct virtio_net *dev = *pdev;
> +
> + if (msg->size != sizeof(msg->payload.inflight)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Invalid get_inflight_fd message size is %d",
> + msg->size);
> + msg->payload.inflight.mmap_size = 0;
In this case, you can't touch the payload.
> + return 0;
And an error should be returned.
> + }
> +
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> +
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> + msg->payload.inflight.num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> + msg->payload.inflight.queue_size);
> + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> +
> + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> + if (!addr) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> + msg->payload.inflight.mmap_size = 0;
> + return 0;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> + memset(addr, 0, mmap_size);
> +
> + dev->inflight_info.addr = addr;
> + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> + dev->inflight_info.fd = msg->fds[0] = fd;
> + msg->payload.inflight.mmap_offset = 0;
> + msg->fd_num = 1;
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_size: %lu\n",
> + msg->payload.inflight.mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_offset: %lu\n",
> + msg->payload.inflight.mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight fd: %d\n", msg->fds[0]);
> +
> + return RTE_VHOST_MSG_RESULT_REPLY;
> +}
> +
> +static int
> +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd, i;
> + uint64_t mmap_size, mmap_offset;
> + uint16_t num_queues, queue_size;
> + uint32_t pervq_inflight_size;
> + void *rc;
> + struct vhost_virtqueue *vq;
> + struct virtio_net *dev = *pdev;
> +
> + fd = msg->fds[0];
> + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> + msg->size, fd);
> + return -1;
Ditto.
> + }
> +
> + mmap_size = msg->payload.inflight.mmap_size;
> + mmap_offset = msg->payload.inflight.mmap_offset;
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> + pervq_inflight_size = get_pervq_shm_size(queue_size);
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd num_queues: %u\n", num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd queue_size: %u\n", queue_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd fd: %d\n", fd);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd pervq_inflight_size: %d\n",
> + pervq_inflight_size);
> +
> + if (dev->inflight_info.addr)
> + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> +
> + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> + fd, mmap_offset);
Why call it rc? Maybe addr is a better name?
> + if (rc == MAP_FAILED) {
> + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> + return -1;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> +
> + if (dev->inflight_info.fd)
> + close(dev->inflight_info.fd);
> +
> + dev->inflight_info.fd = fd;
> + dev->inflight_info.addr = rc;
> + dev->inflight_info.size = mmap_size;
> +
> + for (i = 0; i < num_queues; i++) {
> + vq = dev->virtqueue[i];
> + vq->inflight = (VhostInflightInfo *)rc;
> + rc = (void *)((char *)rc + pervq_inflight_size);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> static int
> vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> }
>
> static int
> +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> +{
> + uint16_t i = 0;
> +
> + if ((!vq->inflight))
> + return RTE_VHOST_MSG_RESULT_ERR;
Should check whether the feature is negotiated first.
> +
> + if (!vq->inflight->version) {
> + vq->inflight->version = INFLIGHT_VERSION;
> + return RTE_VHOST_MSG_RESULT_OK;
> + }
> +
> + for (i = 0; i < vq->size; i++) {
> + if (vq->inflight->desc[i].inflight == 1) {
> + vq->inflight_flag = 1;
> + break;
> + }
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> +static int
> vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> {
> @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> close(vq->kickfd);
> vq->kickfd = file.fd;
>
> + if (vhost_check_queue_inflights(vq)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Failed to inflights for vq: %d\n", file.index);
> + return RTE_VHOST_MSG_RESULT_ERR;
> + }
> +
> return RTE_VHOST_MSG_RESULT_OK;
> }
>
> @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> };
>
>
> diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> index 2a650fe4b..35f969b1b 100644
> --- a/lib/librte_vhost/vhost_user.h
> +++ b/lib/librte_vhost/vhost_user.h
> @@ -23,7 +23,8 @@
> (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
It will advertise this feature for builtin net and crypto
backends. It's probably not what you intended.
>
> typedef enum VhostUserRequest {
> VHOST_USER_NONE = 0,
> @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> VHOST_USER_POSTCOPY_ADVISE = 28,
> VHOST_USER_POSTCOPY_LISTEN = 29,
> VHOST_USER_POSTCOPY_END = 30,
> - VHOST_USER_MAX = 31
> + VHOST_USER_GET_INFLIGHT_FD = 31,
> + VHOST_USER_SET_INFLIGHT_FD = 32,
> + VHOST_USER_MAX = 33
> } VhostUserRequest;
>
> typedef enum VhostUserSlaveRequest {
> @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> uint64_t offset;
> } VhostUserVringArea;
>
> +typedef struct VhostUserInflight {
> + uint64_t mmap_size;
> + uint64_t mmap_offset;
> + uint16_t num_queues;
> + uint16_t queue_size;
> +} VhostUserInflight;
> +
> typedef struct VhostUserMsg {
> union {
> uint32_t master; /* a VhostUserRequest value */
> @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> struct vhost_vring_addr addr;
> VhostUserMemory memory;
> VhostUserLog log;
> + VhostUserInflight inflight;
> struct vhost_iotlb_msg iotlb;
> VhostUserCryptoSessionParam crypto_session;
> VhostUserVringArea area;
> @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> /* vhost_user.c */
> int vhost_user_msg_handler(int vid, int fd);
> int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
>
> /* socket.c */
> int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> --
> 2.11.0
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 1% [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
@ 2019-04-26 15:14 1% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/compressdevs/overview.rst | 2 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/cryptodevs/aesni_mb.rst | 2 +-
doc/guides/cryptodevs/overview.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 2 +-
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/howto/lm_bond_virtio_sriov.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 ++--
doc/guides/howto/rte_flow.rst | 6 ++---
doc/guides/howto/telemetry.rst | 2 +-
.../howto/virtio_user_as_exceptional_path.rst | 8 +++----
doc/guides/nics/af_packet.rst | 4 ++--
doc/guides/nics/atlantic.rst | 2 +-
doc/guides/nics/cxgbe.rst | 4 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/dpaa2.rst | 2 +-
doc/guides/nics/ena.rst | 2 +-
doc/guides/nics/enetc.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 2 +-
doc/guides/nics/ixgbe.rst | 4 ++--
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/mlx5.rst | 4 ++--
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.rst | 2 +-
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/nfp.rst | 4 ++--
doc/guides/nics/sfc_efx.rst | 14 +++++------
doc/guides/nics/szedata2.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/platform/dpaa.rst | 4 ++--
doc/guides/platform/dpaa2.rst | 4 ++--
doc/guides/prog_guide/bbdev.rst | 4 ++--
doc/guides/prog_guide/compressdev.rst | 6 ++---
doc/guides/prog_guide/cryptodev_lib.rst | 12 +++++-----
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/efd_lib.rst | 2 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
.../prog_guide/event_ethernet_rx_adapter.rst | 6 ++---
doc/guides/prog_guide/eventdev.rst | 6 ++---
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++-------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 2 +-
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 ++--
doc/guides/prog_guide/rte_flow.rst | 8 +++----
doc/guides/prog_guide/rte_security.rst | 20 ++++++++--------
doc/guides/prog_guide/traffic_management.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 2 +-
doc/guides/rawdevs/ifpga_rawdev.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 8 +++----
doc/guides/rel_notes/release_17_11.rst | 10 ++++----
doc/guides/sample_app_ug/bbdev_app.rst | 4 ++--
doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 2 +-
doc/guides/sample_app_ug/ip_pipeline.rst | 4 ++--
doc/guides/sample_app_ug/ipsec_secgw.rst | 8 +++----
doc/guides/sample_app_ug/performance_thread.rst | 4 ++--
doc/guides/sample_app_ug/qos_metering.rst | 2 +-
doc/guides/sample_app_ug/test_pipeline.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 4 ++--
doc/guides/sample_app_ug/vhost_scsi.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 10 ++++----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++---------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
71 files changed, 170 insertions(+), 170 deletions(-)
diff --git a/doc/guides/compressdevs/overview.rst b/doc/guides/compressdevs/overview.rst
index 70bbe82..809e4e6 100644
--- a/doc/guides/compressdevs/overview.rst
+++ b/doc/guides/compressdevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
without making any modifications to it (no compression done).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means PMD supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e6..3b2b174 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -8,7 +8,7 @@ Contributing Code to DPDK
This document outlines the guidelines for submitting code to DPDK.
-The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
`How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 8915201..1eff2b0 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -129,7 +129,7 @@ Extra notes
For AES Counter mode (AES-CTR), the library supports two different sizes for Initialization
Vector (IV):
-* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, which internally
+* 12 bytes: used mainly for IPsec, as it requires 12 bytes from the user, which internally
are appended the counter block (4 bytes), which is set to 1 for the first block
(no padding required from the user)
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index 12f342b..a972c79 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
being the operation in-place (input address = output address).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means pmd supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index a754a27..7004ca4 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -165,7 +165,7 @@ operation:
For pure small packet size (64 bytes) traffic however the multi-core mode is not
an optimal solution, as it doesn't give significant per-core performance improvement.
For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
- For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+ For large packets (1.5 kbytes) scheduler shows linear scaling in performance
up to eight cores.
Each worker uses its own slave cryptodev. Only software cryptodevs
are supported. Only the same type of cryptodevs should be used concurrently.
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
index 0262a33..979f6cd 100644
--- a/doc/guides/eventdevs/opdl.rst
+++ b/doc/guides/eventdevs/opdl.rst
@@ -8,7 +8,7 @@ The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
implementation of the eventdev API. It is particularly suited to packet\
processing workloads that have high throughput and low latency requirements.\
All packets follow the same path through the device. The order in which\
-packets follow is determinted by the order in which queues are set up.\
+packets follow is determined by the order in which queues are set up.\
Events are left on the ring until they are transmitted. As a result packets\
do not go out of order
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index afdcad7..04c8b03 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -70,7 +70,7 @@ Credit Quanta
The credit quanta is the number of credits that a port will fetch at a time from
the instance's credit pool. Higher numbers will cause less overhead in the
atomic credit fetch code, however it also reduces the overall number of credits
-in the system faster. A balanced number (eg 32) ensures that only small numbers
+in the system faster. A balanced number (e.g. 32) ensures that only small numbers
of credits are pre-allocated at a time, while also mitigating performance impact
of the atomics.
@@ -100,7 +100,7 @@ feature would be significant.
~~~~~~~~~~~~~~~~~~
The software eventdev does not support creating queues that handle all types of
-traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
+traffic. An eventdev with this capability allows enqueuing Atomic, Ordered and
Parallel traffic to the same queue, but scheduling each of them appropriately.
The reason to not allow Atomic, Ordered and Parallel event types in the
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index ee8ccda..07563b3 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -328,7 +328,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
testpmd> show bonding config 2
testpmd> port attach 0000:00:04.0
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 6ebc10f..ecb7832 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -243,7 +243,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
Virtio traffic is seen at P0 and P1.
@@ -338,7 +338,7 @@ reset_vf_on_212_131.sh
#!/bin/sh
# This script is run on the host 10.237.212.131 to reset SRIOV
- # BDF for Ninatic NIC is 0000:06:00.0
+ # BDF for Niantic NIC is 0000:06:00.0
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
echo 0 > /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 3dcda6c..e197376 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -23,7 +23,7 @@ In this example we will create a simple rule that drops packets whose IPv4
destination equals 192.168.3.2. This code is equivalent to the following
testpmd command (wrapped for clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst is 192.168.3.2 / end actions drop / end
Code
@@ -118,7 +118,7 @@ a mask.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 /
end actions drop / end
@@ -219,7 +219,7 @@ In this example we will create a rule that routes all vlan id 123 to queue 3.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
+ testpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
end actions queue index 3 / end
Code
diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst
index 00f8f7a..e10804d 100644
--- a/doc/guides/howto/telemetry.rst
+++ b/doc/guides/howto/telemetry.rst
@@ -18,7 +18,7 @@ which acts as the client.
In DPDK, applications are used to initialize the ``telemetry``. To view incoming
traffic on featured ports, the application should be run first (ie. after ports
are configured). Once the application is running, the service assurance agent
-(for example the collectd plugin) should be run to begin querying the API.
+(for example the CollectD plugin) should be run to begin querying the API.
A client connects their Service Assurance application to the DPDK application
via a UNIX socket. Once a connection is established, a client can send JSON
diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst
index 4910c12..ec021af 100644
--- a/doc/guides/howto/virtio_user_as_exceptional_path.rst
+++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2016 Intel Corporation.
-.. _virtio_user_as_excpetional_path:
+.. _virtio_user_as_exceptional_path:
Virtio_user as Exceptional Path
===============================
@@ -22,7 +22,7 @@ solution is very promising in:
* Features
vhost-net is born to be a networking solution, which has lots of networking
- related featuers, like multi queue, tso, multi-seg mbuf, etc.
+ related features, like multi queue, tso, multi-seg mbuf, etc.
* Performance
@@ -38,7 +38,7 @@ in :numref:`figure_virtio_user_as_exceptional_path`.
.. figure:: img/virtio_user_as_exceptional_path.*
- Overview of a DPDK app using virtio-user as excpetional path
+ Overview of a DPDK app using virtio-user as exceptional path
Sample Usage
@@ -75,7 +75,7 @@ compiling the kernel and those kernel modules should be inserted.
* ``queues``
- Number of multi-queues. Each qeueue will be served by a kthread. For example:
+ Number of multi-queues. Each queue will be served by a kthread. For example:
.. code-block:: console
diff --git a/doc/guides/nics/af_packet.rst b/doc/guides/nics/af_packet.rst
index 1260bb2..efd6f1c 100644
--- a/doc/guides/nics/af_packet.rst
+++ b/doc/guides/nics/af_packet.rst
@@ -13,13 +13,13 @@ PACKET_MMAP, which provides a mmap'ed ring buffer, shared between user space
and kernel, that's used to send and receive packets. This helps reducing system
calls and the copies needed between user space and Kernel.
-The PACKET_FANOUT_HASH behaviour of AF_PACKET is used for frame reception.
+The PACKET_FANOUT_HASH behavior of AF_PACKET is used for frame reception.
Options and inherent limitations
--------------------------------
The following options can be provided to set up an af_packet port in DPDK.
-Some of these, in turn, will be used to configure the PAKET_MMAP settings.
+Some of these, in turn, will be used to configure the PACKET_MMAP settings.
* ``iface`` - name of the Kernel interface to attach to (required);
* ``qpairs`` - number of Rx and Tx queues (optional, default 1);
diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst
index 22f2410..3f3f294 100644
--- a/doc/guides/nics/atlantic.rst
+++ b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
- Port statistics
- RSS (Receive Side Scaling)
- Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
- MACSEC offload
Experimental API features
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index f3e6115..7a893cc 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -126,7 +126,7 @@ enabling debugging options may affect system performance.
- ``CONFIG_RTE_LIBRTE_CXGBE_TPUT`` (default **y**)
- Toggle behaviour to prefer Throughput or Latency.
+ Toggle behavior to prefer Throughput or Latency.
Runtime Options
~~~~~~~~~~~~~~~
@@ -140,7 +140,7 @@ be passed as part of EAL arguments. For example,
- ``keep_ovlan`` (default **0**)
- Toggle behaviour to keep/strip outer VLAN in Q-in-Q packets. If
+ Toggle behavior to keep/strip outer VLAN in Q-in-Q packets. If
enabled, the outer VLAN tag is preserved in Q-in-Q packets. Otherwise,
the outer VLAN tag is stripped in Q-in-Q packets.
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index fb7bc7d..2243a4a 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -251,7 +251,7 @@ state during application initialization:
automatically be assigned from the these high perf PUSH queues. Any queue
configuration beyond that will be standard Rx queues. The application can
choose to change their number if HW portals are limited.
- The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ The valid values are from '0' to '4'. The values shall be set to '0' if the
application want to use eventdev with DPAA device.
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index d74d8f8..b3b7678 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -379,7 +379,7 @@ active -- Ethernet, crypto, compression, etc.
DPBP based Mempool driver
~~~~~~~~~~~~~~~~~~~~~~~~~
-The DPBP driver is bound to a DPBP objects and provides sevices to
+The DPBP driver is bound to a DPBP objects and provides services to
create a hardware offloaded packet buffer mempool.
DPAA2 NIC Driver
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 80da4b6..d44f3cd 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -189,7 +189,7 @@ Prerequisites
reduces the latency of the packets by pushing the header directly through
the PCI to the device, before the DMA is even triggered. For proper work
kernel PCI driver must support write combining (WC). In mainline version of
- ``igb_uio`` (in DPDK repo) it must be enabled by loding module with
+ ``igb_uio`` (in DPDK repo) it must be enabled by loading module with
``wc_activate=1`` flag (example below). However, mainline's vfio-pci
driver in kernel doesn't have WC support yet (planed to be added).
If vfio-pci used user should be either turn off ENAv2 (to avoid performance
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 2620460..3c896ee 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -76,7 +76,7 @@ Supported ENETC SoCs
Prerequisites
~~~~~~~~~~~~~
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 726a69e..cdb55e0 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -224,7 +224,7 @@ the use of SR-IOV.
passthrough devices do not require libvirt, port profiles, and VM-FEX.
-.. _enic-genic-flow-api:
+.. _enic-generic-flow-api:
Generic Flow API support
------------------------
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c5bf322..d57ddc2 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -495,7 +495,7 @@ Supports adding traffic mirroring rules.
Inline crypto
-------------
-Supports inline crypto processing (eg. inline IPsec). See Security library and PMD documentation for more details.
+Supports inline crypto processing (e.g. inline IPsec). See Security library and PMD documentation for more details.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_SECURITY``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 9680a92..2e9ec79 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -580,7 +580,7 @@ bandwidth setting.
TC TX scheduling mode setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There're 2 TX scheduling modes for TCs, round robin and strict priority mode.
+There are 2 TX scheduling modes for TCs, round robin and strict priority mode.
If a TC is set to strict priority mode, it can consume unlimited bandwidth.
It means if APP has set the max bandwidth for that TC, it comes to no
effect.
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1c294b0..975143f 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -203,8 +203,8 @@ as a workaround.
X550 does not support legacy interrupt mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Desccription
-^^^^^^^^^^^^
+Description
+^^^^^^^^^^^
X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy
interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states
that the Interrupt Status bit is not implemented. The errata is the item #22
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index a66c595..602a06b 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -65,7 +65,7 @@ backend device by default.
PMD arguments
-------------
-``no_request_thread``, by default PMD creates a phtread for each KNI interface
+``no_request_thread``, by default PMD creates a pthread for each KNI interface
to handle Linux network interface control commands, like ``ifconfig kni0 up``
With ``no_request_thread`` option, pthread is not created and control commands
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index aaf1907..f6d7a16 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -83,7 +83,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx4**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx4**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5fa6b62..af1e408 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,7 +168,7 @@ Limitations
- must specify the VXLAN item with tunnel outer parameters.
- must specify the tunnel outer VNI in the VXLAN item.
- must specify the tunnel outer remote (destination) UDP port in the VXLAN item.
- - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed.
+ - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interface, wildcards not allowed.
- must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed.
- must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule.
@@ -216,7 +216,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx5**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx5**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 09e2f2a..bacc013 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -91,7 +91,7 @@ Limitations
chance to start in a sane state.
- MUSDK architecture does not support changing configuration in run time.
- All nessesary configurations should be done before first dev_start().
+ All necessary configurations should be done before first dev_start().
- RX queue start/stop is not supported.
diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 87fabf5..6dbb9a5 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -89,7 +89,7 @@ operations:
.. Note::
- The dpkd-devbind.py script can not be used since it only handles PCI devices.
+ The dpdk-devbind.py script can not be used since it only handles PCI devices.
Prerequisites
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index a7fb963..8df76c0 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -81,7 +81,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They are represented in DPDK as a single port.
-NFB-200G2QL card employs an addon cable which allows to connect it to two
+NFB-200G2QL card employs an add-on cable which allows to connect it to two
physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 09a8529..309fa5d 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -149,8 +149,8 @@ PF multiprocess support
-----------------------
Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary proceses with PF
-ports is limitted to only one.
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
This limitation will be solved in future versions but having basic multiprocess support
is important for allowing development and debugging through the PF using a secondary
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index eb47f25..6d01d05 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -96,7 +96,7 @@ Non-supported Features
The features not yet supported include:
-- Receive queue interupts
+- Receive queue interrupts
- Priority-based flow control
@@ -209,12 +209,12 @@ Validating flow rules depends on the firmware variant.
The :ref:`flow_isolated_mode` is supported.
-Ethernet destinaton individual/group match
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ethernet destination individual/group match
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet item supports I/G matching, if only the corresponding bit is set
-in the mask of destination address. If destinaton address in the spec is
-multicast, it matches all multicast (and broadcast) packets, oherwise it
+in the mask of destination address. If destination address in the spec is
+multicast, it matches all multicast (and broadcast) packets, otherwise it
matches unicast packets that are not filtered by other flow rules.
Exceptions to flow rules
@@ -348,10 +348,10 @@ boolean parameters value.
- ``perf_profile`` [auto|throughput|low-latency] (default **throughput**)
- Choose hardware tunning to be optimized for either throughput or
+ Choose hardware tuning to be optimized for either throughput or
low-latency.
**auto** allows NIC firmware to make a choice based on
- installed licences and firmware variant configured using **sfboot**.
+ installed licenses and firmware variant configured using **sfboot**.
- ``stats_update_period_ms`` [long] (default **1000**)
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index a2092f9..94dba82 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -89,7 +89,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They were historically represented in DPDK as a single port.
-However, the new NFB-200G2QL card employs an addon cable which allows to connect
+However, the new NFB-200G2QL card employs an add-on cable which allows to connect
it to two physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 063bd0b..4b6d77d 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -40,7 +40,7 @@ actual MAC address: ``00:64:74:61:70:[00-FF]``.
--vdev=net_tap0,mac="00:64:74:61:70:11"
The MAC address will have a user value passed as string. The MAC address is in
-format with delimeter ``:``. The string is byte converted to hex and you get
+format with delimiter ``:``. The string is byte converted to hex and you get
the actual MAC address: ``00:64:74:61:70:11``.
It is possible to specify a remote netdevice to capture packets from by adding
diff --git a/doc/guides/platform/dpaa.rst b/doc/guides/platform/dpaa.rst
index 3904871..6005f22 100644
--- a/doc/guides/platform/dpaa.rst
+++ b/doc/guides/platform/dpaa.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA Board Support Package
====================================
-This doc has information about steps to setup QorIq dpaa
+This doc has information about steps to setup QorIQ dpaa
based layerscape platform and information about common offload
hw block drivers of **NXP QorIQ DPAA** SoC family.
@@ -38,7 +38,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA PMD on a DPAA
+There are four main pre-requisites for executing DPAA PMD on a DPAA
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/platform/dpaa2.rst b/doc/guides/platform/dpaa2.rst
index 5a64406..2586af0 100644
--- a/doc/guides/platform/dpaa2.rst
+++ b/doc/guides/platform/dpaa2.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA2 Board Support Package
=====================================
-This doc has information about steps to setup NXP QoriQ DPAA2 platform
+This doc has information about steps to setup NXP QorIQ DPAA2 platform
and information about common offload hw block drivers of
**NXP QorIQ DPAA2** SoC family.
@@ -48,7 +48,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA2 PMD on a DPAA2
+There are four main pre-requisites for executing DPAA2 PMD on a DPAA2
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9de1444..658ffd4 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev device consists of
one or more queues identified by queue IDs. While different devices may have
different capabilities (e.g. support different operation types), all queues on
a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initializations time.
+for only one type of operation and is configured at initialization time.
When an operation is enqueued to a specific queue ID, the result is dequeued
from the same queue ID.
@@ -678,7 +678,7 @@ bbdev framework, by giving a sample code performing a loop-back operation with a
baseband processor capable of transceiving data packets.
The following sample C-like pseudo-code shows the basic steps to encode several
-buffers using (**sw_trubo**) bbdev PMD.
+buffers using (**sw_turbo**) bbdev PMD.
.. code-block:: c
diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst
index ad97037..a06c835 100644
--- a/doc/guides/prog_guide/compressdev.rst
+++ b/doc/guides/prog_guide/compressdev.rst
@@ -17,7 +17,7 @@ Device Creation
Physical compression devices are discovered during the bus probe of the EAL function
which is executed at DPDK initialization, based on their unique device identifier.
-For eg. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
+For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
@@ -379,7 +379,7 @@ using priv_xform would look like:
setup op->m_src and op->m_dst;
}
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, comp_ops, NUM_OPS);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deque = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, NUM_OPS);
} while (num_dqud < num_enqd);
@@ -526,7 +526,7 @@ An example pseudocode to set up and process a stream having NUM_CHUNKS with each
op->src.length = CHUNK_LEN;
op->input_chksum = 0;
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, &op[i], 1);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deqd = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, 1);
} while (num_deqd < num_enqd);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 74a930b..23fa5bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -14,7 +14,7 @@ and AEAD symmetric and asymmetric Crypto operations.
Design Principles
-----------------
-The cryptodev library follows the same basic principles as those used in DPDKs
+The cryptodev library follows the same basic principles as those used in DPDK's
Ethernet Device framework. The Crypto framework provides a generic Crypto device
framework which supports both physical (hardware) and virtual (software) Crypto
devices as well as a generic Crypto API which allows Crypto devices to be
@@ -48,7 +48,7 @@ From the command line using the --vdev EAL option
* If DPDK application requires multiple software crypto PMD devices then required
number of ``--vdev`` with appropriate libraries are to be added.
- * An Application with crypto PMD instaces sharing the same library requires unique ID.
+ * An Application with crypto PMD instances sharing the same library requires unique ID.
Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'``
@@ -396,7 +396,7 @@ Operation Management and Allocation
The cryptodev library provides an API set for managing Crypto operations which
utilize the Mempool Library to allocate operation buffers. Therefore, it ensures
-that the crytpo operation is interleaved optimally across the channels and
+that the crypto operation is interleaved optimally across the channels and
ranks for optimal processing.
A ``rte_crypto_op`` contains a field indicating the pool that it originated from.
When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool.
@@ -602,7 +602,7 @@ Sample code
There are various sample applications that show how to use the cryptodev library,
such as the L2fwd with Crypto sample application (L2fwd-crypto) and
-the IPSec Security Gateway application (ipsec-secgw).
+the IPsec Security Gateway application (ipsec-secgw).
While these applications demonstrate how an application can be created to perform
generic crypto operation, the required complexity hides the basic steps of
@@ -807,7 +807,7 @@ using one of the crypto PMDs available in DPDK.
/*
* Dequeue the crypto operations until all the operations
- * are proccessed in the crypto device.
+ * are processed in the crypto device.
*/
uint16_t num_dequeued_ops, total_num_dequeued_ops = 0;
do {
@@ -886,7 +886,7 @@ the order in which the transforms are passed indicates the order of the chaining
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
-asymmetric crypto xfroms.
+asymmetric crypto xforms.
Each xform defines specific asymmetric crypto algo. Currently supported are:
* RSA
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 96dbf30..74dba4d 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -204,7 +204,7 @@ Creates the following symbol:
Which ``dpdk-pmdinfogen`` scans for. Using this information other relevant
bits of data can be exported from the object file and used to produce a
hardware support description, that ``dpdk-pmdinfogen`` then encodes into a
-json formatted string in the following format:
+JSON formatted string in the following format:
.. code-block:: c
diff --git a/doc/guides/prog_guide/efd_lib.rst b/doc/guides/prog_guide/efd_lib.rst
index cb1a1df..2b355ff 100644
--- a/doc/guides/prog_guide/efd_lib.rst
+++ b/doc/guides/prog_guide/efd_lib.rst
@@ -423,6 +423,6 @@ References
1- EFD is based on collaborative research work between Intel and
Carnegie Mellon University (CMU), interested readers can refer to the paper
-“Scaling Up Clustered Network Appliances with ScaleBricks;” Dong Zhou et al.
+"Scaling Up Clustered Network Appliances with ScaleBricks" Dong Zhou et al.
at SIGCOMM 2015 (`http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p241.pdf`)
for more information.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index fa8afdb..c27f730 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -733,7 +733,7 @@ The most important fields in the structure and how they are used are described b
Malloc heap is a doubly-linked list, where each element keeps track of its
previous and next elements. Due to the fact that hugepage memory can come and
-go, neighbouring malloc elements may not necessarily be adjacent in memory.
+go, neighboring malloc elements may not necessarily be adjacent in memory.
Also, since a malloc element may span multiple pages, its contents may not
necessarily be IOVA-contiguous either - each malloc element is only guaranteed
to be virtually contiguous.
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index e955299..c7dda92 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -162,7 +162,7 @@ The servicing_weight member of struct rte_event_eth_rx_adapter_queue_conf
is applicable when the adapter uses a service core function. The application
has to enable Rx queue interrupts when configuring the ethernet device
using the ``rte_eth_dev_configure()`` function and then use a servicing_weight
-of zero when addding the Rx queue to the adapter.
+of zero when adding the Rx queue to the adapter.
The adapter creates a thread blocked on the interrupt, on an interrupt this
thread enqueues the port id and the queue id to a ring buffer. The adapter
@@ -180,9 +180,9 @@ Rx Callback for SW Rx Adapter
For SW based packet transfers, i.e., when the
``RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT`` is not set in the adapter's
capabilities flags for a particular ethernet device, the service function
-temporarily enqueues mbufs to an event buffer before batch enqueueing these
+temporarily enqueues mbufs to an event buffer before batch enqueuing these
to the event device. If the buffer fills up, the service function stops
-dequeueing packets from the ethernet device. The application may want to
+dequeuing packets from the ethernet device. The application may want to
monitor the buffer fill level and instruct the service function to selectively
enqueue packets to the event device. The application may also use some other
criteria to decide which packets should enter the event device even when
diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
index dcdfeb7..7ea14ba 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -42,7 +42,7 @@ The rte_event structure contains the following metadata fields, which the
application fills in to have the event scheduled as required:
* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
-* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``event_type`` - The source of this event, e.g. RTE_EVENT_TYPE_ETHDEV or CPU.
* ``sub_event_type`` - Distinguishes events inside the application, that have
the same event_type (see above)
* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
@@ -265,7 +265,7 @@ Linking Queues and Ports
The final step is to "wire up" the ports to the queues. After this, the
eventdev is capable of scheduling events, and when cores request work to do,
the correct events are provided to that core. Note that the RX core takes input
-from eg: a NIC so it is not linked to any eventdev queues.
+from e.g.: a NIC so it is not linked to any eventdev queues.
Linking all workers to atomic queues, and the TX core to the single-link queue
can be achieved like this:
@@ -276,7 +276,7 @@ can be achieved like this:
uint8_t tx_port_id = 5;
uint8_t atomic_qs[] = {0, 1};
uint8_t single_link_q = 2;
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
for(int worker_port_id = 1; worker_port_id <= 4; worker_port_id++) {
int links_made = rte_event_port_link(dev_id, worker_port_id, atomic_qs, NULL, 2);
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 84696d4..6fc0888 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -65,7 +65,7 @@ In that mode the library functions perform
- check SQN
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
- check padding data
- remove outer IP header (tunnel mode) / update IP header (transport mode)
@@ -88,7 +88,7 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
- check SQN
- check padding data
@@ -101,10 +101,10 @@ In that mode the library functions perform
- generate SQN and IV
- add outer IP header (tunnel mode) / update IP header (transport mode)
- add ESP header and trailer, padding and IV data
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -113,15 +113,15 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
* for outbound packets:
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ In that mode the library functions perform
* for inbound packets:
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
* for outbound packets:
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 7fcbd93..daf87f4 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -227,7 +227,7 @@ application functions:
``config_promiscusity``:
- Called when the user changes the promiscusity state of the KNI
+ Called when the user changes the promiscuity state of the KNI
interface. For example, when the user runs ``ip link set promisc
[on|off] dev <ifaceX>``. If the user sets this callback function to
NULL, but sets the ``port_id`` field to a value other than -1, a default
diff --git a/doc/guides/prog_guide/metrics_lib.rst b/doc/guides/prog_guide/metrics_lib.rst
index e68e4e7..89bc7d6 100644
--- a/doc/guides/prog_guide/metrics_lib.rst
+++ b/doc/guides/prog_guide/metrics_lib.rst
@@ -25,7 +25,7 @@ individual device. Since the metrics library is self-contained, the only
restriction on port numbers is that they are less than ``RTE_MAX_ETHPORTS``
- there is no requirement for the ports to actually exist.
-Initialising the library
+Initializing the library
------------------------
Before the library can be used, it has to be initialized by calling
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1384fe3..6196d3f 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -273,7 +273,7 @@ will be populated by IPC are as follows:
those peer processes that were active at the time of request, how many have
replied)
* ``msgs`` - pointer to where all of the responses are stored. The order in
- which responses appear is undefined. Whendoing sycnrhonous requests, this
+ which responses appear is undefined. When doing synchronous requests, this
memory must be freed by the requestor after request completes!
For asynchronous requests, a function pointer to the callback function must be
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 5af795c..a36ebef 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -64,7 +64,7 @@ The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
get a wall clock counter in user space. Typically it runs at <= 100MHz.
The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
-clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+clock counter is through the ARMv8 PMU subsystem. The PMU cycle counter runs
at CPU frequency. However, access to the PMU cycle counter from user space is
not enabled by default in the arm64 linux kernel. It is possible to enable
cycle counter for user space access by configuring the PMU from the privileged
@@ -75,7 +75,7 @@ scheme. Application can choose the PMU based implementation with
``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
The example below shows the steps to configure the PMU based cycle counter on
-an armv8 machine.
+an ARMv8 machine.
.. code-block:: console
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 0203f4f..937f52b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2129,7 +2129,7 @@ as defined in the ``rte_flow_action_raw_decap``
This action modifies the payload of matched flows. The data supplied must
be a valid header, either holding layer 2 data in case of removing layer 2
-before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
+before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
tunnel definition starting from layer 2 and moving to the tunnel item itself.
When applied to the original packet the resulting packet must be a
valid packet.
@@ -2279,7 +2279,7 @@ Action: ``DEC_TTL``
Decrease TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_dec_ttl:
@@ -2297,7 +2297,7 @@ Action: ``SET_TTL``
Assigns a new TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_set_ttl:
@@ -2725,7 +2725,7 @@ Caveats
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
-- There is no provision for reentrancy/multi-thread safety, although nothing
+- There is no provision for re-entrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index cb70caa..7d0734a 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -40,7 +40,7 @@ Inline Crypto
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
@@ -48,7 +48,7 @@ Ingress Data path - The packet is decrypted in RX path and relevant
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
arrived. The driver Rx path check the descriptors and and based on the
@@ -111,7 +111,7 @@ Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
@@ -119,7 +119,7 @@ Ingress Data path - The packet is decrypted in the RX path and relevant
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
@@ -132,7 +132,7 @@ to identify the security processing done on the packet.
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
@@ -150,7 +150,7 @@ to cross the MTU size.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
@@ -199,13 +199,13 @@ crypto device.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
@@ -217,7 +217,7 @@ for any protocol header addition.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
@@ -549,7 +549,7 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
struct rte_security_ipsec_sa_options options;
/**< various SA options */
enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
+ /**< IPsec SA Direction - Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< IPsec SA Protocol - AH/ESP */
enum rte_security_ipsec_sa_mode mode;
diff --git a/doc/guides/prog_guide/traffic_management.rst b/doc/guides/prog_guide/traffic_management.rst
index 98ac431..05b34d9 100644
--- a/doc/guides/prog_guide/traffic_management.rst
+++ b/doc/guides/prog_guide/traffic_management.rst
@@ -39,7 +39,7 @@ whether a specific implementation does meet the needs to the user application.
At the TM level, users can get high level idea with the help of various
parameters such as maximum number of nodes, maximum number of hierarchical
levels, maximum number of shapers, maximum number of private shapers, type of
-scheduling algorithm (Strict Priority, Weighted Fair Queueing , etc.), etc.,
+scheduling algorithm (Strict Priority, Weighted Fair Queuing , etc.), etc.,
supported by the implementation.
Likewise, users can query the capability of the TM at the hierarchical level to
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a86c07a..fc3ee43 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -63,7 +63,7 @@ The following is an overview of some key Vhost API functions:
512).
* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enableld).
+ boost could be above 70% (when TSO is enabled).
* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
PMD driver consume the mbuf but not release them timely.
diff --git a/doc/guides/rawdevs/ifpga_rawdev.rst b/doc/guides/rawdevs/ifpga_rawdev.rst
index d400db6..a3d92a6 100644
--- a/doc/guides/rawdevs/ifpga_rawdev.rst
+++ b/doc/guides/rawdevs/ifpga_rawdev.rst
@@ -91,7 +91,7 @@ Run-time parameters
-------------------
This driver is invoked automatically in systems added with Intel FPGA,
-but PR and IFPGA Bus scan is trigged by command line using
+but PR and IFPGA Bus scan is triggered by command line using
``--vdev 'ifpga_rawdev_cfg`` EAL option.
The following device parameters are supported:
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index 358dfa3..276327c 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -676,7 +676,7 @@ igb uio legacy mode can not be used in X710/XL710/XXV710
**Description**:
X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
- bit in the PCI status register. Linux delected them from INTx support table. The related
+ bit in the PCI status register. Linux deleted them from INTx support table. The related
`commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
**Implication**:
@@ -722,9 +722,9 @@ Linux kernel 4.10.0 iommu attribute read error
**Description**:
When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
/sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
- This bug is fixed in `Linux commmit a7fdb6e648fb
+ This bug is fixed in `Linux commit a7fdb6e648fb
<https://patchwork.kernel.org/patch/9595727/>`_,
- This bug is introduced in `Linux commmit 39ab9555c241
+ This bug is introduced in `Linux commit 39ab9555c241
<https://patchwork.kernel.org/patch/9554403/>`_,
**Implication**:
@@ -842,7 +842,7 @@ AVX-512 support disabled
drop.
On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
- on information accured from the GCC community defect.
+ on information accrued from the GCC community defect.
**Reason**:
Generated ``AVX-512`` code cause crash:
diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst
index 2a93af3..6448b6c 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -168,7 +168,7 @@ New Features
* The DES CBC algorithm.
* The DES DOCSIS BPI algorithm.
- This change requires version 0.47 of the IPSec Multi-buffer library. For
+ This change requires version 0.47 of the IPsec Multi-buffer library. For
more details see the :doc:`../cryptodevs/aesni_mb` documentation.
* **Updated the OpenSSL PMD.**
@@ -198,7 +198,7 @@ New Features
* **Added the Security Offload Library.**
Added an experimental library - ``rte_security``. This provide security APIs
- for protocols like IPSec using inline ipsec offload to ethernet devices or
+ for protocols like IPsec using inline ipsec offload to ethernet devices or
full protocol offload with lookaside crypto devices.
See the :doc:`../prog_guide/rte_security` section of the DPDK Programmers
@@ -207,11 +207,11 @@ New Features
* **Updated the DPAA2_SEC crypto driver to support rte_security.**
Updated the ``dpaa2_sec`` crypto PMD to support ``rte_security`` lookaside
- protocol offload for IPSec.
+ protocol offload for IPsec.
* **Updated the IXGBE ethernet driver to support rte_security.**
- Updated ixgbe ethernet PMD to support ``rte_security`` inline IPSec offload.
+ Updated ixgbe ethernet PMD to support ``rte_security`` inline IPsec offload.
* **Updated i40e driver to support GTP-C/GTP-U.**
@@ -509,7 +509,7 @@ ABI Changes
* **New parameter added to rte_eth_dev.**
A new parameter ``security_ctx`` has been added to ``rte_eth_dev`` to
- support security operations like IPSec inline.
+ support security operations like IPsec inline.
* **New parameter added to rte_cryptodev.**
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 40a3264..405e706 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -68,7 +68,7 @@ The application accepts a number of command line options:
where:
-* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2)
+* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2)
* ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4)
* ``p ETH_PORT_ID``: ethernet port ID (default = 0)
* ``b BBDEV_ID``: BBDev ID (default = 0)
@@ -87,7 +87,7 @@ issue the command:
$ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
--file-prefix=bbdev -- -e 0x10 -d 0x20
-where, NIC0PCIADDR is the PCI addresse of the Rx port
+where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index 0ec0290..dc7972a 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -49,7 +49,7 @@ these settings is shown below:
./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
-(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application
will print an error message:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index 159bcf7..9070419 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -106,7 +106,7 @@ examples are highlighted below.
(packet arrival) and TX (packet transmission) by adding callbacks to the RX
and TX packet processing functions.
-* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security
+* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security
Gateway application is minimal example of something closer to a real world
example. This is also a good example of an application using the DPDK
Cryptodev framework.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 447a544..4da0fcf 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -113,7 +113,7 @@ Application stages
Initialization
~~~~~~~~~~~~~~
-During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures
+During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures
(i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message
is displayed and the application is terminated.
@@ -185,7 +185,7 @@ Examples
+-----------------------+----------------------+----------------+------------------------------------+
| IP routing | LPM (IPv4) | Forward | 1. Mempool Create |
| | | | 2. Link create |
- | | * Key = IP dest addr | | 3. Pipeline creat |
+ | | * Key = IP dest addr | | 3. Pipeline create |
| | * Offset = 286 | | 4. Pipeline port in/out |
| | * Table size = 4K | | 5. Pipeline table |
| | | | 6. Pipeline port in table |
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 3d784e7..ac118c1 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*.
Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
@@ -124,7 +124,7 @@ Where:
* ``-e``: enables Security Association extended sequence number processing
(available only with librte_ipsec code path).
-* ``-a``: enables Security Association sequence number atomic behaviour
+* ``-a``: enables Security Association sequence number atomic behavior
(available only with librte_ipsec code path).
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
@@ -752,7 +752,7 @@ DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
-It then tries to perform some data transfer using the scheme decribed above.
+It then tries to perform some data transfer using the scheme described above.
usage
~~~~~
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index e2c04ef..ac6ee8a 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in
the L-thread struct.
For legacy and backward compatibility reasons two alternative methods are also
-offered, the first is modelled directly on the pthread get/set specific APIs,
-the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby
+offered, the first is modeled directly on the pthread get/set specific APIs,
+the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby
``PER_LTHREAD`` macros are introduced, in both cases the storage is local to
the L-thread.
diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst
index 2e8e017..d75f7da 100644
--- a/doc/guides/sample_app_ug/qos_metering.rst
+++ b/doc/guides/sample_app_ug/qos_metering.rst
@@ -151,5 +151,5 @@ In this particular case:
* For the rest of the cases, the color is changed to red.
.. note::
- * In color blind mode, first row GREEN colour is only valid.
+ * In color blind mode, first row GREEN color is only valid.
* To drop the packet, policer_table action has to be set to DROP.
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 5f313c5..5aefd8d 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -32,7 +32,7 @@ Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`
-The application is located in the ``$RTE_SDK/app/test-pipline`` directory.
+The application is located in the ``$RTE_SDK/app/test-pipeline`` directory.
Running the Application
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df4d6f9..a71ada6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file.
The vm2vm parameter sets the mode of packet switching between guests in
the host.
-- 0 disables vm2vm, impling that VM's packets will always go to the NIC port.
+- 0 disables vm2vm, implying that VM's packets will always go to the NIC port.
- 1 means a normal mac lookup packet routing.
- 2 means hardware mode packet forwarding between guests, it allows packets
go to the NIC port, hardware L2 switch will determine which guest the
@@ -148,7 +148,7 @@ default value is 15.
**--dequeue-zero-copy**
Dequeue zero copy will be enabled when this option is given. it is worth to
-note that if NIC is binded to driver with iommu enabled, dequeue zero copy
+note that if NIC is bound to driver with iommu enabled, dequeue zero copy
cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu
dma mapping for guest memory.
diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst
index 7ab7d0d..6b9bf62 100644
--- a/doc/guides/sample_app_ug/vhost_scsi.rst
+++ b/doc/guides/sample_app_ug/vhost_scsi.rst
@@ -63,7 +63,7 @@ Vhost_scsi Common Issues
* vhost_scsi can not start with block size 512 Bytes:
- Currently DPDK vhost library was designed for NET device(althrough the APIs
+ Currently DPDK vhost library was designed for NET device(although the APIs
are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced
Disk Device) will enumerate all block device and do some IOs to those block
devices with 512 Bytes sector size. DPDK vhost library can not process such
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e..109d109 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -344,7 +344,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs.
When this parameter is used, the list of cores specified will monitor the ratio
between branch hits and branch misses. A tightly polling PMD thread will have a
- very low branch ratio, so the core frequency will be scaled down to the minimim
+ very low branch ratio, so the core frequency will be scaled down to the minimum
allowed value. When packets are received, the code path will alter, causing the
branch ratio to increase. When the ratio goes above the ratio threshold, the
core frequency will be scaled up to the maximum allowed value.
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The JSON string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -734,7 +734,7 @@ policy down to the host application. These parameters are as follows:
A comma-separated list of cores in the VM that the user wants the host application to
monitor. The list of cores in any vm starts at zero, and these are mapped to the
physical cores by the host application once the policy is passed down.
- Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a
+ Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a
combination of both '1,3,5-7'
.. code-block:: console
@@ -742,7 +742,7 @@ policy down to the host application. These parameters are as follows:
--busy-hours {list of busy hours}
A comma-separated list of hours within which to set the core frequency to maximum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
@@ -750,7 +750,7 @@ policy down to the host application. These parameters are as follows:
--quiet-hours {list of quiet hours}
A comma-separated list of hours within which to set the core frequency to minimum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index fdf6ec7..e7db520 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -381,7 +381,7 @@ The command line options are:
* ``--hot-plug``
- Enable device event monitor mechanism for hot plug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -421,23 +421,23 @@ The command line options are:
* ``--noisy-lkup-memory=N``
- Set the size of the noisy neighbour simulation memory buffer in MB to N.
+ Set the size of the noisy neighbor simulation memory buffer in MB to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads=N``
- Set the number of reads to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of reads to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-writes=N``
- Set the number of writes to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of writes to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads-writes=N``
- Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of r/w accesses to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--no-iova-contig``
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 5d4dc6f..e602df5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -303,7 +303,7 @@ The available information categories are:
This is the default mode.
* ``mac``: Changes the source and the destination Ethernet addresses of packets before forwarding them.
- Default application behaviour is to set source Ethernet address to that of the transmitting interface, and destination
+ Default application behavior is to set source Ethernet address to that of the transmitting interface, and destination
address to a dummy value (set during init). The user may specify a target destination Ethernet address via the 'eth-peer' or
'eth-peers-configfile' command-line options. It is not currently possible to specify a specific source Ethernet address.
@@ -326,7 +326,7 @@ The available information categories are:
* ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is
similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``.
-* ``noisy``: Noisy neighbour simulation.
+* ``noisy``: Noisy neighbor simulation.
Simulate more realistic behavior of a guest machine engaged in receiving
and sending packets performing Virtual Network Function (VNF).
@@ -2289,7 +2289,7 @@ set bonding lacp dedicated_queue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
-when in mode 4 (link-aggregration-802.3ad)::
+when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
@@ -2297,7 +2297,7 @@ when in mode 4 (link-aggregration-802.3ad)::
set bonding agg_mode
~~~~~~~~~~~~~~~~~~~~
-Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+Enable one of the specific aggregators mode when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
@@ -2691,8 +2691,8 @@ where:
* ``shared_shaper_id``: Shared shaper ID to be deleted.
-Set port traffic management hiearchy node private shaper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Set port traffic management hierarchy node private shaper
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
set the port traffic management hierarchy node private shaper::
@@ -2743,7 +2743,7 @@ Delete the WRED profile::
Add port traffic management hierarchy nonleaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add nonleaf node to port traffic management hiearchy::
+Add nonleaf node to port traffic management hierarchy::
testpmd> add port tm nonleaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2758,7 +2758,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``n_sp_priorities``: Number of strict priorities.
@@ -2769,7 +2769,7 @@ where:
Add port traffic management hierarchy leaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add leaf node to port traffic management hiearchy::
+Add leaf node to port traffic management hierarchy::
testpmd> add port tm leaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2784,7 +2784,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``cman_mode``: Congestion management mode to be enabled for this node.
@@ -2796,7 +2796,7 @@ where:
Delete port traffic management hierarchy node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Delete node from port traffic management hiearchy::
+Delete node from port traffic management hierarchy::
testpmd> del port tm node (port_id) (node_id)
@@ -3989,7 +3989,7 @@ This section lists supported actions and their attributes, if any.
- ``dec_ttl``: Performs a decrease TTL value action
-- ``set_ttl``: Set TTL value with specificed value
+- ``set_ttl``: Set TTL value with specified value
- ``ttl_value {unsigned}``: The new TTL value to be set
- ``set_mac_src``: set source MAC address
@@ -4522,7 +4522,7 @@ The following sections show functions to load/unload eBPF based filters.
bpf-load
~~~~~~~~
-Load an eBPF program as a callback for partciular RX/TX queue::
+Load an eBPF program as a callback for particular RX/TX queue::
testpmd> bpf-load rx|tx (portid) (queueid) (load-flags) (bpf-prog-filename)
@@ -4560,7 +4560,7 @@ To load (not JITed) t1.o at TX queue 0, port 0::
bpf-unload
~~~~~~~~~~
-Unload previously loaded eBPF program for partciular RX/TX queue::
+Unload previously loaded eBPF program for particular RX/TX queue::
testpmd> bpf-unload rx|tx (portid) (queueid)
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index c366af4..2fc6544 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -59,7 +59,7 @@ To set on the linearization options add below definition to the
**Step 3: Build the application**
Execute the ``dpdk-setup.sh`` script to build the DPDK library together with the
-``dpdk-test-crypto-perf`` applcation.
+``dpdk-test-crypto-perf`` application.
Initially, the user must select a DPDK target to choose the correct target type
and compiler options to use when building the libraries.
@@ -80,7 +80,7 @@ EAL Options
~~~~~~~~~~~
The following are the EAL command-line options that can be used in conjunction
-with the ``dpdk-test-crypto-perf`` applcation.
+with the ``dpdk-test-crypto-perf`` application.
See the DPDK Getting Started Guides for more information on these options.
* ``-c <COREMASK>`` or ``-l <CORELIST>``
@@ -96,10 +96,10 @@ See the DPDK Getting Started Guides for more information on these options.
Add a virtual device.
-Appication Options
-~~~~~~~~~~~~~~~~~~
+Application Options
+~~~~~~~~~~~~~~~~~~~
-The following are the appication command-line options:
+The following are the application command-line options:
* ``--ptest type``
@@ -338,13 +338,13 @@ Test Vector File
The test vector file is a text file contain information about test vectors.
The file is made of the sections. The first section doesn't have header.
It contain global information used in each test variant vectors -
-typically information about plaintext, ciphertext, cipher key, aut key,
+typically information about plaintext, ciphertext, cipher key, auth key,
initial vector. All other sections begin header.
The sections contain particular information typically digest.
**Format of the file:**
-Each line beginig with sign '#' contain comment and it is ignored by parser::
+Each line beginning with sign '#' contain comment and it is ignored by parser::
# <comment>
@@ -352,16 +352,16 @@ Header line is just name in square bracket::
[<section name>]
-Data line contain information tocken then sign '=' and
+Data line contain information token then sign '=' and
a string of bytes in C byte array format::
- <tocken> = <C byte array>
+ <token> = <C byte array>
-**Tockens list:**
+**Tokens list:**
* ``plaintext``
- Original plaintext to be crypted.
+ Original plaintext to be encrypted.
* ``ciphertext``
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index 6bdf5a8..2ea1b59 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -44,7 +44,7 @@ If no port mask is specified xstats are reset for all DPDK ports.
**-m**: Print DPDK memory information.
**--show-port**
-The show-port parameter displays port level various configuration informationi
+The show-port parameter displays port level various configuration information
associated to RX port queue pair.
**--show-tm**
@@ -56,7 +56,7 @@ The show-crypto parameter displays available cryptodev configurations,
settings and stats per node.
**--show-ring[=name]**
-The show-ring pararmeter display current allocation of all ring with
+The show-ring parameter display current allocation of all ring with
debug information. Specifying the name allows to display details for specific
ring. For invalid or no ring name, whole list is dump.
@@ -76,7 +76,7 @@ Limitations
* When running ``dpdk-procinfo`` with shared library mode, it is required to
pass the same NIC PMD libraries as used for the primary application. Any
- mismatch in PMD library arguments can lead to undefined behaviour and results
+ mismatch in PMD library arguments can lead to undefined behavior and results
affecting primary application too.
* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP.
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 07da35e..7e6a4db 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -139,7 +139,7 @@ There are 6 main test cases that can be executed using testbbdev tool:
* Latency measurement [-c latency]
- Measures the time consumed from the first enqueue until the first
appearance of a dequeued result
- - This measurment represents the full latency of a bbdev operation
+ - This measurement represents the full latency of a bbdev operation
(encode or decode) to execute
* Poll-mode Throughput measurement [-c throughput]
--
2.7.5
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
@ 2019-04-26 15:14 1% John McNamara
2019-04-26 15:14 1% ` John McNamara
0 siblings, 1 reply; 200+ results
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/compressdevs/overview.rst | 2 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/cryptodevs/aesni_mb.rst | 2 +-
doc/guides/cryptodevs/overview.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 2 +-
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/howto/lm_bond_virtio_sriov.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 ++--
doc/guides/howto/rte_flow.rst | 6 ++---
doc/guides/howto/telemetry.rst | 2 +-
.../howto/virtio_user_as_exceptional_path.rst | 8 +++----
doc/guides/nics/af_packet.rst | 4 ++--
doc/guides/nics/atlantic.rst | 2 +-
doc/guides/nics/cxgbe.rst | 4 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/dpaa2.rst | 2 +-
doc/guides/nics/ena.rst | 2 +-
doc/guides/nics/enetc.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 2 +-
doc/guides/nics/ixgbe.rst | 4 ++--
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/mlx5.rst | 4 ++--
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.rst | 2 +-
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/nfp.rst | 4 ++--
doc/guides/nics/sfc_efx.rst | 14 +++++------
doc/guides/nics/szedata2.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/platform/dpaa.rst | 4 ++--
doc/guides/platform/dpaa2.rst | 4 ++--
doc/guides/prog_guide/bbdev.rst | 4 ++--
doc/guides/prog_guide/compressdev.rst | 6 ++---
doc/guides/prog_guide/cryptodev_lib.rst | 12 +++++-----
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/efd_lib.rst | 2 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
.../prog_guide/event_ethernet_rx_adapter.rst | 6 ++---
doc/guides/prog_guide/eventdev.rst | 6 ++---
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++-------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 2 +-
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 ++--
doc/guides/prog_guide/rte_flow.rst | 8 +++----
doc/guides/prog_guide/rte_security.rst | 20 ++++++++--------
doc/guides/prog_guide/traffic_management.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 2 +-
doc/guides/rawdevs/ifpga_rawdev.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 8 +++----
doc/guides/rel_notes/release_17_11.rst | 10 ++++----
doc/guides/sample_app_ug/bbdev_app.rst | 4 ++--
doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 2 +-
doc/guides/sample_app_ug/ip_pipeline.rst | 4 ++--
doc/guides/sample_app_ug/ipsec_secgw.rst | 8 +++----
doc/guides/sample_app_ug/performance_thread.rst | 4 ++--
doc/guides/sample_app_ug/qos_metering.rst | 2 +-
doc/guides/sample_app_ug/test_pipeline.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 4 ++--
doc/guides/sample_app_ug/vhost_scsi.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 10 ++++----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++---------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
71 files changed, 170 insertions(+), 170 deletions(-)
diff --git a/doc/guides/compressdevs/overview.rst b/doc/guides/compressdevs/overview.rst
index 70bbe82..809e4e6 100644
--- a/doc/guides/compressdevs/overview.rst
+++ b/doc/guides/compressdevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
without making any modifications to it (no compression done).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means PMD supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e6..3b2b174 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -8,7 +8,7 @@ Contributing Code to DPDK
This document outlines the guidelines for submitting code to DPDK.
-The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
`How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 8915201..1eff2b0 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -129,7 +129,7 @@ Extra notes
For AES Counter mode (AES-CTR), the library supports two different sizes for Initialization
Vector (IV):
-* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, which internally
+* 12 bytes: used mainly for IPsec, as it requires 12 bytes from the user, which internally
are appended the counter block (4 bytes), which is set to 1 for the first block
(no padding required from the user)
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index 12f342b..a972c79 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
being the operation in-place (input address = output address).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means pmd supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index a754a27..7004ca4 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -165,7 +165,7 @@ operation:
For pure small packet size (64 bytes) traffic however the multi-core mode is not
an optimal solution, as it doesn't give significant per-core performance improvement.
For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
- For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+ For large packets (1.5 kbytes) scheduler shows linear scaling in performance
up to eight cores.
Each worker uses its own slave cryptodev. Only software cryptodevs
are supported. Only the same type of cryptodevs should be used concurrently.
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
index 0262a33..979f6cd 100644
--- a/doc/guides/eventdevs/opdl.rst
+++ b/doc/guides/eventdevs/opdl.rst
@@ -8,7 +8,7 @@ The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
implementation of the eventdev API. It is particularly suited to packet\
processing workloads that have high throughput and low latency requirements.\
All packets follow the same path through the device. The order in which\
-packets follow is determinted by the order in which queues are set up.\
+packets follow is determined by the order in which queues are set up.\
Events are left on the ring until they are transmitted. As a result packets\
do not go out of order
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index afdcad7..04c8b03 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -70,7 +70,7 @@ Credit Quanta
The credit quanta is the number of credits that a port will fetch at a time from
the instance's credit pool. Higher numbers will cause less overhead in the
atomic credit fetch code, however it also reduces the overall number of credits
-in the system faster. A balanced number (eg 32) ensures that only small numbers
+in the system faster. A balanced number (e.g. 32) ensures that only small numbers
of credits are pre-allocated at a time, while also mitigating performance impact
of the atomics.
@@ -100,7 +100,7 @@ feature would be significant.
~~~~~~~~~~~~~~~~~~
The software eventdev does not support creating queues that handle all types of
-traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
+traffic. An eventdev with this capability allows enqueuing Atomic, Ordered and
Parallel traffic to the same queue, but scheduling each of them appropriately.
The reason to not allow Atomic, Ordered and Parallel event types in the
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index ee8ccda..07563b3 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -328,7 +328,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
testpmd> show bonding config 2
testpmd> port attach 0000:00:04.0
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 6ebc10f..ecb7832 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -243,7 +243,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
Virtio traffic is seen at P0 and P1.
@@ -338,7 +338,7 @@ reset_vf_on_212_131.sh
#!/bin/sh
# This script is run on the host 10.237.212.131 to reset SRIOV
- # BDF for Ninatic NIC is 0000:06:00.0
+ # BDF for Niantic NIC is 0000:06:00.0
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
echo 0 > /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 3dcda6c..e197376 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -23,7 +23,7 @@ In this example we will create a simple rule that drops packets whose IPv4
destination equals 192.168.3.2. This code is equivalent to the following
testpmd command (wrapped for clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst is 192.168.3.2 / end actions drop / end
Code
@@ -118,7 +118,7 @@ a mask.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 /
end actions drop / end
@@ -219,7 +219,7 @@ In this example we will create a rule that routes all vlan id 123 to queue 3.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
+ testpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
end actions queue index 3 / end
Code
diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst
index 00f8f7a..e10804d 100644
--- a/doc/guides/howto/telemetry.rst
+++ b/doc/guides/howto/telemetry.rst
@@ -18,7 +18,7 @@ which acts as the client.
In DPDK, applications are used to initialize the ``telemetry``. To view incoming
traffic on featured ports, the application should be run first (ie. after ports
are configured). Once the application is running, the service assurance agent
-(for example the collectd plugin) should be run to begin querying the API.
+(for example the CollectD plugin) should be run to begin querying the API.
A client connects their Service Assurance application to the DPDK application
via a UNIX socket. Once a connection is established, a client can send JSON
diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst
index 4910c12..ec021af 100644
--- a/doc/guides/howto/virtio_user_as_exceptional_path.rst
+++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2016 Intel Corporation.
-.. _virtio_user_as_excpetional_path:
+.. _virtio_user_as_exceptional_path:
Virtio_user as Exceptional Path
===============================
@@ -22,7 +22,7 @@ solution is very promising in:
* Features
vhost-net is born to be a networking solution, which has lots of networking
- related featuers, like multi queue, tso, multi-seg mbuf, etc.
+ related features, like multi queue, tso, multi-seg mbuf, etc.
* Performance
@@ -38,7 +38,7 @@ in :numref:`figure_virtio_user_as_exceptional_path`.
.. figure:: img/virtio_user_as_exceptional_path.*
- Overview of a DPDK app using virtio-user as excpetional path
+ Overview of a DPDK app using virtio-user as exceptional path
Sample Usage
@@ -75,7 +75,7 @@ compiling the kernel and those kernel modules should be inserted.
* ``queues``
- Number of multi-queues. Each qeueue will be served by a kthread. For example:
+ Number of multi-queues. Each queue will be served by a kthread. For example:
.. code-block:: console
diff --git a/doc/guides/nics/af_packet.rst b/doc/guides/nics/af_packet.rst
index 1260bb2..efd6f1c 100644
--- a/doc/guides/nics/af_packet.rst
+++ b/doc/guides/nics/af_packet.rst
@@ -13,13 +13,13 @@ PACKET_MMAP, which provides a mmap'ed ring buffer, shared between user space
and kernel, that's used to send and receive packets. This helps reducing system
calls and the copies needed between user space and Kernel.
-The PACKET_FANOUT_HASH behaviour of AF_PACKET is used for frame reception.
+The PACKET_FANOUT_HASH behavior of AF_PACKET is used for frame reception.
Options and inherent limitations
--------------------------------
The following options can be provided to set up an af_packet port in DPDK.
-Some of these, in turn, will be used to configure the PAKET_MMAP settings.
+Some of these, in turn, will be used to configure the PACKET_MMAP settings.
* ``iface`` - name of the Kernel interface to attach to (required);
* ``qpairs`` - number of Rx and Tx queues (optional, default 1);
diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst
index 22f2410..3f3f294 100644
--- a/doc/guides/nics/atlantic.rst
+++ b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
- Port statistics
- RSS (Receive Side Scaling)
- Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
- MACSEC offload
Experimental API features
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index f3e6115..7a893cc 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -126,7 +126,7 @@ enabling debugging options may affect system performance.
- ``CONFIG_RTE_LIBRTE_CXGBE_TPUT`` (default **y**)
- Toggle behaviour to prefer Throughput or Latency.
+ Toggle behavior to prefer Throughput or Latency.
Runtime Options
~~~~~~~~~~~~~~~
@@ -140,7 +140,7 @@ be passed as part of EAL arguments. For example,
- ``keep_ovlan`` (default **0**)
- Toggle behaviour to keep/strip outer VLAN in Q-in-Q packets. If
+ Toggle behavior to keep/strip outer VLAN in Q-in-Q packets. If
enabled, the outer VLAN tag is preserved in Q-in-Q packets. Otherwise,
the outer VLAN tag is stripped in Q-in-Q packets.
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index fb7bc7d..2243a4a 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -251,7 +251,7 @@ state during application initialization:
automatically be assigned from the these high perf PUSH queues. Any queue
configuration beyond that will be standard Rx queues. The application can
choose to change their number if HW portals are limited.
- The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ The valid values are from '0' to '4'. The values shall be set to '0' if the
application want to use eventdev with DPAA device.
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index d74d8f8..b3b7678 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -379,7 +379,7 @@ active -- Ethernet, crypto, compression, etc.
DPBP based Mempool driver
~~~~~~~~~~~~~~~~~~~~~~~~~
-The DPBP driver is bound to a DPBP objects and provides sevices to
+The DPBP driver is bound to a DPBP objects and provides services to
create a hardware offloaded packet buffer mempool.
DPAA2 NIC Driver
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 80da4b6..d44f3cd 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -189,7 +189,7 @@ Prerequisites
reduces the latency of the packets by pushing the header directly through
the PCI to the device, before the DMA is even triggered. For proper work
kernel PCI driver must support write combining (WC). In mainline version of
- ``igb_uio`` (in DPDK repo) it must be enabled by loding module with
+ ``igb_uio`` (in DPDK repo) it must be enabled by loading module with
``wc_activate=1`` flag (example below). However, mainline's vfio-pci
driver in kernel doesn't have WC support yet (planed to be added).
If vfio-pci used user should be either turn off ENAv2 (to avoid performance
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 2620460..3c896ee 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -76,7 +76,7 @@ Supported ENETC SoCs
Prerequisites
~~~~~~~~~~~~~
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 726a69e..cdb55e0 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -224,7 +224,7 @@ the use of SR-IOV.
passthrough devices do not require libvirt, port profiles, and VM-FEX.
-.. _enic-genic-flow-api:
+.. _enic-generic-flow-api:
Generic Flow API support
------------------------
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c5bf322..d57ddc2 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -495,7 +495,7 @@ Supports adding traffic mirroring rules.
Inline crypto
-------------
-Supports inline crypto processing (eg. inline IPsec). See Security library and PMD documentation for more details.
+Supports inline crypto processing (e.g. inline IPsec). See Security library and PMD documentation for more details.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_SECURITY``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 9680a92..2e9ec79 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -580,7 +580,7 @@ bandwidth setting.
TC TX scheduling mode setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There're 2 TX scheduling modes for TCs, round robin and strict priority mode.
+There are 2 TX scheduling modes for TCs, round robin and strict priority mode.
If a TC is set to strict priority mode, it can consume unlimited bandwidth.
It means if APP has set the max bandwidth for that TC, it comes to no
effect.
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1c294b0..975143f 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -203,8 +203,8 @@ as a workaround.
X550 does not support legacy interrupt mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Desccription
-^^^^^^^^^^^^
+Description
+^^^^^^^^^^^
X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy
interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states
that the Interrupt Status bit is not implemented. The errata is the item #22
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index a66c595..602a06b 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -65,7 +65,7 @@ backend device by default.
PMD arguments
-------------
-``no_request_thread``, by default PMD creates a phtread for each KNI interface
+``no_request_thread``, by default PMD creates a pthread for each KNI interface
to handle Linux network interface control commands, like ``ifconfig kni0 up``
With ``no_request_thread`` option, pthread is not created and control commands
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index aaf1907..f6d7a16 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -83,7 +83,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx4**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx4**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5fa6b62..af1e408 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,7 +168,7 @@ Limitations
- must specify the VXLAN item with tunnel outer parameters.
- must specify the tunnel outer VNI in the VXLAN item.
- must specify the tunnel outer remote (destination) UDP port in the VXLAN item.
- - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed.
+ - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interface, wildcards not allowed.
- must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed.
- must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule.
@@ -216,7 +216,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx5**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx5**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 09e2f2a..bacc013 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -91,7 +91,7 @@ Limitations
chance to start in a sane state.
- MUSDK architecture does not support changing configuration in run time.
- All nessesary configurations should be done before first dev_start().
+ All necessary configurations should be done before first dev_start().
- RX queue start/stop is not supported.
diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 87fabf5..6dbb9a5 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -89,7 +89,7 @@ operations:
.. Note::
- The dpkd-devbind.py script can not be used since it only handles PCI devices.
+ The dpdk-devbind.py script can not be used since it only handles PCI devices.
Prerequisites
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index a7fb963..8df76c0 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -81,7 +81,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They are represented in DPDK as a single port.
-NFB-200G2QL card employs an addon cable which allows to connect it to two
+NFB-200G2QL card employs an add-on cable which allows to connect it to two
physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 09a8529..309fa5d 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -149,8 +149,8 @@ PF multiprocess support
-----------------------
Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary proceses with PF
-ports is limitted to only one.
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
This limitation will be solved in future versions but having basic multiprocess support
is important for allowing development and debugging through the PF using a secondary
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index eb47f25..6d01d05 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -96,7 +96,7 @@ Non-supported Features
The features not yet supported include:
-- Receive queue interupts
+- Receive queue interrupts
- Priority-based flow control
@@ -209,12 +209,12 @@ Validating flow rules depends on the firmware variant.
The :ref:`flow_isolated_mode` is supported.
-Ethernet destinaton individual/group match
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ethernet destination individual/group match
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet item supports I/G matching, if only the corresponding bit is set
-in the mask of destination address. If destinaton address in the spec is
-multicast, it matches all multicast (and broadcast) packets, oherwise it
+in the mask of destination address. If destination address in the spec is
+multicast, it matches all multicast (and broadcast) packets, otherwise it
matches unicast packets that are not filtered by other flow rules.
Exceptions to flow rules
@@ -348,10 +348,10 @@ boolean parameters value.
- ``perf_profile`` [auto|throughput|low-latency] (default **throughput**)
- Choose hardware tunning to be optimized for either throughput or
+ Choose hardware tuning to be optimized for either throughput or
low-latency.
**auto** allows NIC firmware to make a choice based on
- installed licences and firmware variant configured using **sfboot**.
+ installed licenses and firmware variant configured using **sfboot**.
- ``stats_update_period_ms`` [long] (default **1000**)
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index a2092f9..94dba82 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -89,7 +89,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They were historically represented in DPDK as a single port.
-However, the new NFB-200G2QL card employs an addon cable which allows to connect
+However, the new NFB-200G2QL card employs an add-on cable which allows to connect
it to two physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 063bd0b..4b6d77d 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -40,7 +40,7 @@ actual MAC address: ``00:64:74:61:70:[00-FF]``.
--vdev=net_tap0,mac="00:64:74:61:70:11"
The MAC address will have a user value passed as string. The MAC address is in
-format with delimeter ``:``. The string is byte converted to hex and you get
+format with delimiter ``:``. The string is byte converted to hex and you get
the actual MAC address: ``00:64:74:61:70:11``.
It is possible to specify a remote netdevice to capture packets from by adding
diff --git a/doc/guides/platform/dpaa.rst b/doc/guides/platform/dpaa.rst
index 3904871..6005f22 100644
--- a/doc/guides/platform/dpaa.rst
+++ b/doc/guides/platform/dpaa.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA Board Support Package
====================================
-This doc has information about steps to setup QorIq dpaa
+This doc has information about steps to setup QorIQ dpaa
based layerscape platform and information about common offload
hw block drivers of **NXP QorIQ DPAA** SoC family.
@@ -38,7 +38,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA PMD on a DPAA
+There are four main pre-requisites for executing DPAA PMD on a DPAA
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/platform/dpaa2.rst b/doc/guides/platform/dpaa2.rst
index 5a64406..2586af0 100644
--- a/doc/guides/platform/dpaa2.rst
+++ b/doc/guides/platform/dpaa2.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA2 Board Support Package
=====================================
-This doc has information about steps to setup NXP QoriQ DPAA2 platform
+This doc has information about steps to setup NXP QorIQ DPAA2 platform
and information about common offload hw block drivers of
**NXP QorIQ DPAA2** SoC family.
@@ -48,7 +48,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA2 PMD on a DPAA2
+There are four main pre-requisites for executing DPAA2 PMD on a DPAA2
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9de1444..658ffd4 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev device consists of
one or more queues identified by queue IDs. While different devices may have
different capabilities (e.g. support different operation types), all queues on
a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initializations time.
+for only one type of operation and is configured at initialization time.
When an operation is enqueued to a specific queue ID, the result is dequeued
from the same queue ID.
@@ -678,7 +678,7 @@ bbdev framework, by giving a sample code performing a loop-back operation with a
baseband processor capable of transceiving data packets.
The following sample C-like pseudo-code shows the basic steps to encode several
-buffers using (**sw_trubo**) bbdev PMD.
+buffers using (**sw_turbo**) bbdev PMD.
.. code-block:: c
diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst
index ad97037..a06c835 100644
--- a/doc/guides/prog_guide/compressdev.rst
+++ b/doc/guides/prog_guide/compressdev.rst
@@ -17,7 +17,7 @@ Device Creation
Physical compression devices are discovered during the bus probe of the EAL function
which is executed at DPDK initialization, based on their unique device identifier.
-For eg. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
+For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
@@ -379,7 +379,7 @@ using priv_xform would look like:
setup op->m_src and op->m_dst;
}
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, comp_ops, NUM_OPS);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deque = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, NUM_OPS);
} while (num_dqud < num_enqd);
@@ -526,7 +526,7 @@ An example pseudocode to set up and process a stream having NUM_CHUNKS with each
op->src.length = CHUNK_LEN;
op->input_chksum = 0;
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, &op[i], 1);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deqd = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, 1);
} while (num_deqd < num_enqd);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 74a930b..23fa5bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -14,7 +14,7 @@ and AEAD symmetric and asymmetric Crypto operations.
Design Principles
-----------------
-The cryptodev library follows the same basic principles as those used in DPDKs
+The cryptodev library follows the same basic principles as those used in DPDK's
Ethernet Device framework. The Crypto framework provides a generic Crypto device
framework which supports both physical (hardware) and virtual (software) Crypto
devices as well as a generic Crypto API which allows Crypto devices to be
@@ -48,7 +48,7 @@ From the command line using the --vdev EAL option
* If DPDK application requires multiple software crypto PMD devices then required
number of ``--vdev`` with appropriate libraries are to be added.
- * An Application with crypto PMD instaces sharing the same library requires unique ID.
+ * An Application with crypto PMD instances sharing the same library requires unique ID.
Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'``
@@ -396,7 +396,7 @@ Operation Management and Allocation
The cryptodev library provides an API set for managing Crypto operations which
utilize the Mempool Library to allocate operation buffers. Therefore, it ensures
-that the crytpo operation is interleaved optimally across the channels and
+that the crypto operation is interleaved optimally across the channels and
ranks for optimal processing.
A ``rte_crypto_op`` contains a field indicating the pool that it originated from.
When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool.
@@ -602,7 +602,7 @@ Sample code
There are various sample applications that show how to use the cryptodev library,
such as the L2fwd with Crypto sample application (L2fwd-crypto) and
-the IPSec Security Gateway application (ipsec-secgw).
+the IPsec Security Gateway application (ipsec-secgw).
While these applications demonstrate how an application can be created to perform
generic crypto operation, the required complexity hides the basic steps of
@@ -807,7 +807,7 @@ using one of the crypto PMDs available in DPDK.
/*
* Dequeue the crypto operations until all the operations
- * are proccessed in the crypto device.
+ * are processed in the crypto device.
*/
uint16_t num_dequeued_ops, total_num_dequeued_ops = 0;
do {
@@ -886,7 +886,7 @@ the order in which the transforms are passed indicates the order of the chaining
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
-asymmetric crypto xfroms.
+asymmetric crypto xforms.
Each xform defines specific asymmetric crypto algo. Currently supported are:
* RSA
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 96dbf30..74dba4d 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -204,7 +204,7 @@ Creates the following symbol:
Which ``dpdk-pmdinfogen`` scans for. Using this information other relevant
bits of data can be exported from the object file and used to produce a
hardware support description, that ``dpdk-pmdinfogen`` then encodes into a
-json formatted string in the following format:
+JSON formatted string in the following format:
.. code-block:: c
diff --git a/doc/guides/prog_guide/efd_lib.rst b/doc/guides/prog_guide/efd_lib.rst
index cb1a1df..2b355ff 100644
--- a/doc/guides/prog_guide/efd_lib.rst
+++ b/doc/guides/prog_guide/efd_lib.rst
@@ -423,6 +423,6 @@ References
1- EFD is based on collaborative research work between Intel and
Carnegie Mellon University (CMU), interested readers can refer to the paper
-“Scaling Up Clustered Network Appliances with ScaleBricks;” Dong Zhou et al.
+"Scaling Up Clustered Network Appliances with ScaleBricks" Dong Zhou et al.
at SIGCOMM 2015 (`http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p241.pdf`)
for more information.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index fa8afdb..c27f730 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -733,7 +733,7 @@ The most important fields in the structure and how they are used are described b
Malloc heap is a doubly-linked list, where each element keeps track of its
previous and next elements. Due to the fact that hugepage memory can come and
-go, neighbouring malloc elements may not necessarily be adjacent in memory.
+go, neighboring malloc elements may not necessarily be adjacent in memory.
Also, since a malloc element may span multiple pages, its contents may not
necessarily be IOVA-contiguous either - each malloc element is only guaranteed
to be virtually contiguous.
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index e955299..c7dda92 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -162,7 +162,7 @@ The servicing_weight member of struct rte_event_eth_rx_adapter_queue_conf
is applicable when the adapter uses a service core function. The application
has to enable Rx queue interrupts when configuring the ethernet device
using the ``rte_eth_dev_configure()`` function and then use a servicing_weight
-of zero when addding the Rx queue to the adapter.
+of zero when adding the Rx queue to the adapter.
The adapter creates a thread blocked on the interrupt, on an interrupt this
thread enqueues the port id and the queue id to a ring buffer. The adapter
@@ -180,9 +180,9 @@ Rx Callback for SW Rx Adapter
For SW based packet transfers, i.e., when the
``RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT`` is not set in the adapter's
capabilities flags for a particular ethernet device, the service function
-temporarily enqueues mbufs to an event buffer before batch enqueueing these
+temporarily enqueues mbufs to an event buffer before batch enqueuing these
to the event device. If the buffer fills up, the service function stops
-dequeueing packets from the ethernet device. The application may want to
+dequeuing packets from the ethernet device. The application may want to
monitor the buffer fill level and instruct the service function to selectively
enqueue packets to the event device. The application may also use some other
criteria to decide which packets should enter the event device even when
diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
index dcdfeb7..7ea14ba 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -42,7 +42,7 @@ The rte_event structure contains the following metadata fields, which the
application fills in to have the event scheduled as required:
* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
-* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``event_type`` - The source of this event, e.g. RTE_EVENT_TYPE_ETHDEV or CPU.
* ``sub_event_type`` - Distinguishes events inside the application, that have
the same event_type (see above)
* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
@@ -265,7 +265,7 @@ Linking Queues and Ports
The final step is to "wire up" the ports to the queues. After this, the
eventdev is capable of scheduling events, and when cores request work to do,
the correct events are provided to that core. Note that the RX core takes input
-from eg: a NIC so it is not linked to any eventdev queues.
+from e.g.: a NIC so it is not linked to any eventdev queues.
Linking all workers to atomic queues, and the TX core to the single-link queue
can be achieved like this:
@@ -276,7 +276,7 @@ can be achieved like this:
uint8_t tx_port_id = 5;
uint8_t atomic_qs[] = {0, 1};
uint8_t single_link_q = 2;
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
for(int worker_port_id = 1; worker_port_id <= 4; worker_port_id++) {
int links_made = rte_event_port_link(dev_id, worker_port_id, atomic_qs, NULL, 2);
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 84696d4..6fc0888 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -65,7 +65,7 @@ In that mode the library functions perform
- check SQN
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
- check padding data
- remove outer IP header (tunnel mode) / update IP header (transport mode)
@@ -88,7 +88,7 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
- check SQN
- check padding data
@@ -101,10 +101,10 @@ In that mode the library functions perform
- generate SQN and IV
- add outer IP header (tunnel mode) / update IP header (transport mode)
- add ESP header and trailer, padding and IV data
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -113,15 +113,15 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
* for outbound packets:
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ In that mode the library functions perform
* for inbound packets:
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
* for outbound packets:
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 7fcbd93..daf87f4 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -227,7 +227,7 @@ application functions:
``config_promiscusity``:
- Called when the user changes the promiscusity state of the KNI
+ Called when the user changes the promiscuity state of the KNI
interface. For example, when the user runs ``ip link set promisc
[on|off] dev <ifaceX>``. If the user sets this callback function to
NULL, but sets the ``port_id`` field to a value other than -1, a default
diff --git a/doc/guides/prog_guide/metrics_lib.rst b/doc/guides/prog_guide/metrics_lib.rst
index e68e4e7..89bc7d6 100644
--- a/doc/guides/prog_guide/metrics_lib.rst
+++ b/doc/guides/prog_guide/metrics_lib.rst
@@ -25,7 +25,7 @@ individual device. Since the metrics library is self-contained, the only
restriction on port numbers is that they are less than ``RTE_MAX_ETHPORTS``
- there is no requirement for the ports to actually exist.
-Initialising the library
+Initializing the library
------------------------
Before the library can be used, it has to be initialized by calling
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1384fe3..6196d3f 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -273,7 +273,7 @@ will be populated by IPC are as follows:
those peer processes that were active at the time of request, how many have
replied)
* ``msgs`` - pointer to where all of the responses are stored. The order in
- which responses appear is undefined. Whendoing sycnrhonous requests, this
+ which responses appear is undefined. When doing synchronous requests, this
memory must be freed by the requestor after request completes!
For asynchronous requests, a function pointer to the callback function must be
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 5af795c..a36ebef 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -64,7 +64,7 @@ The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
get a wall clock counter in user space. Typically it runs at <= 100MHz.
The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
-clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+clock counter is through the ARMv8 PMU subsystem. The PMU cycle counter runs
at CPU frequency. However, access to the PMU cycle counter from user space is
not enabled by default in the arm64 linux kernel. It is possible to enable
cycle counter for user space access by configuring the PMU from the privileged
@@ -75,7 +75,7 @@ scheme. Application can choose the PMU based implementation with
``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
The example below shows the steps to configure the PMU based cycle counter on
-an armv8 machine.
+an ARMv8 machine.
.. code-block:: console
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 0203f4f..937f52b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2129,7 +2129,7 @@ as defined in the ``rte_flow_action_raw_decap``
This action modifies the payload of matched flows. The data supplied must
be a valid header, either holding layer 2 data in case of removing layer 2
-before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
+before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
tunnel definition starting from layer 2 and moving to the tunnel item itself.
When applied to the original packet the resulting packet must be a
valid packet.
@@ -2279,7 +2279,7 @@ Action: ``DEC_TTL``
Decrease TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_dec_ttl:
@@ -2297,7 +2297,7 @@ Action: ``SET_TTL``
Assigns a new TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_set_ttl:
@@ -2725,7 +2725,7 @@ Caveats
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
-- There is no provision for reentrancy/multi-thread safety, although nothing
+- There is no provision for re-entrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index cb70caa..7d0734a 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -40,7 +40,7 @@ Inline Crypto
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
@@ -48,7 +48,7 @@ Ingress Data path - The packet is decrypted in RX path and relevant
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
arrived. The driver Rx path check the descriptors and and based on the
@@ -111,7 +111,7 @@ Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
@@ -119,7 +119,7 @@ Ingress Data path - The packet is decrypted in the RX path and relevant
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
@@ -132,7 +132,7 @@ to identify the security processing done on the packet.
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
@@ -150,7 +150,7 @@ to cross the MTU size.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
@@ -199,13 +199,13 @@ crypto device.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
@@ -217,7 +217,7 @@ for any protocol header addition.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
@@ -549,7 +549,7 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
struct rte_security_ipsec_sa_options options;
/**< various SA options */
enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
+ /**< IPsec SA Direction - Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< IPsec SA Protocol - AH/ESP */
enum rte_security_ipsec_sa_mode mode;
diff --git a/doc/guides/prog_guide/traffic_management.rst b/doc/guides/prog_guide/traffic_management.rst
index 98ac431..05b34d9 100644
--- a/doc/guides/prog_guide/traffic_management.rst
+++ b/doc/guides/prog_guide/traffic_management.rst
@@ -39,7 +39,7 @@ whether a specific implementation does meet the needs to the user application.
At the TM level, users can get high level idea with the help of various
parameters such as maximum number of nodes, maximum number of hierarchical
levels, maximum number of shapers, maximum number of private shapers, type of
-scheduling algorithm (Strict Priority, Weighted Fair Queueing , etc.), etc.,
+scheduling algorithm (Strict Priority, Weighted Fair Queuing , etc.), etc.,
supported by the implementation.
Likewise, users can query the capability of the TM at the hierarchical level to
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a86c07a..fc3ee43 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -63,7 +63,7 @@ The following is an overview of some key Vhost API functions:
512).
* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enableld).
+ boost could be above 70% (when TSO is enabled).
* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
PMD driver consume the mbuf but not release them timely.
diff --git a/doc/guides/rawdevs/ifpga_rawdev.rst b/doc/guides/rawdevs/ifpga_rawdev.rst
index d400db6..a3d92a6 100644
--- a/doc/guides/rawdevs/ifpga_rawdev.rst
+++ b/doc/guides/rawdevs/ifpga_rawdev.rst
@@ -91,7 +91,7 @@ Run-time parameters
-------------------
This driver is invoked automatically in systems added with Intel FPGA,
-but PR and IFPGA Bus scan is trigged by command line using
+but PR and IFPGA Bus scan is triggered by command line using
``--vdev 'ifpga_rawdev_cfg`` EAL option.
The following device parameters are supported:
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index 358dfa3..276327c 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -676,7 +676,7 @@ igb uio legacy mode can not be used in X710/XL710/XXV710
**Description**:
X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
- bit in the PCI status register. Linux delected them from INTx support table. The related
+ bit in the PCI status register. Linux deleted them from INTx support table. The related
`commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
**Implication**:
@@ -722,9 +722,9 @@ Linux kernel 4.10.0 iommu attribute read error
**Description**:
When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
/sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
- This bug is fixed in `Linux commmit a7fdb6e648fb
+ This bug is fixed in `Linux commit a7fdb6e648fb
<https://patchwork.kernel.org/patch/9595727/>`_,
- This bug is introduced in `Linux commmit 39ab9555c241
+ This bug is introduced in `Linux commit 39ab9555c241
<https://patchwork.kernel.org/patch/9554403/>`_,
**Implication**:
@@ -842,7 +842,7 @@ AVX-512 support disabled
drop.
On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
- on information accured from the GCC community defect.
+ on information accrued from the GCC community defect.
**Reason**:
Generated ``AVX-512`` code cause crash:
diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst
index 2a93af3..6448b6c 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -168,7 +168,7 @@ New Features
* The DES CBC algorithm.
* The DES DOCSIS BPI algorithm.
- This change requires version 0.47 of the IPSec Multi-buffer library. For
+ This change requires version 0.47 of the IPsec Multi-buffer library. For
more details see the :doc:`../cryptodevs/aesni_mb` documentation.
* **Updated the OpenSSL PMD.**
@@ -198,7 +198,7 @@ New Features
* **Added the Security Offload Library.**
Added an experimental library - ``rte_security``. This provide security APIs
- for protocols like IPSec using inline ipsec offload to ethernet devices or
+ for protocols like IPsec using inline ipsec offload to ethernet devices or
full protocol offload with lookaside crypto devices.
See the :doc:`../prog_guide/rte_security` section of the DPDK Programmers
@@ -207,11 +207,11 @@ New Features
* **Updated the DPAA2_SEC crypto driver to support rte_security.**
Updated the ``dpaa2_sec`` crypto PMD to support ``rte_security`` lookaside
- protocol offload for IPSec.
+ protocol offload for IPsec.
* **Updated the IXGBE ethernet driver to support rte_security.**
- Updated ixgbe ethernet PMD to support ``rte_security`` inline IPSec offload.
+ Updated ixgbe ethernet PMD to support ``rte_security`` inline IPsec offload.
* **Updated i40e driver to support GTP-C/GTP-U.**
@@ -509,7 +509,7 @@ ABI Changes
* **New parameter added to rte_eth_dev.**
A new parameter ``security_ctx`` has been added to ``rte_eth_dev`` to
- support security operations like IPSec inline.
+ support security operations like IPsec inline.
* **New parameter added to rte_cryptodev.**
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 40a3264..405e706 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -68,7 +68,7 @@ The application accepts a number of command line options:
where:
-* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2)
+* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2)
* ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4)
* ``p ETH_PORT_ID``: ethernet port ID (default = 0)
* ``b BBDEV_ID``: BBDev ID (default = 0)
@@ -87,7 +87,7 @@ issue the command:
$ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
--file-prefix=bbdev -- -e 0x10 -d 0x20
-where, NIC0PCIADDR is the PCI addresse of the Rx port
+where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index 0ec0290..dc7972a 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -49,7 +49,7 @@ these settings is shown below:
./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
-(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application
will print an error message:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index 159bcf7..9070419 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -106,7 +106,7 @@ examples are highlighted below.
(packet arrival) and TX (packet transmission) by adding callbacks to the RX
and TX packet processing functions.
-* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security
+* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security
Gateway application is minimal example of something closer to a real world
example. This is also a good example of an application using the DPDK
Cryptodev framework.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 447a544..4da0fcf 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -113,7 +113,7 @@ Application stages
Initialization
~~~~~~~~~~~~~~
-During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures
+During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures
(i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message
is displayed and the application is terminated.
@@ -185,7 +185,7 @@ Examples
+-----------------------+----------------------+----------------+------------------------------------+
| IP routing | LPM (IPv4) | Forward | 1. Mempool Create |
| | | | 2. Link create |
- | | * Key = IP dest addr | | 3. Pipeline creat |
+ | | * Key = IP dest addr | | 3. Pipeline create |
| | * Offset = 286 | | 4. Pipeline port in/out |
| | * Table size = 4K | | 5. Pipeline table |
| | | | 6. Pipeline port in table |
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 3d784e7..ac118c1 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*.
Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
@@ -124,7 +124,7 @@ Where:
* ``-e``: enables Security Association extended sequence number processing
(available only with librte_ipsec code path).
-* ``-a``: enables Security Association sequence number atomic behaviour
+* ``-a``: enables Security Association sequence number atomic behavior
(available only with librte_ipsec code path).
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
@@ -752,7 +752,7 @@ DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
-It then tries to perform some data transfer using the scheme decribed above.
+It then tries to perform some data transfer using the scheme described above.
usage
~~~~~
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index e2c04ef..ac6ee8a 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in
the L-thread struct.
For legacy and backward compatibility reasons two alternative methods are also
-offered, the first is modelled directly on the pthread get/set specific APIs,
-the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby
+offered, the first is modeled directly on the pthread get/set specific APIs,
+the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby
``PER_LTHREAD`` macros are introduced, in both cases the storage is local to
the L-thread.
diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst
index 2e8e017..d75f7da 100644
--- a/doc/guides/sample_app_ug/qos_metering.rst
+++ b/doc/guides/sample_app_ug/qos_metering.rst
@@ -151,5 +151,5 @@ In this particular case:
* For the rest of the cases, the color is changed to red.
.. note::
- * In color blind mode, first row GREEN colour is only valid.
+ * In color blind mode, first row GREEN color is only valid.
* To drop the packet, policer_table action has to be set to DROP.
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 5f313c5..5aefd8d 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -32,7 +32,7 @@ Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`
-The application is located in the ``$RTE_SDK/app/test-pipline`` directory.
+The application is located in the ``$RTE_SDK/app/test-pipeline`` directory.
Running the Application
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df4d6f9..a71ada6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file.
The vm2vm parameter sets the mode of packet switching between guests in
the host.
-- 0 disables vm2vm, impling that VM's packets will always go to the NIC port.
+- 0 disables vm2vm, implying that VM's packets will always go to the NIC port.
- 1 means a normal mac lookup packet routing.
- 2 means hardware mode packet forwarding between guests, it allows packets
go to the NIC port, hardware L2 switch will determine which guest the
@@ -148,7 +148,7 @@ default value is 15.
**--dequeue-zero-copy**
Dequeue zero copy will be enabled when this option is given. it is worth to
-note that if NIC is binded to driver with iommu enabled, dequeue zero copy
+note that if NIC is bound to driver with iommu enabled, dequeue zero copy
cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu
dma mapping for guest memory.
diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst
index 7ab7d0d..6b9bf62 100644
--- a/doc/guides/sample_app_ug/vhost_scsi.rst
+++ b/doc/guides/sample_app_ug/vhost_scsi.rst
@@ -63,7 +63,7 @@ Vhost_scsi Common Issues
* vhost_scsi can not start with block size 512 Bytes:
- Currently DPDK vhost library was designed for NET device(althrough the APIs
+ Currently DPDK vhost library was designed for NET device(although the APIs
are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced
Disk Device) will enumerate all block device and do some IOs to those block
devices with 512 Bytes sector size. DPDK vhost library can not process such
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e..109d109 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -344,7 +344,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs.
When this parameter is used, the list of cores specified will monitor the ratio
between branch hits and branch misses. A tightly polling PMD thread will have a
- very low branch ratio, so the core frequency will be scaled down to the minimim
+ very low branch ratio, so the core frequency will be scaled down to the minimum
allowed value. When packets are received, the code path will alter, causing the
branch ratio to increase. When the ratio goes above the ratio threshold, the
core frequency will be scaled up to the maximum allowed value.
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The JSON string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -734,7 +734,7 @@ policy down to the host application. These parameters are as follows:
A comma-separated list of cores in the VM that the user wants the host application to
monitor. The list of cores in any vm starts at zero, and these are mapped to the
physical cores by the host application once the policy is passed down.
- Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a
+ Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a
combination of both '1,3,5-7'
.. code-block:: console
@@ -742,7 +742,7 @@ policy down to the host application. These parameters are as follows:
--busy-hours {list of busy hours}
A comma-separated list of hours within which to set the core frequency to maximum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
@@ -750,7 +750,7 @@ policy down to the host application. These parameters are as follows:
--quiet-hours {list of quiet hours}
A comma-separated list of hours within which to set the core frequency to minimum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index fdf6ec7..e7db520 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -381,7 +381,7 @@ The command line options are:
* ``--hot-plug``
- Enable device event monitor mechanism for hot plug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -421,23 +421,23 @@ The command line options are:
* ``--noisy-lkup-memory=N``
- Set the size of the noisy neighbour simulation memory buffer in MB to N.
+ Set the size of the noisy neighbor simulation memory buffer in MB to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads=N``
- Set the number of reads to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of reads to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-writes=N``
- Set the number of writes to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of writes to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads-writes=N``
- Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of r/w accesses to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--no-iova-contig``
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 5d4dc6f..e602df5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -303,7 +303,7 @@ The available information categories are:
This is the default mode.
* ``mac``: Changes the source and the destination Ethernet addresses of packets before forwarding them.
- Default application behaviour is to set source Ethernet address to that of the transmitting interface, and destination
+ Default application behavior is to set source Ethernet address to that of the transmitting interface, and destination
address to a dummy value (set during init). The user may specify a target destination Ethernet address via the 'eth-peer' or
'eth-peers-configfile' command-line options. It is not currently possible to specify a specific source Ethernet address.
@@ -326,7 +326,7 @@ The available information categories are:
* ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is
similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``.
-* ``noisy``: Noisy neighbour simulation.
+* ``noisy``: Noisy neighbor simulation.
Simulate more realistic behavior of a guest machine engaged in receiving
and sending packets performing Virtual Network Function (VNF).
@@ -2289,7 +2289,7 @@ set bonding lacp dedicated_queue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
-when in mode 4 (link-aggregration-802.3ad)::
+when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
@@ -2297,7 +2297,7 @@ when in mode 4 (link-aggregration-802.3ad)::
set bonding agg_mode
~~~~~~~~~~~~~~~~~~~~
-Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+Enable one of the specific aggregators mode when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
@@ -2691,8 +2691,8 @@ where:
* ``shared_shaper_id``: Shared shaper ID to be deleted.
-Set port traffic management hiearchy node private shaper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Set port traffic management hierarchy node private shaper
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
set the port traffic management hierarchy node private shaper::
@@ -2743,7 +2743,7 @@ Delete the WRED profile::
Add port traffic management hierarchy nonleaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add nonleaf node to port traffic management hiearchy::
+Add nonleaf node to port traffic management hierarchy::
testpmd> add port tm nonleaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2758,7 +2758,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``n_sp_priorities``: Number of strict priorities.
@@ -2769,7 +2769,7 @@ where:
Add port traffic management hierarchy leaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add leaf node to port traffic management hiearchy::
+Add leaf node to port traffic management hierarchy::
testpmd> add port tm leaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2784,7 +2784,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``cman_mode``: Congestion management mode to be enabled for this node.
@@ -2796,7 +2796,7 @@ where:
Delete port traffic management hierarchy node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Delete node from port traffic management hiearchy::
+Delete node from port traffic management hierarchy::
testpmd> del port tm node (port_id) (node_id)
@@ -3989,7 +3989,7 @@ This section lists supported actions and their attributes, if any.
- ``dec_ttl``: Performs a decrease TTL value action
-- ``set_ttl``: Set TTL value with specificed value
+- ``set_ttl``: Set TTL value with specified value
- ``ttl_value {unsigned}``: The new TTL value to be set
- ``set_mac_src``: set source MAC address
@@ -4522,7 +4522,7 @@ The following sections show functions to load/unload eBPF based filters.
bpf-load
~~~~~~~~
-Load an eBPF program as a callback for partciular RX/TX queue::
+Load an eBPF program as a callback for particular RX/TX queue::
testpmd> bpf-load rx|tx (portid) (queueid) (load-flags) (bpf-prog-filename)
@@ -4560,7 +4560,7 @@ To load (not JITed) t1.o at TX queue 0, port 0::
bpf-unload
~~~~~~~~~~
-Unload previously loaded eBPF program for partciular RX/TX queue::
+Unload previously loaded eBPF program for particular RX/TX queue::
testpmd> bpf-unload rx|tx (portid) (queueid)
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index c366af4..2fc6544 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -59,7 +59,7 @@ To set on the linearization options add below definition to the
**Step 3: Build the application**
Execute the ``dpdk-setup.sh`` script to build the DPDK library together with the
-``dpdk-test-crypto-perf`` applcation.
+``dpdk-test-crypto-perf`` application.
Initially, the user must select a DPDK target to choose the correct target type
and compiler options to use when building the libraries.
@@ -80,7 +80,7 @@ EAL Options
~~~~~~~~~~~
The following are the EAL command-line options that can be used in conjunction
-with the ``dpdk-test-crypto-perf`` applcation.
+with the ``dpdk-test-crypto-perf`` application.
See the DPDK Getting Started Guides for more information on these options.
* ``-c <COREMASK>`` or ``-l <CORELIST>``
@@ -96,10 +96,10 @@ See the DPDK Getting Started Guides for more information on these options.
Add a virtual device.
-Appication Options
-~~~~~~~~~~~~~~~~~~
+Application Options
+~~~~~~~~~~~~~~~~~~~
-The following are the appication command-line options:
+The following are the application command-line options:
* ``--ptest type``
@@ -338,13 +338,13 @@ Test Vector File
The test vector file is a text file contain information about test vectors.
The file is made of the sections. The first section doesn't have header.
It contain global information used in each test variant vectors -
-typically information about plaintext, ciphertext, cipher key, aut key,
+typically information about plaintext, ciphertext, cipher key, auth key,
initial vector. All other sections begin header.
The sections contain particular information typically digest.
**Format of the file:**
-Each line beginig with sign '#' contain comment and it is ignored by parser::
+Each line beginning with sign '#' contain comment and it is ignored by parser::
# <comment>
@@ -352,16 +352,16 @@ Header line is just name in square bracket::
[<section name>]
-Data line contain information tocken then sign '=' and
+Data line contain information token then sign '=' and
a string of bytes in C byte array format::
- <tocken> = <C byte array>
+ <token> = <C byte array>
-**Tockens list:**
+**Tokens list:**
* ``plaintext``
- Original plaintext to be crypted.
+ Original plaintext to be encrypted.
* ``ciphertext``
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index 6bdf5a8..2ea1b59 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -44,7 +44,7 @@ If no port mask is specified xstats are reset for all DPDK ports.
**-m**: Print DPDK memory information.
**--show-port**
-The show-port parameter displays port level various configuration informationi
+The show-port parameter displays port level various configuration information
associated to RX port queue pair.
**--show-tm**
@@ -56,7 +56,7 @@ The show-crypto parameter displays available cryptodev configurations,
settings and stats per node.
**--show-ring[=name]**
-The show-ring pararmeter display current allocation of all ring with
+The show-ring parameter display current allocation of all ring with
debug information. Specifying the name allows to display details for specific
ring. For invalid or no ring name, whole list is dump.
@@ -76,7 +76,7 @@ Limitations
* When running ``dpdk-procinfo`` with shared library mode, it is required to
pass the same NIC PMD libraries as used for the primary application. Any
- mismatch in PMD library arguments can lead to undefined behaviour and results
+ mismatch in PMD library arguments can lead to undefined behavior and results
affecting primary application too.
* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP.
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 07da35e..7e6a4db 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -139,7 +139,7 @@ There are 6 main test cases that can be executed using testbbdev tool:
* Latency measurement [-c latency]
- Measures the time consumed from the first enqueue until the first
appearance of a dequeued result
- - This measurment represents the full latency of a bbdev operation
+ - This measurement represents the full latency of a bbdev operation
(encode or decode) to execute
* Poll-mode Throughput measurement [-c throughput]
--
2.7.5
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
@ 2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-24 18:38 UTC (permalink / raw)
To: Ray Kinsella, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, April 23, 2019 7:54 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Stephen Hemminger
> <stephen@networkplumber.org>
> 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; nd <nd@arm.com>
> Subject: Re: [EXT] Re: [dpdk-dev] ABI and inline functions
>
>
>
> 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?
The arm64 integrated SoC would functions as PCIE EP mode as well.
That would means that you will have x86/arm64 server machine and
Integrated NIC controller SoC connected to server over PCIE. The usecase for
this to have packet processing offload from server to EP device to save server cycles.
Where EP device will be treated as FW and internally it runs DPDK as HW
Abstraction library for FW.
>
> Thanks,
>
> Ray K
>
^ permalink raw reply [relevance 4%]
* 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
@ 2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
1 sibling, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-24 18:38 UTC (permalink / raw)
To: Ray Kinsella, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, April 23, 2019 7:54 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Stephen Hemminger
> <stephen@networkplumber.org>
> 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; nd <nd@arm.com>
> Subject: Re: [EXT] Re: [dpdk-dev] ABI and inline functions
>
>
>
> 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?
The arm64 integrated SoC would functions as PCIE EP mode as well.
That would means that you will have x86/arm64 server machine and
Integrated NIC controller SoC connected to server over PCIE. The usecase for
this to have packet processing offload from server to EP device to save server cycles.
Where EP device will be treated as FW and internally it runs DPDK as HW
Abstraction library for FW.
>
> Thanks,
>
> Ray K
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 15:44 4% ` Stephen Hemminger
@ 2019-04-24 15:44 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-24 15:44 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli, dev,
Ananyev, Konstantin, thomas, nd
On Wed, 24 Apr 2019 13:54:51 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
> >
> > 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 was basing my response on your earlier comparisons of DPDK to
> GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
> then these frameworks generally go through much more rigorous
> development/design cycle than DPDK does - DPDK's API design process is
> pretty ad-hoc, while both Java and .NET have various kinds of procedures
> by which things get into the standard library. If we're prepared to do
> that - i'm all for it. What we can't have is stability *and* keep the
> same approach to design/development that we have now.
>
Lets step back a bit. I think some of the basic business rules which
go back to the "Innovators dilemma" are that it is NOT a good idea
to pay too much attention to existing customers. Instead, it is important
to pay attention to the need of the potential customers that could
use your product.
In this case, my argument is that it is important for the DPDK project
to pay more attention to the reasons that new users
do not want to use the project; and existing users do not want to
upgrade. This problem has been repeatedly expressed as:
"DPDK is not stable". The project needs to address that concern
even if it means a 1% drop in performance. Surely that 1% can be
made up by improving other places. Even using link-time-optimization
can give 2 to 5 % back.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 12:54 4% ` Burakov, Anatoly
@ 2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-24 15:44 4% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-24 15:44 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli, dev,
Ananyev, Konstantin, thomas, nd
On Wed, 24 Apr 2019 13:54:51 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
> >
> > 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 was basing my response on your earlier comparisons of DPDK to
> GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
> then these frameworks generally go through much more rigorous
> development/design cycle than DPDK does - DPDK's API design process is
> pretty ad-hoc, while both Java and .NET have various kinds of procedures
> by which things get into the standard library. If we're prepared to do
> that - i'm all for it. What we can't have is stability *and* keep the
> same approach to design/development that we have now.
>
Lets step back a bit. I think some of the basic business rules which
go back to the "Innovators dilemma" are that it is NOT a good idea
to pay too much attention to existing customers. Instead, it is important
to pay attention to the need of the potential customers that could
use your product.
In this case, my argument is that it is important for the DPDK project
to pay more attention to the reasons that new users
do not want to use the project; and existing users do not want to
upgrade. This problem has been repeatedly expressed as:
"DPDK is not stable". The project needs to address that concern
even if it means a 1% drop in performance. Surely that 1% can be
made up by improving other places. Even using link-time-optimization
can give 2 to 5 % back.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:54 4% ` Burakov, Anatoly
@ 2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 15:44 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 12:54 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
>
> 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 was basing my response on your earlier comparisons of DPDK to
GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
then these frameworks generally go through much more rigorous
development/design cycle than DPDK does - DPDK's API design process is
pretty ad-hoc, while both Java and .NET have various kinds of procedures
by which things get into the standard library. If we're prepared to do
that - i'm all for it. What we can't have is stability *and* keep the
same approach to design/development that we have now.
--
Thanks,
Anatoly
^ 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
@ 2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-30 8:52 9% ` Thomas Monjalon
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 12:54 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
>
> 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 was basing my response on your earlier comparisons of DPDK to
GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
then these frameworks generally go through much more rigorous
development/design cycle than DPDK does - DPDK's API design process is
pretty ad-hoc, while both Java and .NET have various kinds of procedures
by which things get into the standard library. If we're prepared to do
that - i'm all for it. What we can't have is stability *and* keep the
same approach to design/development that we have now.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* 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
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-30 8:52 9% ` Thomas Monjalon
2 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
` (2 more replies)
1 sibling, 3 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] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 12:08 4% ` Neil Horman
@ 2019-04-24 12:08 4% ` Neil Horman
2019-05-01 23:47 4% ` Thomas Monjalon
1 sibling, 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-05-01 23:47 4% ` Thomas Monjalon
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2 siblings, 2 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] [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
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
1 sibling, 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
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
1 sibling, 2 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] 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-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
1 sibling, 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
2019-05-03 7:22 0% ` David Marchand
1 sibling, 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 " 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
2019-05-03 7:22 0% ` David Marchand
2019-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2 siblings, 2 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 0/5] make lcore_config internal
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 " 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-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2 siblings, 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-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
` (2 more replies)
0 siblings, 3 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-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
0 siblings, 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)
1 sibling, 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
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%]
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-04-03 15:42 [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
2019-04-04 12:52 ` [dpdk-dev] [dpdk-techboard] " Ray Kinsella
2019-04-04 14:07 ` Burakov, Anatoly
2019-04-07 9:48 ` Thomas Monjalon
2019-04-08 9:04 ` Ray Kinsella
2019-04-08 10:15 ` Burakov, Anatoly
2019-04-08 13:00 ` Ray Kinsella
2019-04-08 13:38 ` Burakov, Anatoly
2019-04-08 13:58 ` David Marchand
2019-04-08 14:02 ` Burakov, Anatoly
2019-04-08 14:38 ` David Marchand
2019-04-08 15:49 ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
2019-04-09 9:42 ` 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-08 18:25 [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 " 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-05-03 7:22 0% ` David Marchand
2019-05-03 7:22 0% ` David Marchand
2019-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-05-02 23:15 0% ` 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-24 18:38 4% ` Jerin Jacob Kollanukkaran
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
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 12:54 4% ` Burakov, Anatoly
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-30 8:52 9% ` Thomas Monjalon
2019-04-30 8:52 9% ` Thomas Monjalon
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-05-01 23:47 4% ` Thomas Monjalon
2019-05-01 23:47 4% ` Thomas Monjalon
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2019-04-25 11:10 [dpdk-dev] [PATCH v2] vhost: support inflight share memory protocol feature Li Lin
2019-04-26 9:40 ` [dpdk-dev] [PATCH v3] " Li Lin
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-29 4:07 0% ` lin li
2019-04-29 4:07 0% ` lin li
2019-04-26 15:14 1% [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
2019-04-26 15:14 1% ` John McNamara
2019-04-28 14:58 4% [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni Arnon Warshavsky
2019-04-28 14:58 4% ` Arnon Warshavsky
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 17:19 4% ` Ferruh Yigit
2019-04-29 17:19 4% ` Ferruh Yigit
2019-05-02 9:33 [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30 Reshma Pattan
2019-05-02 14:13 ` [dpdk-dev] [PATCH v2] mk: report address of packed member as warning Reshma Pattan
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-03 7:56 0% ` Burakov, Anatoly
2019-05-03 7:56 0% ` Burakov, Anatoly
2019-05-03 14:34 [dpdk-dev] [PATCH 1/4] devtools: do not complain when reordering symbols David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
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).