* Re: [dpdk-dev] [PATCH v2] eal: rename state values in rte_lcore_state
@ 2019-04-02 21:07 4% ` Stephen Hemminger
2019-04-02 21:21 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-02 21:07 UTC (permalink / raw)
To: David Marchand; +Cc: dev
On Tue, 2 Apr 2019 23:03:06 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Tue, Apr 2, 2019 at 10:48 PM Stephen Hemminger <
> stephen@networkplumber.org> wrote:
>
> > On Tue, 2 Apr 2019 22:15:40 +0200
> > David Marchand <david.marchand@redhat.com> wrote:
> >
> > > On Tue, Apr 2, 2019 at 5:57 PM Stephen Hemminger <
> > stephen@networkplumber.org>
> > > wrote:
> > >
> > > > C language does not really treat enum's as first class symbols.
> > > > The values in an enum live in a global namespace. That means if
> > > > DPDK defines "RUNNING" it can't be used by another enum in an
> > > > application using DPDK.
> > > >
> > > > To solve this add a prefix "RTE_LCORE_" to the enum values, and
> > > > make them grammatically consistent.
> > > >
> > >
> > > Well, I understand this is not clean, but this patch breaks the API.
> >
> > The lcore state was marked as internal in the header file, code that
> > ignores that is going to have problems. The values are the same.
> >
> > We could defer this to 19.11 (next LTS) since it is cosmetic.
> >
>
> We must announce it before changing.
I disagree, if an API is marked as internal it can be changed at any
time (as long as ABI is maintained).
>
>
> At that time, I am willing to do more work to make lcore_config hidden;
> > ie no inline's to access it.
> >
>
> Ah I was looking at that, to see if we could at least shoot the direct
> accesses by calling the existing API.
> I can see we are missing one wrapper for the cpu id...
>
> And there are quite some odds things in with cpu affinity in dpaa:
> drivers/bus/dpaa/dpaa_bus.c: cpu = lcore_config[lcore].core_id;
> drivers/bus/dpaa/dpaa_bus.c:
> &lcore_config[lcore].cpuset);
> drivers/bus/fslmc/portal/dpaa2_hw_dpio.c: if
> (CPU_ISSET(i, &lcore_config[lcore_id].cpuset)) {
>
>
Drivers have no API/ABI restriction, it is only user code.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] eal: rename state values in rte_lcore_state
2019-04-02 21:07 4% ` Stephen Hemminger
@ 2019-04-02 21:21 0% ` David Marchand
2019-04-02 21:21 0% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-04-02 21:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Apr 2, 2019 at 11:07 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> On Tue, 2 Apr 2019 23:03:06 +0200
> David Marchand <david.marchand@redhat.com> wrote:
>
> > On Tue, Apr 2, 2019 at 10:48 PM Stephen Hemminger <
> > stephen@networkplumber.org> wrote:
> >
> > > On Tue, 2 Apr 2019 22:15:40 +0200
> > > David Marchand <david.marchand@redhat.com> wrote:
>
> > > > Well, I understand this is not clean, but this patch breaks the
> API.
> > >
> > > The lcore state was marked as internal in the header file, code that
> > > ignores that is going to have problems. The values are the same.
> > >
> > > We could defer this to 19.11 (next LTS) since it is cosmetic.
> > >
> >
> > We must announce it before changing.
>
> I disagree, if an API is marked as internal it can be changed at any
> time (as long as ABI is maintained).
>
rte_launch.h is exposed to applications.
And specifically, for rte_eal_get_lcore_state():
/**
* Get the state of the lcore identified by slave_id.
*
* To be executed on the MASTER lcore only.
*
* @param slave_id
* The identifier of the lcore.
* @return
* The state of the lcore.
*/
enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned slave_id);
I don't see where this is marked as internal.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] eal: rename state values in rte_lcore_state
2019-04-02 21:21 0% ` David Marchand
@ 2019-04-02 21:21 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-04-02 21:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Apr 2, 2019 at 11:07 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> On Tue, 2 Apr 2019 23:03:06 +0200
> David Marchand <david.marchand@redhat.com> wrote:
>
> > On Tue, Apr 2, 2019 at 10:48 PM Stephen Hemminger <
> > stephen@networkplumber.org> wrote:
> >
> > > On Tue, 2 Apr 2019 22:15:40 +0200
> > > David Marchand <david.marchand@redhat.com> wrote:
>
> > > > Well, I understand this is not clean, but this patch breaks the
> API.
> > >
> > > The lcore state was marked as internal in the header file, code that
> > > ignores that is going to have problems. The values are the same.
> > >
> > > We could defer this to 19.11 (next LTS) since it is cosmetic.
> > >
> >
> > We must announce it before changing.
>
> I disagree, if an API is marked as internal it can be changed at any
> time (as long as ABI is maintained).
>
rte_launch.h is exposed to applications.
And specifically, for rte_eal_get_lcore_state():
/**
* Get the state of the lcore identified by slave_id.
*
* To be executed on the MASTER lcore only.
*
* @param slave_id
* The identifier of the lcore.
* @return
* The state of the lcore.
*/
enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned slave_id);
I don't see where this is marked as internal.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] EAL lcore config
@ 2019-04-03 3:04 4% Stephen Hemminger
2019-04-03 3:04 4% ` Stephen Hemminger
2019-04-03 9:58 0% ` Burakov, Anatoly
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-03 3:04 UTC (permalink / raw)
To: dev
Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
The data structure for lcore config is a holey mess and changing it would
break the ABI.
I propose that for 19.05 we introduce accessor functions and change all
internal (out side of eal directory) to use those. And add a deprecation notice.
For 19.08, we can mark the data structure as deprecated but keep it
the same. Any thing built from source that hits the global variable
will get a warning. Binaries will still run unmodified.
For 19.11, lcore_config can be moved to eal_private.h where it belongs,
and some simple rearrangements will shrink it and get almost all data
on the same cache line. This breaks ABI but API stays the same as 19.05
After that some of the debris can be cleaned out without affecting
API or ABI in future.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] EAL lcore config
2019-04-03 3:04 4% [dpdk-dev] EAL lcore config Stephen Hemminger
@ 2019-04-03 3:04 4% ` Stephen Hemminger
2019-04-03 9:58 0% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-03 3:04 UTC (permalink / raw)
To: dev
Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
The data structure for lcore config is a holey mess and changing it would
break the ABI.
I propose that for 19.05 we introduce accessor functions and change all
internal (out side of eal directory) to use those. And add a deprecation notice.
For 19.08, we can mark the data structure as deprecated but keep it
the same. Any thing built from source that hits the global variable
will get a warning. Binaries will still run unmodified.
For 19.11, lcore_config can be moved to eal_private.h where it belongs,
and some simple rearrangements will shrink it and get almost all data
on the same cache line. This breaks ABI but API stays the same as 19.05
After that some of the debris can be cleaned out without affecting
API or ABI in future.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] EAL lcore config
2019-04-03 3:04 4% [dpdk-dev] EAL lcore config Stephen Hemminger
2019-04-03 3:04 4% ` Stephen Hemminger
@ 2019-04-03 9:58 0% ` Burakov, Anatoly
2019-04-03 9:58 0% ` Burakov, Anatoly
1 sibling, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-04-03 9:58 UTC (permalink / raw)
To: Stephen Hemminger, dev
On 03-Apr-19 4:04 AM, Stephen Hemminger wrote:
> Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
> The data structure for lcore config is a holey mess and changing it would
> break the ABI.
>
> I propose that for 19.05 we introduce accessor functions and change all
> internal (out side of eal directory) to use those. And add a deprecation notice.
>
> For 19.08, we can mark the data structure as deprecated but keep it
> the same. Any thing built from source that hits the global variable
> will get a warning. Binaries will still run unmodified.
>
> For 19.11, lcore_config can be moved to eal_private.h where it belongs,
> and some simple rearrangements will shrink it and get almost all data
> on the same cache line. This breaks ABI but API stays the same as 19.05
>
> After that some of the debris can be cleaned out without affecting
> API or ABI in future.
>
To be fair, the entire EAL API should receive the same treatment :)
There are a lot of cases where the "reasonable" way to access something
is to use a shared internal structure. I've attempted to fix some of
that on the memory side by introducing a mountain of new API's, but more
work is needed.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] EAL lcore config
2019-04-03 9:58 0% ` Burakov, Anatoly
@ 2019-04-03 9:58 0% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-03 9:58 UTC (permalink / raw)
To: Stephen Hemminger, dev
On 03-Apr-19 4:04 AM, Stephen Hemminger wrote:
> Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
> The data structure for lcore config is a holey mess and changing it would
> break the ABI.
>
> I propose that for 19.05 we introduce accessor functions and change all
> internal (out side of eal directory) to use those. And add a deprecation notice.
>
> For 19.08, we can mark the data structure as deprecated but keep it
> the same. Any thing built from source that hits the global variable
> will get a warning. Binaries will still run unmodified.
>
> For 19.11, lcore_config can be moved to eal_private.h where it belongs,
> and some simple rearrangements will shrink it and get almost all data
> on the same cache line. This breaks ABI but API stays the same as 19.05
>
> After that some of the debris can be cleaned out without affecting
> API or ABI in future.
>
To be fair, the entire EAL API should receive the same treatment :)
There are a lot of cases where the "reasonable" way to access something
is to use a shared internal structure. I've attempted to fix some of
that on the memory side by introducing a mountain of new API's, but more
work is needed.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell
@ 2019-04-03 13:26 1% John McNamara
2019-04-03 13:26 1% ` John McNamara
0 siblings, 1 reply; 200+ results
From: John McNamara @ 2019-04-03 13:26 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
Some notes on this.
It is probably best not to apply this patch until just before the release
since it could potentially create a lot of conflicts. I'll resubmit a v2
prior to the 19.05 release.
The fixes list is below. I didn't include them in the commit message
since I don't think the effort of backporting is worth it.
Fixes: a6531d58b415 ("compressdev: replace mbuf scatter gather flag")
Fixes: 58abf6e77c6b ("doc: add contributors guide")
Fixes: 3728e9ba7739 ("crypto/aesni_mb: support IPSec Multi-buffer lib v0.46")
Fixes: 2717246ecd7d ("cryptodev: replace mbuf scatter gather flag")
Fixes: 02545b6ca29a ("doc: update build instructions for qat PMDs")
Fixes: 4c07e0552f0a ("crypto/scheduler: add multicore scheduling mode")
Fixes: c7aa67f5a9e4 ("doc: add eventdev OPDL PMD guide")
Fixes: 0857b9421138 ("doc: add event device and software eventdev")
Fixes: 206b6ba882cf ("doc: add VF live migration howto with bonded virtio")
Fixes: 6993fe1375c1 ("doc: add VM live migration howto with vhost-user")
Fixes: 3e0ceb9f17ff ("doc: add basic howto for flow API")
Fixes: 6e9270eab112 ("doc: add telemetry how-to")
Fixes: 0ba3870e7559 ("doc: add guide to use virtio-user as exceptional path")
Fixes: 6ef75e405d5a ("doc: add af_packet PMD guide")
Fixes: 3d38e3dcf197 ("net/atlantic: implement Rx path")
Fixes: 6c2809628cd5 ("net/cxgbe: improve latency for slow traffic")
Fixes: cda260a4ac1a ("net/cxgbe: add option to keep outer VLAN tag in QinQ")
Fixes: 0c504f6950b6 ("net/dpaa: support push mode")
Fixes: 846a8305f277 ("doc: add DPAA2 NIC details")
Fixes: 61e093398fbc ("doc: add instructions for WC in ENAv2")
Fixes: 65313f1a822a ("doc: add guide for ENETC PMD")
Fixes: 0543f9d24ae1 ("net/enic: flow API documentation")
Fixes: 13e855a3b996 ("doc: add inline crypto feature")
Fixes: 04c8542f96f7 ("net/i40e: set TC strict priority mode")
Fixes: 621c5c1db2b1 ("doc: add ixgbe known issue with legacy interrrupt")
Fixes: 75e2bc54c018 ("net/kni: add KNI PMD")
Fixes: 2c0dd7b69fb0 ("config: add static linkage of mlx dependency")
Fixes: 0280f2812284 ("doc: add mlx5 E-Switch VXLAN tunnels limitations")
Fixes: 2c0dd7b69fb0 ("config: add static linkage of mlx dependency")
Fixes: 7d6bf6b866b8 ("net/mlx5: add Multi-Packet Rx support")
Fixes: 0ba610ca1d17 ("net/mvpp2: document MTR and TM usage")
Fixes: 4b048f352c01 ("doc: clarify usage of netvsc PMD")
Fixes: ef28aa96e53b ("net/nfp: support multiprocess")
Fixes: c7cb2d7a5f2a ("net/sfc: add device configuration checks")
Fixes: 8cb45c97d396 ("net/sfc: add unknown unicast/multicast match in flow API")
Fixes: c22d3c508e0c ("net/sfc: support parameter to choose performance profile")
Fixes: a5e1231f099b ("net/szedata2: do not affect Ethernet interfaces")
Fixes: bcab6c1d27fa ("net/tap: allow user MAC to be passed as args")
Fixes: ceccf8dc7c3d ("doc: create NXP DPAA platform guide")
Fixes: b84c108742a9 ("doc: create NXP DPAA2 platform guide")
Fixes: 4935e1e9f76e ("bbdev: introduce wireless base band device lib")
Fixes: a584d3bea902 ("doc: add compressdev library guide")
Fixes: 0318c02b57cf ("doc: add cryptodev chapter in prog guide")
Fixes: c149818b0e51 ("doc: add note on multiple crypto vdevs")
Fixes: 0318c02b57cf ("doc: add cryptodev chapter in prog guide")
Fixes: 31850d26850e ("doc: add cryptodev sample code")
Fixes: b9209dc21999 ("doc: add asymmetric crypto in programmer guide")
Fixes: a5d7a3f77ddc ("unify tools naming")
Fixes: 0dd62a01874a ("doc: add EFD library section in programmers guide")
Fixes: b31739328354 ("doc: update guides for memory subsystem")
Fixes: 3810ae435783 ("eventdev: add interrupt driven queues to Rx adapter")
Fixes: c1eaab510dba ("eventdev: add callback for Rx adapter SW transfers")
Fixes: 7358c91ffa85 ("doc: add eventdev library to programmers guide")
Fixes: 50bdac5916d9 ("flow_classify: remove table id parameter from API")
Fixes: fdec9301f52d ("doc: add flow classify guides")
Fixes: 9ef6cb1a1583 ("doc: add IPsec library guide")
Fixes: 89397a01ce4a ("kni: set default carrier state of interface")
Fixes: 349950ddb9c5 ("metrics: add information metrics library")
Fixes: 2ad7ba9a6567 ("bitrate: add bitrate statistics library")
Fixes: 5cd3cac9ed22 ("latency: added new library for latency stats")
Fixes: e22266669e86 ("doc: add IPC guide")
Fixes: 9d5ba88c2d41 ("doc: add ARM profiling methods")
Fixes: 7307cf6333ca ("ethdev: add raw encapsulation action")
Fixes: 6f1c2168bccb ("ethdev: add generic TTL rewrite actions")
Fixes: 40ff8c99ea99 ("doc: add details of security library")
Fixes: e660897d8a0a ("doc: describe traffic management API")
Fixes: 9ba1e744ab65 ("vhost: add a flag to enable dequeue zero copy")
Fixes: ef1e8ede3da5 ("raw/ifpga: add Intel FPGA bus rawdev driver")
Fixes: 86fa6c57a175 ("doc: add known igb_uio issue for i40e")
Fixes: b667029e9096 ("doc: add Linux 4.10.0 known issue in release notes")
Fixes: a32ca9a4ebc1 ("mk: fix scope of disabling AVX512F support")
Fixes: c9b13d944088 ("doc: update release notes for 17.11")
Fixes: 1ffee690eaa1 ("examples/bbdev: add sample app")
Fixes: 1094ca96689c ("doc: add SW eventdev pipeline to sample app guide")
Fixes: fdec9301f52d ("doc: add flow classify guides")
Fixes: bef33b0a9d58 ("doc: add new introduction to sample app guides")
Fixes: 71f2e9ba7d8c ("doc: update IP pipeline application guide")
Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload")
Fixes: 02dc5b7d58c7 ("doc: update ipsec-secgw guide and release notes")
Fixes: 4d1a771bd88d ("doc: add guide for performance-thread example")
Fixes: 331ce43dc564 ("doc: add policer table details for metering application")
Fixes: 474572d2ae5a ("app/pipeline: move from test directory")
Fixes: a971c509a523 ("doc: update vhost sample guide")
Fixes: e3075e969eff ("doc: add driver limitation for vhost dequeue zero copy")
Fixes: db75c7af19bb ("examples/vhost_scsi: introduce a new sample app")
Fixes: 50ac590ff826 ("doc: update VM power manager sample guide")
Fixes: a63504a90f6a ("examples/power: add JSON string handling")
Fixes: 50ac590ff826 ("doc: update VM power manager sample guide")
Fixes: fb73e096110a ("app/testpmd: enable device hotplug monitoring")
Fixes: 3c156061b938 ("app/testpmd: add noisy neighbour forwarding mode")
Fixes: a67857e97ba8 ("doc: clarify usage of testpmd MAC forward mode")
Fixes: 8d9d4c2428be ("app/testpmd: update softnic mode documentation")
Fixes: c4e04283abee ("doc: fix literal block in testpmd guide")
Fixes: 0aeb7077d171 ("doc: add 802.3ad modes in testpmd guide")
Fixes: 5b590fbe09b6 ("app/testpmd: add traffic management forwarding mode")
Fixes: 708d0bcb72c2 ("app/testpmd: add commands to modify TTL")
Fixes: e977e4199a8d ("app/testpmd: add commands to load/unload BPF filters")
Fixes: c6baca7adc94 ("doc: describe new performance test application")
Fixes: 98a7ea332ba3 ("fix typos using codespell utility")
Fixes: c6baca7adc94 ("doc: describe new performance test application")
Fixes: 8a37f37fc243 ("app/procinfo: add --show-port")
Fixes: c13e8984404a ("app/procinfo: add --show-ring")
Fixes: bacf34762ac5 ("doc: update limitations in procinfo guide")
Fixes: 8723590ec603 ("doc: update bbdev test app guide")
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/qat.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 4 +--
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 | 10 ++++----
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.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 | 14 +++++-----
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/flow_classify_lib.rst | 12 ++++-----
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 12 ++++-----
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 +--
doc/guides/prog_guide/rte_flow.rst | 6 ++---
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/flow_classify.rst | 8 +++---
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 | 14 +++++-----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 30 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++--------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
73 files changed, 192 insertions(+), 192 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 47f2ecc..b61802d 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -133,7 +133,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 607e758..dd25b22 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/qat.rst b/doc/guides/cryptodevs/qat.rst
index da9655c..651bf38 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -225,7 +225,7 @@ Dependency on the QAT kernel driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To use QAT an SRIOV-enabled QAT kernel driver is required. The VF
-devices created and initialised by this driver will be used by the QAT PMDs.
+devices created and initialized by this driver will be used by the QAT PMDs.
Instructions for installation are below, but first an explanation of the
relationships between the PF/VF devices and the PMDs visible to
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..8334ba5 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
@@ -61,7 +61,7 @@ Queue Dependencies
As stated the order in which packets travel through queues is static in
nature. They go through the queues in the order the queues are setup at
-initialisation ``rte_event_queue_setup()``. For example if an application
+initialization ``rte_event_queue_setup()``. For example if an application
sets up 3 queues, Q0, Q1, Q2 and has 3 associated ports P0, P1, P2 and
P3 then packets must be
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 80591b1..f6f2c66 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
Configuration Information
^^^^^^^^^^^^^^^^^^^^^^^^^
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 392ab05..a532d08 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 8038bf2..376768d 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -69,7 +69,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 4ad361a..28e3666 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 0200373..3f3226a 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -149,7 +149,7 @@ Limitations
- E-Switch VXLAN decapsulation Flow:
- - can be appiled to PF port only.
+ - can be applied to PF port only.
- must specify VF port action (packet redirection from PF to VF).
- must specify tunnel outer UDP local (destination) port, wildcards not allowed.
- must specify tunnel outer VNI, wildcards not allowed.
@@ -164,7 +164,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.
@@ -212,7 +212,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**)
@@ -319,7 +319,7 @@ Run-time configuration
buffers per a packet, one large buffer is posted in order to receive multiple
packets on the buffer. A MPRQ buffer consists of multiple fixed-size strides
and each stride receives one packet. MPRQ can improve throughput for
- small-packet tarffic.
+ small-packet traffic.
When MPRQ is enabled, max_rx_pkt_len can be larger than the size of
user-provided mbuf even if DEV_RX_OFFLOAD_SCATTER isn't enabled. PMD will
@@ -330,7 +330,7 @@ Run-time configuration
- ``mprq_log_stride_num`` parameter [int]
Log 2 of the number of strides for Multi-Packet Rx queue. Configuring more
- strides can reduce PCIe tarffic further. If configured value is not in the
+ strides can reduce PCIe traffic further. If configured value is not in the
range of device capability, the default value will be set with a warning
message. The default value is 4 which is 16 strides per a buffer, valid only
if ``mprq_en`` is set.
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/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 028c92c..d8512fa 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..dae40fb 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.
@@ -549,7 +549,7 @@ chain.
union {
struct rte_cryptodev_sym_session *session;
- /**< Handle for the initialised session context */
+ /**< Handle for the initialized session context */
struct rte_crypto_sym_xform *xform;
/**< Session-less API Crypto operation parameters */
};
@@ -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 c134636..a8ae214 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -705,7 +705,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/flow_classify_lib.rst b/doc/guides/prog_guide/flow_classify_lib.rst
index f0ed5a1..fbb71f5 100644
--- a/doc/guides/prog_guide/flow_classify_lib.rst
+++ b/doc/guides/prog_guide/flow_classify_lib.rst
@@ -94,7 +94,7 @@ The library has the following API's
* Associated actions (list terminated by the END pattern item).
* @param[out] error
* Perform verbose error reporting if not NULL. Structure
- * initialised in case of error only.
+ * initialized in case of error only.
* @return
* 0 on success, error code otherwise
*/
@@ -120,7 +120,7 @@ The library has the following API's
* returns 1 if rule present already, 0 otherwise.
* @param[out] error
* Perform verbose error reporting if not NULL. Structure
- * initialised in case of error only.
+ * initialized in case of error only.
* @return
* A valid handle in case of success, NULL otherwise.
*/
@@ -175,7 +175,7 @@ Classifier creation
The application creates the ``Classifier`` using the
``rte_flow_classifier_create`` API.
-The ``rte_flow_classify_params`` structure must be initialised by the
+The ``rte_flow_classify_params`` structure must be initialized by the
application before calling the API.
.. code-block:: c
@@ -229,7 +229,7 @@ Adding a table to the Classifier
The application adds a table to the ``Classifier`` using the
``rte_flow_classify_table_create`` API.
-The ``rte_flow_classify_table_params`` structure must be initialised by the
+The ``rte_flow_classify_table_params`` structure must be initialized by the
application before calling the API.
.. code-block:: c
@@ -246,7 +246,7 @@ application before calling the API.
};
To create an ACL table the ``rte_table_acl_params`` structure must be
-initialised and assigned to ``arg_create`` in the
+initialized and assigned to ``arg_create`` in the
``rte_flow_classify_table_params`` structure.
.. code-block:: c
@@ -265,7 +265,7 @@ initialised and assigned to ``arg_create`` in the
struct rte_acl_field_def field_format[RTE_ACL_MAX_FIELDS];
};
-The fields for the ACL rule must also be initialised by the application.
+The fields for the ACL rule must also be initialized by the application.
An ACL table can be added to the ``Classifier`` for each ACL rule, for example
another table could be added for the IPv6 5-tuple rule.
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 992fdf4..1beb8e7 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..f2071f2 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
@@ -169,13 +169,13 @@ following names:
- ``peak_bits_in``: Peak inbound bit-rate
- ``peak_bits_out``: Peak outbound bit-rate
-Once initialised and clocked at the appropriate frequency, these
+Once initialized and clocked at the appropriate frequency, these
statistics can be obtained by querying the metrics library.
Initialization
~~~~~~~~~~~~~~
-Before the library can be used, it has to be initialised by calling
+Before the library can be used, it has to be initialized by calling
``rte_stats_bitrate_create()``, which will return a bit-rate
calculation object. Since the bit-rate library uses the metrics library
to report the calculated statistics, the bit-rate library then needs to
@@ -233,13 +233,13 @@ via the metrics library using the following names:
- ``mac_latency_ns``: Maximum processing latency (nano-seconds)
- ``jitter_ns``: Variance in processing latency (nano-seconds)
-Once initialised and clocked at the appropriate frequency, these
+Once initialized and clocked at the appropriate frequency, these
statistics can be obtained by querying the metrics library.
Initialization
~~~~~~~~~~~~~~
-Before the library can be used, it has to be initialised by calling
+Before the library can be used, it has to be initialized by calling
``rte_latencystats_init()``.
.. code-block:: c
@@ -266,7 +266,7 @@ Library shutdown
~~~~~~~~~~~~~~~~
When finished, ``rte_latencystats_uninit()`` needs to be called to
-de-initialise the latency library.
+de-initialize the latency library.
.. code-block:: c
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..1aec578 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:
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/flow_classify.rst b/doc/guides/sample_app_ug/flow_classify.rst
index a6383b3..1c765a5 100644
--- a/doc/guides/sample_app_ug/flow_classify.rst
+++ b/doc/guides/sample_app_ug/flow_classify.rst
@@ -64,7 +64,7 @@ ACL field definitions for the IPv4 5 tuple rule
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following field definitions are used when creating the ACL table during
-initialisation of the ``Flow Classify`` application..
+initialization of the ``Flow Classify`` application..
.. code-block:: c
@@ -222,13 +222,13 @@ table`` to the flow classifier.
rte_exit(EXIT_FAILURE, "Cannot create classifier\n");
}
- /* initialise ACL table params */
+ /* initialize ACL table params */
table_acl_params.name = "table_acl_ipv4_5tuple";
table_acl_params.n_rule_fields = RTE_DIM(ipv4_defs);
table_acl_params.n_rules = FLOW_CLASSIFY_MAX_RULE_NUM;
memcpy(table_acl_params.field_format, ipv4_defs, sizeof(ipv4_defs));
- /* initialise table create params */
+ /* initialize table create params */
cls_table_params.ops = &rte_table_acl_ops,
cls_table_params.arg_create = &table_acl_params,
cls_table_params.type = RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE;
@@ -240,7 +240,7 @@ table`` to the flow classifier.
rte_exit(EXIT_FAILURE, "Failed to create classifier table\n");
}
-It then reads the ipv4_rules_file.txt file and initialises the parameters for
+It then reads the ipv4_rules_file.txt file and initializes the parameters for
the ``rte_flow_classify_table_entry_add`` API.
This API adds a rule to the ACL table.
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..d7a05b7 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 initialized 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..7d73de3 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -53,8 +53,8 @@ The solution is comprised of two high-level components:
application below for more information on setting the policy values.
- Out-of-band monitoring of workloads via cores hardware event counters:
- The host application can manage power for an application in a virtualised
- OR non-virtualised environment by looking at the event counters of the
+ The host application can manage power for an application in a virtualized
+ OR non-virtualized environment by looking at the event counters of the
cores and taking action based on the branch hit/miss ratio. See the host
application '--core-list' command line parameter below.
@@ -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 b717b8c..eb632e2 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -369,7 +369,7 @@ The commandline options are:
* ``--hot-plug``
- Enable device event monitor machenism for hotplug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -409,21 +409,21 @@ The commandline 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.
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 06c8b2a..8eb39cd 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -302,7 +302,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.
@@ -323,9 +323,9 @@ The available information categories are:
* ``ieee1588``: Demonstrate L2 IEEE1588 V2 PTP timestamping for RX and TX. Requires ``CONFIG_RTE_LIBRTE_IEEE1588=y``.
* ``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``.
+ 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 initialized. 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).
@@ -2286,7 +2286,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)
@@ -2294,7 +2294,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)
@@ -2688,8 +2688,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::
@@ -2740,7 +2740,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) \
@@ -2755,7 +2755,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.
@@ -2766,7 +2766,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) \
@@ -2781,7 +2781,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.
@@ -2793,7 +2793,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)
@@ -3986,7 +3986,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
@@ -4519,7 +4519,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)
@@ -4557,7 +4557,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 f338647..0001a0d 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 v1] doc: fix spelling errors reported by aspell
2019-04-03 13:26 1% [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell John McNamara
@ 2019-04-03 13:26 1% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-04-03 13:26 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
Some notes on this.
It is probably best not to apply this patch until just before the release
since it could potentially create a lot of conflicts. I'll resubmit a v2
prior to the 19.05 release.
The fixes list is below. I didn't include them in the commit message
since I don't think the effort of backporting is worth it.
Fixes: a6531d58b415 ("compressdev: replace mbuf scatter gather flag")
Fixes: 58abf6e77c6b ("doc: add contributors guide")
Fixes: 3728e9ba7739 ("crypto/aesni_mb: support IPSec Multi-buffer lib v0.46")
Fixes: 2717246ecd7d ("cryptodev: replace mbuf scatter gather flag")
Fixes: 02545b6ca29a ("doc: update build instructions for qat PMDs")
Fixes: 4c07e0552f0a ("crypto/scheduler: add multicore scheduling mode")
Fixes: c7aa67f5a9e4 ("doc: add eventdev OPDL PMD guide")
Fixes: 0857b9421138 ("doc: add event device and software eventdev")
Fixes: 206b6ba882cf ("doc: add VF live migration howto with bonded virtio")
Fixes: 6993fe1375c1 ("doc: add VM live migration howto with vhost-user")
Fixes: 3e0ceb9f17ff ("doc: add basic howto for flow API")
Fixes: 6e9270eab112 ("doc: add telemetry how-to")
Fixes: 0ba3870e7559 ("doc: add guide to use virtio-user as exceptional path")
Fixes: 6ef75e405d5a ("doc: add af_packet PMD guide")
Fixes: 3d38e3dcf197 ("net/atlantic: implement Rx path")
Fixes: 6c2809628cd5 ("net/cxgbe: improve latency for slow traffic")
Fixes: cda260a4ac1a ("net/cxgbe: add option to keep outer VLAN tag in QinQ")
Fixes: 0c504f6950b6 ("net/dpaa: support push mode")
Fixes: 846a8305f277 ("doc: add DPAA2 NIC details")
Fixes: 61e093398fbc ("doc: add instructions for WC in ENAv2")
Fixes: 65313f1a822a ("doc: add guide for ENETC PMD")
Fixes: 0543f9d24ae1 ("net/enic: flow API documentation")
Fixes: 13e855a3b996 ("doc: add inline crypto feature")
Fixes: 04c8542f96f7 ("net/i40e: set TC strict priority mode")
Fixes: 621c5c1db2b1 ("doc: add ixgbe known issue with legacy interrrupt")
Fixes: 75e2bc54c018 ("net/kni: add KNI PMD")
Fixes: 2c0dd7b69fb0 ("config: add static linkage of mlx dependency")
Fixes: 0280f2812284 ("doc: add mlx5 E-Switch VXLAN tunnels limitations")
Fixes: 2c0dd7b69fb0 ("config: add static linkage of mlx dependency")
Fixes: 7d6bf6b866b8 ("net/mlx5: add Multi-Packet Rx support")
Fixes: 0ba610ca1d17 ("net/mvpp2: document MTR and TM usage")
Fixes: 4b048f352c01 ("doc: clarify usage of netvsc PMD")
Fixes: ef28aa96e53b ("net/nfp: support multiprocess")
Fixes: c7cb2d7a5f2a ("net/sfc: add device configuration checks")
Fixes: 8cb45c97d396 ("net/sfc: add unknown unicast/multicast match in flow API")
Fixes: c22d3c508e0c ("net/sfc: support parameter to choose performance profile")
Fixes: a5e1231f099b ("net/szedata2: do not affect Ethernet interfaces")
Fixes: bcab6c1d27fa ("net/tap: allow user MAC to be passed as args")
Fixes: ceccf8dc7c3d ("doc: create NXP DPAA platform guide")
Fixes: b84c108742a9 ("doc: create NXP DPAA2 platform guide")
Fixes: 4935e1e9f76e ("bbdev: introduce wireless base band device lib")
Fixes: a584d3bea902 ("doc: add compressdev library guide")
Fixes: 0318c02b57cf ("doc: add cryptodev chapter in prog guide")
Fixes: c149818b0e51 ("doc: add note on multiple crypto vdevs")
Fixes: 0318c02b57cf ("doc: add cryptodev chapter in prog guide")
Fixes: 31850d26850e ("doc: add cryptodev sample code")
Fixes: b9209dc21999 ("doc: add asymmetric crypto in programmer guide")
Fixes: a5d7a3f77ddc ("unify tools naming")
Fixes: 0dd62a01874a ("doc: add EFD library section in programmers guide")
Fixes: b31739328354 ("doc: update guides for memory subsystem")
Fixes: 3810ae435783 ("eventdev: add interrupt driven queues to Rx adapter")
Fixes: c1eaab510dba ("eventdev: add callback for Rx adapter SW transfers")
Fixes: 7358c91ffa85 ("doc: add eventdev library to programmers guide")
Fixes: 50bdac5916d9 ("flow_classify: remove table id parameter from API")
Fixes: fdec9301f52d ("doc: add flow classify guides")
Fixes: 9ef6cb1a1583 ("doc: add IPsec library guide")
Fixes: 89397a01ce4a ("kni: set default carrier state of interface")
Fixes: 349950ddb9c5 ("metrics: add information metrics library")
Fixes: 2ad7ba9a6567 ("bitrate: add bitrate statistics library")
Fixes: 5cd3cac9ed22 ("latency: added new library for latency stats")
Fixes: e22266669e86 ("doc: add IPC guide")
Fixes: 9d5ba88c2d41 ("doc: add ARM profiling methods")
Fixes: 7307cf6333ca ("ethdev: add raw encapsulation action")
Fixes: 6f1c2168bccb ("ethdev: add generic TTL rewrite actions")
Fixes: 40ff8c99ea99 ("doc: add details of security library")
Fixes: e660897d8a0a ("doc: describe traffic management API")
Fixes: 9ba1e744ab65 ("vhost: add a flag to enable dequeue zero copy")
Fixes: ef1e8ede3da5 ("raw/ifpga: add Intel FPGA bus rawdev driver")
Fixes: 86fa6c57a175 ("doc: add known igb_uio issue for i40e")
Fixes: b667029e9096 ("doc: add Linux 4.10.0 known issue in release notes")
Fixes: a32ca9a4ebc1 ("mk: fix scope of disabling AVX512F support")
Fixes: c9b13d944088 ("doc: update release notes for 17.11")
Fixes: 1ffee690eaa1 ("examples/bbdev: add sample app")
Fixes: 1094ca96689c ("doc: add SW eventdev pipeline to sample app guide")
Fixes: fdec9301f52d ("doc: add flow classify guides")
Fixes: bef33b0a9d58 ("doc: add new introduction to sample app guides")
Fixes: 71f2e9ba7d8c ("doc: update IP pipeline application guide")
Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload")
Fixes: 02dc5b7d58c7 ("doc: update ipsec-secgw guide and release notes")
Fixes: 4d1a771bd88d ("doc: add guide for performance-thread example")
Fixes: 331ce43dc564 ("doc: add policer table details for metering application")
Fixes: 474572d2ae5a ("app/pipeline: move from test directory")
Fixes: a971c509a523 ("doc: update vhost sample guide")
Fixes: e3075e969eff ("doc: add driver limitation for vhost dequeue zero copy")
Fixes: db75c7af19bb ("examples/vhost_scsi: introduce a new sample app")
Fixes: 50ac590ff826 ("doc: update VM power manager sample guide")
Fixes: a63504a90f6a ("examples/power: add JSON string handling")
Fixes: 50ac590ff826 ("doc: update VM power manager sample guide")
Fixes: fb73e096110a ("app/testpmd: enable device hotplug monitoring")
Fixes: 3c156061b938 ("app/testpmd: add noisy neighbour forwarding mode")
Fixes: a67857e97ba8 ("doc: clarify usage of testpmd MAC forward mode")
Fixes: 8d9d4c2428be ("app/testpmd: update softnic mode documentation")
Fixes: c4e04283abee ("doc: fix literal block in testpmd guide")
Fixes: 0aeb7077d171 ("doc: add 802.3ad modes in testpmd guide")
Fixes: 5b590fbe09b6 ("app/testpmd: add traffic management forwarding mode")
Fixes: 708d0bcb72c2 ("app/testpmd: add commands to modify TTL")
Fixes: e977e4199a8d ("app/testpmd: add commands to load/unload BPF filters")
Fixes: c6baca7adc94 ("doc: describe new performance test application")
Fixes: 98a7ea332ba3 ("fix typos using codespell utility")
Fixes: c6baca7adc94 ("doc: describe new performance test application")
Fixes: 8a37f37fc243 ("app/procinfo: add --show-port")
Fixes: c13e8984404a ("app/procinfo: add --show-ring")
Fixes: bacf34762ac5 ("doc: update limitations in procinfo guide")
Fixes: 8723590ec603 ("doc: update bbdev test app guide")
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/qat.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 4 +--
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 | 10 ++++----
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.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 | 14 +++++-----
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/flow_classify_lib.rst | 12 ++++-----
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 12 ++++-----
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 +--
doc/guides/prog_guide/rte_flow.rst | 6 ++---
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/flow_classify.rst | 8 +++---
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 | 14 +++++-----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 30 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++--------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
73 files changed, 192 insertions(+), 192 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 47f2ecc..b61802d 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -133,7 +133,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 607e758..dd25b22 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/qat.rst b/doc/guides/cryptodevs/qat.rst
index da9655c..651bf38 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -225,7 +225,7 @@ Dependency on the QAT kernel driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To use QAT an SRIOV-enabled QAT kernel driver is required. The VF
-devices created and initialised by this driver will be used by the QAT PMDs.
+devices created and initialized by this driver will be used by the QAT PMDs.
Instructions for installation are below, but first an explanation of the
relationships between the PF/VF devices and the PMDs visible to
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..8334ba5 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
@@ -61,7 +61,7 @@ Queue Dependencies
As stated the order in which packets travel through queues is static in
nature. They go through the queues in the order the queues are setup at
-initialisation ``rte_event_queue_setup()``. For example if an application
+initialization ``rte_event_queue_setup()``. For example if an application
sets up 3 queues, Q0, Q1, Q2 and has 3 associated ports P0, P1, P2 and
P3 then packets must be
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 80591b1..f6f2c66 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
Configuration Information
^^^^^^^^^^^^^^^^^^^^^^^^^
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 392ab05..a532d08 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 8038bf2..376768d 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -69,7 +69,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 4ad361a..28e3666 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 0200373..3f3226a 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -149,7 +149,7 @@ Limitations
- E-Switch VXLAN decapsulation Flow:
- - can be appiled to PF port only.
+ - can be applied to PF port only.
- must specify VF port action (packet redirection from PF to VF).
- must specify tunnel outer UDP local (destination) port, wildcards not allowed.
- must specify tunnel outer VNI, wildcards not allowed.
@@ -164,7 +164,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.
@@ -212,7 +212,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**)
@@ -319,7 +319,7 @@ Run-time configuration
buffers per a packet, one large buffer is posted in order to receive multiple
packets on the buffer. A MPRQ buffer consists of multiple fixed-size strides
and each stride receives one packet. MPRQ can improve throughput for
- small-packet tarffic.
+ small-packet traffic.
When MPRQ is enabled, max_rx_pkt_len can be larger than the size of
user-provided mbuf even if DEV_RX_OFFLOAD_SCATTER isn't enabled. PMD will
@@ -330,7 +330,7 @@ Run-time configuration
- ``mprq_log_stride_num`` parameter [int]
Log 2 of the number of strides for Multi-Packet Rx queue. Configuring more
- strides can reduce PCIe tarffic further. If configured value is not in the
+ strides can reduce PCIe traffic further. If configured value is not in the
range of device capability, the default value will be set with a warning
message. The default value is 4 which is 16 strides per a buffer, valid only
if ``mprq_en`` is set.
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/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 028c92c..d8512fa 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..dae40fb 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.
@@ -549,7 +549,7 @@ chain.
union {
struct rte_cryptodev_sym_session *session;
- /**< Handle for the initialised session context */
+ /**< Handle for the initialized session context */
struct rte_crypto_sym_xform *xform;
/**< Session-less API Crypto operation parameters */
};
@@ -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 c134636..a8ae214 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -705,7 +705,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/flow_classify_lib.rst b/doc/guides/prog_guide/flow_classify_lib.rst
index f0ed5a1..fbb71f5 100644
--- a/doc/guides/prog_guide/flow_classify_lib.rst
+++ b/doc/guides/prog_guide/flow_classify_lib.rst
@@ -94,7 +94,7 @@ The library has the following API's
* Associated actions (list terminated by the END pattern item).
* @param[out] error
* Perform verbose error reporting if not NULL. Structure
- * initialised in case of error only.
+ * initialized in case of error only.
* @return
* 0 on success, error code otherwise
*/
@@ -120,7 +120,7 @@ The library has the following API's
* returns 1 if rule present already, 0 otherwise.
* @param[out] error
* Perform verbose error reporting if not NULL. Structure
- * initialised in case of error only.
+ * initialized in case of error only.
* @return
* A valid handle in case of success, NULL otherwise.
*/
@@ -175,7 +175,7 @@ Classifier creation
The application creates the ``Classifier`` using the
``rte_flow_classifier_create`` API.
-The ``rte_flow_classify_params`` structure must be initialised by the
+The ``rte_flow_classify_params`` structure must be initialized by the
application before calling the API.
.. code-block:: c
@@ -229,7 +229,7 @@ Adding a table to the Classifier
The application adds a table to the ``Classifier`` using the
``rte_flow_classify_table_create`` API.
-The ``rte_flow_classify_table_params`` structure must be initialised by the
+The ``rte_flow_classify_table_params`` structure must be initialized by the
application before calling the API.
.. code-block:: c
@@ -246,7 +246,7 @@ application before calling the API.
};
To create an ACL table the ``rte_table_acl_params`` structure must be
-initialised and assigned to ``arg_create`` in the
+initialized and assigned to ``arg_create`` in the
``rte_flow_classify_table_params`` structure.
.. code-block:: c
@@ -265,7 +265,7 @@ initialised and assigned to ``arg_create`` in the
struct rte_acl_field_def field_format[RTE_ACL_MAX_FIELDS];
};
-The fields for the ACL rule must also be initialised by the application.
+The fields for the ACL rule must also be initialized by the application.
An ACL table can be added to the ``Classifier`` for each ACL rule, for example
another table could be added for the IPv6 5-tuple rule.
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 992fdf4..1beb8e7 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..f2071f2 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
@@ -169,13 +169,13 @@ following names:
- ``peak_bits_in``: Peak inbound bit-rate
- ``peak_bits_out``: Peak outbound bit-rate
-Once initialised and clocked at the appropriate frequency, these
+Once initialized and clocked at the appropriate frequency, these
statistics can be obtained by querying the metrics library.
Initialization
~~~~~~~~~~~~~~
-Before the library can be used, it has to be initialised by calling
+Before the library can be used, it has to be initialized by calling
``rte_stats_bitrate_create()``, which will return a bit-rate
calculation object. Since the bit-rate library uses the metrics library
to report the calculated statistics, the bit-rate library then needs to
@@ -233,13 +233,13 @@ via the metrics library using the following names:
- ``mac_latency_ns``: Maximum processing latency (nano-seconds)
- ``jitter_ns``: Variance in processing latency (nano-seconds)
-Once initialised and clocked at the appropriate frequency, these
+Once initialized and clocked at the appropriate frequency, these
statistics can be obtained by querying the metrics library.
Initialization
~~~~~~~~~~~~~~
-Before the library can be used, it has to be initialised by calling
+Before the library can be used, it has to be initialized by calling
``rte_latencystats_init()``.
.. code-block:: c
@@ -266,7 +266,7 @@ Library shutdown
~~~~~~~~~~~~~~~~
When finished, ``rte_latencystats_uninit()`` needs to be called to
-de-initialise the latency library.
+de-initialize the latency library.
.. code-block:: c
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..1aec578 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:
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/flow_classify.rst b/doc/guides/sample_app_ug/flow_classify.rst
index a6383b3..1c765a5 100644
--- a/doc/guides/sample_app_ug/flow_classify.rst
+++ b/doc/guides/sample_app_ug/flow_classify.rst
@@ -64,7 +64,7 @@ ACL field definitions for the IPv4 5 tuple rule
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following field definitions are used when creating the ACL table during
-initialisation of the ``Flow Classify`` application..
+initialization of the ``Flow Classify`` application..
.. code-block:: c
@@ -222,13 +222,13 @@ table`` to the flow classifier.
rte_exit(EXIT_FAILURE, "Cannot create classifier\n");
}
- /* initialise ACL table params */
+ /* initialize ACL table params */
table_acl_params.name = "table_acl_ipv4_5tuple";
table_acl_params.n_rule_fields = RTE_DIM(ipv4_defs);
table_acl_params.n_rules = FLOW_CLASSIFY_MAX_RULE_NUM;
memcpy(table_acl_params.field_format, ipv4_defs, sizeof(ipv4_defs));
- /* initialise table create params */
+ /* initialize table create params */
cls_table_params.ops = &rte_table_acl_ops,
cls_table_params.arg_create = &table_acl_params,
cls_table_params.type = RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE;
@@ -240,7 +240,7 @@ table`` to the flow classifier.
rte_exit(EXIT_FAILURE, "Failed to create classifier table\n");
}
-It then reads the ipv4_rules_file.txt file and initialises the parameters for
+It then reads the ipv4_rules_file.txt file and initializes the parameters for
the ``rte_flow_classify_table_entry_add`` API.
This API adds a rule to the ACL table.
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..d7a05b7 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 initialized 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..7d73de3 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -53,8 +53,8 @@ The solution is comprised of two high-level components:
application below for more information on setting the policy values.
- Out-of-band monitoring of workloads via cores hardware event counters:
- The host application can manage power for an application in a virtualised
- OR non-virtualised environment by looking at the event counters of the
+ The host application can manage power for an application in a virtualized
+ OR non-virtualized environment by looking at the event counters of the
cores and taking action based on the branch hit/miss ratio. See the host
application '--core-list' command line parameter below.
@@ -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 b717b8c..eb632e2 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -369,7 +369,7 @@ The commandline options are:
* ``--hot-plug``
- Enable device event monitor machenism for hotplug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -409,21 +409,21 @@ The commandline 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.
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 06c8b2a..8eb39cd 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -302,7 +302,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.
@@ -323,9 +323,9 @@ The available information categories are:
* ``ieee1588``: Demonstrate L2 IEEE1588 V2 PTP timestamping for RX and TX. Requires ``CONFIG_RTE_LIBRTE_IEEE1588=y``.
* ``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``.
+ 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 initialized. 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).
@@ -2286,7 +2286,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)
@@ -2294,7 +2294,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)
@@ -2688,8 +2688,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::
@@ -2740,7 +2740,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) \
@@ -2755,7 +2755,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.
@@ -2766,7 +2766,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) \
@@ -2781,7 +2781,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.
@@ -2793,7 +2793,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)
@@ -3986,7 +3986,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
@@ -4519,7 +4519,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)
@@ -4557,7 +4557,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 f338647..0001a0d 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] DPDK ABI/API Stability
@ 2019-04-03 15:42 9% Ray Kinsella
2019-04-03 15:42 9% ` Ray Kinsella
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Ray Kinsella @ 2019-04-03 15:42 UTC (permalink / raw)
To: dev, Kevin Traynor, techboard
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
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".
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.
ABI Versioning
7. New quarterly releases of DPDK will remain ABI compatible with the
most recent DPDK LTS release.
(e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
8. New DPDK LTS releases will remain ABI compatible with the previous
two DPDK LTS releases.
(e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
8. & 9. will be achieved with ABI symbol versioning.
^ permalink raw reply [relevance 9%]
* [dpdk-dev] DPDK ABI/API Stability
2019-04-03 15:42 9% [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
@ 2019-04-03 15:42 9% ` Ray Kinsella
2019-04-03 19:53 9% ` Luca Boccassi
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-03 15:42 UTC (permalink / raw)
To: dev, Kevin Traynor, techboard
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
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".
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.
ABI Versioning
7. New quarterly releases of DPDK will remain ABI compatible with the
most recent DPDK LTS release.
(e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
8. New DPDK LTS releases will remain ABI compatible with the previous
two DPDK LTS releases.
(e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
8. & 9. will be achieved with ABI symbol versioning.
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v10 0/1] Introduce AF_XDP PMD
@ 2019-04-03 16:59 2% ` Xiaolong Ye
2019-04-03 16:59 2% ` Xiaolong Ye
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
1 sibling, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-04-03 16:59 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 14 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1105 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v10 0/1] Introduce AF_XDP PMD
2019-04-03 16:59 2% ` [dpdk-dev] [PATCH v10 0/1] " Xiaolong Ye
@ 2019-04-03 16:59 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-04-03 16:59 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 14 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1105 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config
@ 2019-04-03 17:16 9% ` Stephen Hemminger
2019-04-03 17:16 9% ` Stephen Hemminger
2019-04-03 17:16 3% ` [dpdk-dev] [RFC 5/5] eal: make lcore_config private Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-03 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 the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 46 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 57 +++++++++++++++++------
3 files changed, 96 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index bdad1ddbeedf..995fbf177b93 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -188,6 +188,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..806204d9f73d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,52 @@
#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 lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+enum rte_lcore_state_t
+rte_lcore_state(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].state;
+}
+
+int
+rte_lcore_return_code(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7477ed2d9550 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,7 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +169,37 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned rte_lcore_to_socket_id(unsigned 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 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 lcore_id);
/**
* Test if an lcore is enabled.
@@ -201,6 +219,17 @@ rte_lcore_is_enabled(unsigned lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
+/**
+ * Get the state of an lcore ID.
+ *
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * the current state of that lcore
+ */
+enum rte_lcore_state_t __rte_experimental
+rte_lcore_state(unsigned lcore_id);
+
/**
* Get the next enabled lcore ID.
*
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [RFC 5/5] eal: make lcore_config private
2019-04-03 17:16 9% ` [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-03 17:16 3% ` Stephen Hemminger
2019-04-03 17:16 3% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-03 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7477ed2d9550..0b157b3e07ce 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..291e56dabc91 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config
2019-04-03 17:16 9% ` [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-03 17:16 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-03 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 the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 46 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 57 +++++++++++++++++------
3 files changed, 96 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index bdad1ddbeedf..995fbf177b93 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -188,6 +188,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..806204d9f73d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,52 @@
#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 lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+enum rte_lcore_state_t
+rte_lcore_state(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].state;
+}
+
+int
+rte_lcore_return_code(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7477ed2d9550 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,7 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +169,37 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned rte_lcore_to_socket_id(unsigned 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 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 lcore_id);
/**
* Test if an lcore is enabled.
@@ -201,6 +219,17 @@ rte_lcore_is_enabled(unsigned lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
+/**
+ * Get the state of an lcore ID.
+ *
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * the current state of that lcore
+ */
+enum rte_lcore_state_t __rte_experimental
+rte_lcore_state(unsigned lcore_id);
+
/**
* Get the next enabled lcore ID.
*
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [RFC 5/5] eal: make lcore_config private
2019-04-03 17:16 3% ` [dpdk-dev] [RFC 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-03 17:16 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-03 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7477ed2d9550..0b157b3e07ce 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..291e56dabc91 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 15:42 9% [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
2019-04-03 15:42 9% ` Ray Kinsella
@ 2019-04-03 19:53 9% ` Luca Boccassi
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-04 9:29 9% ` Burakov, Anatoly
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2019-04-03 19:53 UTC (permalink / raw)
To: Ray Kinsella, dev; +Cc: Christian Ehrhardt, Kevin Traynor, techboard
On Wed, 2019-04-03 at 16:42 +0100, Ray Kinsella 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
>
>
> 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".
> 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
Hello Ray,
It will not come as a surprise to anybody when I say I fully agree with
your analysis :-)
One of the consequences is that this has a tendency to lead to
vendorization - given distros have to move on, and moving on with
application is a lot of work as you pointed out, the easiest solution
is to fork and embed.
If we can't change this, I think at the very least we should be more
explicit in the documentation about how the API is in flux. At least
project managers would be able to know up front that there is a higher-
than-normal long-term opex attached to a DPDK application, even when
all other development stops.
A couple of comments inline below.
> 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.
>From my experience in other projects, if a symbol is available in a
shared library, it will be used. So one thing that's missing from the
current system, which is already good and very helpful, is being able
to completely disable the experimental APIs.
In the past I looked into stopping to export those symbols but the
issue is intra-project dependencies - this can only be done if, for
example, PMDs are not allowed to use an experimental RTE api, unless
it's wrapped in an experimental ifdef (or similar mechanism). This of
course would be a major pain for everybody involved.
> 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.
The switch to Meson will help here, as it's the default.
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with
> the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the
> previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK
> 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
There is also an additional problem with the way we do ABI versioning,
we talked about it many times - ABI bumps need to be "sticky" and
propagate. Eg: if libfoo goes from 1 to 2, all libraries linking to foo
also need a bump. We don't do this, which made necessary the
introduction of the "major abi revision" option, which essentially
makes all the ABI versions match the release version, and which we use
in Debian/Ubuntu.
IMHO we should do a mix of the two - move to always use major version,
but of the LTS as you suggest. So all ABI revisions will be 19.11 until
20.11 is out, and so on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 19:53 9% ` Luca Boccassi
@ 2019-04-03 19:53 9% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-03 19:53 UTC (permalink / raw)
To: Ray Kinsella, dev; +Cc: Christian Ehrhardt, Kevin Traynor, techboard
On Wed, 2019-04-03 at 16:42 +0100, Ray Kinsella 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
>
>
> 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".
> 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
Hello Ray,
It will not come as a surprise to anybody when I say I fully agree with
your analysis :-)
One of the consequences is that this has a tendency to lead to
vendorization - given distros have to move on, and moving on with
application is a lot of work as you pointed out, the easiest solution
is to fork and embed.
If we can't change this, I think at the very least we should be more
explicit in the documentation about how the API is in flux. At least
project managers would be able to know up front that there is a higher-
than-normal long-term opex attached to a DPDK application, even when
all other development stops.
A couple of comments inline below.
> 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.
From my experience in other projects, if a symbol is available in a
shared library, it will be used. So one thing that's missing from the
current system, which is already good and very helpful, is being able
to completely disable the experimental APIs.
In the past I looked into stopping to export those symbols but the
issue is intra-project dependencies - this can only be done if, for
example, PMDs are not allowed to use an experimental RTE api, unless
it's wrapped in an experimental ifdef (or similar mechanism). This of
course would be a major pain for everybody involved.
> 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.
The switch to Meson will help here, as it's the default.
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with
> the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the
> previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK
> 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
There is also an additional problem with the way we do ABI versioning,
we talked about it many times - ABI bumps need to be "sticky" and
propagate. Eg: if libfoo goes from 1 to 2, all libraries linking to foo
also need a bump. We don't do this, which made necessary the
introduction of the "major abi revision" option, which essentially
makes all the ABI versions match the release version, and which we use
in Debian/Ubuntu.
IMHO we should do a mix of the two - move to always use major version,
but of the LTS as you suggest. So all ABI revisions will be 19.11 until
20.11 is out, and so on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-03 16:59 2% ` [dpdk-dev] [PATCH v10 0/1] " Xiaolong Ye
@ 2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 16:13 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Xiaolong Ye @ 2019-04-04 8:51 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v11:
- fix the meson build issue
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 15 +
drivers/net/af_xdp/meson.build | 19 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1104 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
@ 2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 16:13 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-04-04 8:51 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v11:
- fix the meson build issue
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 15 +
drivers/net/af_xdp/meson.build | 19 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1104 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 15:42 9% [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
2019-04-03 15:42 9% ` Ray Kinsella
2019-04-03 19:53 9% ` Luca Boccassi
@ 2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
2019-04-10 5:14 9% ` Honnappa Nagarahalli
4 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 9:29 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard
On 03-Apr-19 4:42 PM, Ray Kinsella 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
>
> 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".
> 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.
Hi Ray,
My somewhat rambly 2 cents :)
While i think some solution has to be found for the situation, we also
have to balance this against speed of development and new features rollout.
For example, let's consider what i am intimately familiar with - the
memory rework. I have made enormous efforts to ensure that pre-18.05 and
post-18.05 remain as ABI/API compatible as possible, but there were a
couple of API calls that were removed, and there couldn't have been any
replacements (these API's were exposing internal structures that
shouldn't have been exposed in the first place), and 18.05 also broke
the ABI compatibility, because there was no way to do it without it
(shared internal structures needed to change in part to support
multiprocess).
So, if i understand your proposal correctly, assuming a 2-year waiting
period for the deprecation of core API's, you would essentially still be
waiting for the memory rework to land for a year more. Moreover, even
*after* it has landed, there was a continuous stream of improvements and
bugfixes, some of which has broke ABI compatibility as well. Some of
them were my fault (as in, i could've foreseen the need for those
changes, but didn't), but others came as a result of people using these
new features in the wild and reporting issues/problems/suggestions - i
am but one man, after all. Plus, you know, there's only 24 hours in a
day, and some stuff takes time to implement :)
Since this rework goes right at the heart of DPDK (arguably there isn't
a more "core" API than memory!), there is no (sane) way in the universe
to 1) keep backwards compatibility for this, or 2) keep two parallel
versions of it. We also need to test all that, and, to be honest, one
validation cycle for a release wouldn't be enough to figure out all of
the kinks and implications of such a case. It was really great that
memory rework has landed in 18.05 and we had time to improve and prepare
it for an 18.11 LTS - i think everyone can say that it's in much better
shape in 18.11 than it was in 18.05, but if we couldn't do an ABI break
here or there, this rate of improvements would have slowed down
significantly.
Now, i understand that this is probably a highly exceptional case, but
i'm sure that maintainers of other parts of DPDK will have their own
examples of similar things happening.
I have no idea what a proper solution would look like. Any "splitting"
of the trees into "experimental" vs. "stable" will end up causing the
same issue - people choose to use stable over experimental because,
well, it's more stable, and new/experimental features don't get tested
as much because no one runs the thing in the first place.
TL;DR we have to be careful not to constrain the pace of
development/bugfixing just for the sake of having a stable API/ABI :)
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 9:29 9% ` Burakov, Anatoly
@ 2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 9:29 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard
On 03-Apr-19 4:42 PM, Ray Kinsella 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
>
> 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".
> 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.
Hi Ray,
My somewhat rambly 2 cents :)
While i think some solution has to be found for the situation, we also
have to balance this against speed of development and new features rollout.
For example, let's consider what i am intimately familiar with - the
memory rework. I have made enormous efforts to ensure that pre-18.05 and
post-18.05 remain as ABI/API compatible as possible, but there were a
couple of API calls that were removed, and there couldn't have been any
replacements (these API's were exposing internal structures that
shouldn't have been exposed in the first place), and 18.05 also broke
the ABI compatibility, because there was no way to do it without it
(shared internal structures needed to change in part to support
multiprocess).
So, if i understand your proposal correctly, assuming a 2-year waiting
period for the deprecation of core API's, you would essentially still be
waiting for the memory rework to land for a year more. Moreover, even
*after* it has landed, there was a continuous stream of improvements and
bugfixes, some of which has broke ABI compatibility as well. Some of
them were my fault (as in, i could've foreseen the need for those
changes, but didn't), but others came as a result of people using these
new features in the wild and reporting issues/problems/suggestions - i
am but one man, after all. Plus, you know, there's only 24 hours in a
day, and some stuff takes time to implement :)
Since this rework goes right at the heart of DPDK (arguably there isn't
a more "core" API than memory!), there is no (sane) way in the universe
to 1) keep backwards compatibility for this, or 2) keep two parallel
versions of it. We also need to test all that, and, to be honest, one
validation cycle for a release wouldn't be enough to figure out all of
the kinks and implications of such a case. It was really great that
memory rework has landed in 18.05 and we had time to improve and prepare
it for an 18.11 LTS - i think everyone can say that it's in much better
shape in 18.11 than it was in 18.05, but if we couldn't do an ABI break
here or there, this rate of improvements would have slowed down
significantly.
Now, i understand that this is probably a highly exceptional case, but
i'm sure that maintainers of other parts of DPDK will have their own
examples of similar things happening.
I have no idea what a proper solution would look like. Any "splitting"
of the trees into "experimental" vs. "stable" will end up causing the
same issue - people choose to use stable over experimental because,
well, it's more stable, and new/experimental features don't get tested
as much because no one runs the thing in the first place.
TL;DR we have to be careful not to constrain the pace of
development/bugfixing just for the sake of having a stable API/ABI :)
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 15:42 9% [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
` (2 preceding siblings ...)
2019-04-04 9:29 9% ` Burakov, Anatoly
@ 2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 13:16 7% ` Ray Kinsella
2019-04-10 5:14 9% ` Honnappa Nagarahalli
4 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 9:47 UTC (permalink / raw)
To: Ray Kinsella, dev, techboard
On 03/04/2019 16:42, Ray Kinsella 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
>
> 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".
> 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.
>
+1
> 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.
>
I don't think they automatically graduate in the current scheme, so it
would seem to be no change to the process.
One thing to note is that in the current experimental API scheme those
API are tagged as deprecated which can cause problems with application
build/CI if they are used. But this is more related to implementation
rather than the classification indicating the API may change. It might
need to change if there was a trend for keeping API as experimental for
a longer time.
> 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.
I agree with the sentiment but it needs real buy in from authors.
Otherwise the burden falls on the reviewer to spend time
exploring/finding a way not to change the API.
> 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.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
@ 2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 13:16 7% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 9:47 UTC (permalink / raw)
To: Ray Kinsella, dev, techboard
On 03/04/2019 16:42, Ray Kinsella 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
>
> 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".
> 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.
>
+1
> 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.
>
I don't think they automatically graduate in the current scheme, so it
would seem to be no change to the process.
One thing to note is that in the current experimental API scheme those
API are tagged as deprecated which can cause problems with application
build/CI if they are used. But this is more related to implementation
rather than the classification indicating the API may change. It might
need to change if there was a trend for keeping API as experimental for
a longer time.
> 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.
I agree with the sentiment but it needs real buy in from authors.
Otherwise the burden falls on the reviewer to spend time
exploring/finding a way not to change the API.
> 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.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 9:29 9% ` Burakov, Anatoly
@ 2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
` (4 more replies)
1 sibling, 5 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 10:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> On 03-Apr-19 4:42 PM, Ray Kinsella 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
> >
> > 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".
> > 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.
>
> Hi Ray,
>
> My somewhat rambly 2 cents :)
>
> While i think some solution has to be found for the situation, we also have
> to balance this against speed of development and new features rollout.
>
> For example, let's consider what i am intimately familiar with - the memory
> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
> remain as ABI/API compatible as possible, but there were a couple of API
> calls that were removed, and there couldn't have been any replacements
> (these API's were exposing internal structures that shouldn't have been
> exposed in the first place), and 18.05 also broke the ABI compatibility,
> because there was no way to do it without it (shared internal structures
> needed to change in part to support multiprocess).
>
> So, if i understand your proposal correctly, assuming a 2-year waiting
> period for the deprecation of core API's, you would essentially still be
> waiting for the memory rework to land for a year more. Moreover, even
> *after* it has landed, there was a continuous stream of improvements and
> bugfixes, some of which has broke ABI compatibility as well. Some of them
> were my fault (as in, i could've foreseen the need for those changes, but
> didn't), but others came as a result of people using these new features in
> the wild and reporting issues/problems/suggestions - i am but one man, after
> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
> time to implement :)
>
> Since this rework goes right at the heart of DPDK (arguably there isn't a
> more "core" API than memory!), there is no (sane) way in the universe to 1)
> keep backwards compatibility for this, or 2) keep two parallel versions of
> it. We also need to test all that, and, to be honest, one validation cycle
> for a release wouldn't be enough to figure out all of the kinks and
> implications of such a case. It was really great that memory rework has
> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
> i think everyone can say that it's in much better shape in 18.11 than it was
> in 18.05, but if we couldn't do an ABI break here or there, this rate of
> improvements would have slowed down significantly.
>
> Now, i understand that this is probably a highly exceptional case, but i'm
> sure that maintainers of other parts of DPDK will have their own examples of
> similar things happening.
>
> I have no idea what a proper solution would look like. Any "splitting" of
> the trees into "experimental" vs. "stable" will end up causing the same
> issue - people choose to use stable over experimental because, well, it's
> more stable, and new/experimental features don't get tested as much because
> no one runs the thing in the first place.
>
> TL;DR we have to be careful not to constrain the pace of
> development/bugfixing just for the sake of having a stable API/ABI :)
>
Actually, I think we *do* need to constrain the pace of development for the
sake of ABI stability. At this stage DPDK has been around for quite a
number of years and so should be considered a fairly mature project - it
should just start acting like it.
Now, in terms of features like the memory rework, that is indeed a case
that there was no alternative other than a massive ABI break. However, for
that rework there was a strong need for improvement in that area that we
can make the case for an ABI break to support it - and it is of a scale
that nothing other than an ABI change would do. For other areas and
examples, I doubt there are many in the last couple of years that are of
that scale.
My thoughts on the matter are:
1. I think we really need to do work to start hiding more of our data
structures - like what Stephen's latest RFC does. This hiding should reduce
the scope for ABI breaks.
2. Once done, I think we should commit to having an ABI break only in the
rarest of circumstances, and only with very large justification. I want us
to get to the point where DPDK releases can immediately be picked up by all
linux distros and rolled out because they are ABI compatible.
I'm not sure I like the idea of planned ABI break releases - that strikes
me as a plan where we end up with the same number of ABI breaks as before,
just balled into one release.
Question for Kevin, Luca and others who look at distro-packaging: is it the
case that each distro will only ship one version of DPDK, or is it possible
that if we have ABI breaks, a distro will provide two copies of DPDK
simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
ABI breaks, and having ABI breaks as a major event reserved only for
massive rework changes, such as major mbuf changes, or new memory layout or
similar.
Regards,
/Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 12:02 4% ` Luca Boccassi
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 10:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> On 03-Apr-19 4:42 PM, Ray Kinsella 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
> >
> > 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".
> > 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.
>
> Hi Ray,
>
> My somewhat rambly 2 cents :)
>
> While i think some solution has to be found for the situation, we also have
> to balance this against speed of development and new features rollout.
>
> For example, let's consider what i am intimately familiar with - the memory
> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
> remain as ABI/API compatible as possible, but there were a couple of API
> calls that were removed, and there couldn't have been any replacements
> (these API's were exposing internal structures that shouldn't have been
> exposed in the first place), and 18.05 also broke the ABI compatibility,
> because there was no way to do it without it (shared internal structures
> needed to change in part to support multiprocess).
>
> So, if i understand your proposal correctly, assuming a 2-year waiting
> period for the deprecation of core API's, you would essentially still be
> waiting for the memory rework to land for a year more. Moreover, even
> *after* it has landed, there was a continuous stream of improvements and
> bugfixes, some of which has broke ABI compatibility as well. Some of them
> were my fault (as in, i could've foreseen the need for those changes, but
> didn't), but others came as a result of people using these new features in
> the wild and reporting issues/problems/suggestions - i am but one man, after
> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
> time to implement :)
>
> Since this rework goes right at the heart of DPDK (arguably there isn't a
> more "core" API than memory!), there is no (sane) way in the universe to 1)
> keep backwards compatibility for this, or 2) keep two parallel versions of
> it. We also need to test all that, and, to be honest, one validation cycle
> for a release wouldn't be enough to figure out all of the kinks and
> implications of such a case. It was really great that memory rework has
> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
> i think everyone can say that it's in much better shape in 18.11 than it was
> in 18.05, but if we couldn't do an ABI break here or there, this rate of
> improvements would have slowed down significantly.
>
> Now, i understand that this is probably a highly exceptional case, but i'm
> sure that maintainers of other parts of DPDK will have their own examples of
> similar things happening.
>
> I have no idea what a proper solution would look like. Any "splitting" of
> the trees into "experimental" vs. "stable" will end up causing the same
> issue - people choose to use stable over experimental because, well, it's
> more stable, and new/experimental features don't get tested as much because
> no one runs the thing in the first place.
>
> TL;DR we have to be careful not to constrain the pace of
> development/bugfixing just for the sake of having a stable API/ABI :)
>
Actually, I think we *do* need to constrain the pace of development for the
sake of ABI stability. At this stage DPDK has been around for quite a
number of years and so should be considered a fairly mature project - it
should just start acting like it.
Now, in terms of features like the memory rework, that is indeed a case
that there was no alternative other than a massive ABI break. However, for
that rework there was a strong need for improvement in that area that we
can make the case for an ABI break to support it - and it is of a scale
that nothing other than an ABI change would do. For other areas and
examples, I doubt there are many in the last couple of years that are of
that scale.
My thoughts on the matter are:
1. I think we really need to do work to start hiding more of our data
structures - like what Stephen's latest RFC does. This hiding should reduce
the scope for ABI breaks.
2. Once done, I think we should commit to having an ABI break only in the
rarest of circumstances, and only with very large justification. I want us
to get to the point where DPDK releases can immediately be picked up by all
linux distros and rolled out because they are ABI compatible.
I'm not sure I like the idea of planned ABI break releases - that strikes
me as a plan where we end up with the same number of ABI breaks as before,
just balled into one release.
Question for Kevin, Luca and others who look at distro-packaging: is it the
case that each distro will only ship one version of DPDK, or is it possible
that if we have ABI breaks, a distro will provide two copies of DPDK
simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
ABI breaks, and having ABI breaks as a major event reserved only for
massive rework changes, such as major mbuf changes, or new memory layout or
similar.
Regards,
/Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
@ 2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
` (2 subsequent siblings)
4 siblings, 2 replies; 200+ results
From: Luca Boccassi @ 2019-04-04 12:02 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > > 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
> > >
> > >
> > > 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".
> > > 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.
> >
> > Hi Ray,
> >
> > My somewhat rambly 2 cents :)
> >
> > While i think some solution has to be found for the situation, we
> > also have
> > to balance this against speed of development and new features
> > rollout.
> >
> > For example, let's consider what i am intimately familiar with -
> > the memory
> > rework. I have made enormous efforts to ensure that pre-18.05 and
> > post-18.05
> > remain as ABI/API compatible as possible, but there were a couple
> > of API
> > calls that were removed, and there couldn't have been any
> > replacements
> > (these API's were exposing internal structures that shouldn't have
> > been
> > exposed in the first place), and 18.05 also broke the ABI
> > compatibility,
> > because there was no way to do it without it (shared internal
> > structures
> > needed to change in part to support multiprocess).
> >
> > So, if i understand your proposal correctly, assuming a 2-year
> > waiting
> > period for the deprecation of core API's, you would essentially
> > still be
> > waiting for the memory rework to land for a year more. Moreover,
> > even
> > *after* it has landed, there was a continuous stream of
> > improvements and
> > bugfixes, some of which has broke ABI compatibility as well. Some
> > of them
> > were my fault (as in, i could've foreseen the need for those
> > changes, but
> > didn't), but others came as a result of people using these new
> > features in
> > the wild and reporting issues/problems/suggestions - i am but one
> > man, after
> > all. Plus, you know, there's only 24 hours in a day, and some stuff
> > takes
> > time to implement :)
> >
> > Since this rework goes right at the heart of DPDK (arguably there
> > isn't a
> > more "core" API than memory!), there is no (sane) way in the
> > universe to 1)
> > keep backwards compatibility for this, or 2) keep two parallel
> > versions of
> > it. We also need to test all that, and, to be honest, one
> > validation cycle
> > for a release wouldn't be enough to figure out all of the kinks and
> > implications of such a case. It was really great that memory rework
> > has
> > landed in 18.05 and we had time to improve and prepare it for an
> > 18.11 LTS -
> > i think everyone can say that it's in much better shape in 18.11
> > than it was
> > in 18.05, but if we couldn't do an ABI break here or there, this
> > rate of
> > improvements would have slowed down significantly.
> >
> > Now, i understand that this is probably a highly exceptional case,
> > but i'm
> > sure that maintainers of other parts of DPDK will have their own
> > examples of
> > similar things happening.
> >
> > I have no idea what a proper solution would look like. Any
> > "splitting" of
> > the trees into "experimental" vs. "stable" will end up causing the
> > same
> > issue - people choose to use stable over experimental because,
> > well, it's
> > more stable, and new/experimental features don't get tested as much
> > because
> > no one runs the thing in the first place.
> >
> > TL;DR we have to be careful not to constrain the pace of
> > development/bugfixing just for the sake of having a stable API/ABI
> > :)
> >
>
> Actually, I think we *do* need to constrain the pace of development
> for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project -
> it
> should just start acting like it.
>
> Now, in terms of features like the memory rework, that is indeed a
> case
> that there was no alternative other than a massive ABI break.
> However, for
> that rework there was a strong need for improvement in that area that
> we
> can make the case for an ABI break to support it - and it is of a
> scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are
> of
> that scale.
Fully agree.
It's normal for new project, big and small, to start without a
stability promise as development ramps up, and then steer toward
stability as the user base grows. Sometimes the switch is made explicit
by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
I don't think we crossed that boundary yet in this project, and I
believe that's the main question Ray was trying to raise: has the time
finally come for DPDK to do this phase shift?
Of course it comes with a price for all developers, and that's again
common.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should
> reduce
> the scope for ABI breaks.
Yes, I'm a big fan of accessors and opaque structs.
> 2. Once done, I think we should commit to having an ABI break only in
> the
> rarest of circumstances, and only with very large justification. I
> want us
> to get to the point where DPDK releases can immediately be picked up
> by all
> linux distros and rolled out because they are ABI compatible.
>
> I'm not sure I like the idea of planned ABI break releases - that
> strikes
> me as a plan where we end up with the same number of ABI breaks as
> before,
> just balled into one release.
I think that was intended as a compromise, especially as we move from
one model to the other, and more of a "if a breakage has to happen, it
must be in the X release" rather than "let's always break in the X
release" :-)
> Question for Kevin, Luca and others who look at distro-packaging: is
> it the
> case that each distro will only ship one version of DPDK, or is it
> possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
We can ship multiple versions, although it's more work so there should
be a good reason to do it. At the moment in Debian and Ubuntu we don't,
and we tend to ship whatever the latest LTS version is at the distro
freeze milestone - for example Debian 10 which will be released soon
(TM) will have 18.11.0.
> So, in short, I'm generally in favour of a zero-tolerance approach
> for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory
> layout or
> similar.
>
> Regards,
> /Bruce
>
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:02 4% ` Luca Boccassi
@ 2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 13:05 7% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-04 12:02 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > > 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
> > >
> > >
> > > 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".
> > > 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.
> >
> > Hi Ray,
> >
> > My somewhat rambly 2 cents :)
> >
> > While i think some solution has to be found for the situation, we
> > also have
> > to balance this against speed of development and new features
> > rollout.
> >
> > For example, let's consider what i am intimately familiar with -
> > the memory
> > rework. I have made enormous efforts to ensure that pre-18.05 and
> > post-18.05
> > remain as ABI/API compatible as possible, but there were a couple
> > of API
> > calls that were removed, and there couldn't have been any
> > replacements
> > (these API's were exposing internal structures that shouldn't have
> > been
> > exposed in the first place), and 18.05 also broke the ABI
> > compatibility,
> > because there was no way to do it without it (shared internal
> > structures
> > needed to change in part to support multiprocess).
> >
> > So, if i understand your proposal correctly, assuming a 2-year
> > waiting
> > period for the deprecation of core API's, you would essentially
> > still be
> > waiting for the memory rework to land for a year more. Moreover,
> > even
> > *after* it has landed, there was a continuous stream of
> > improvements and
> > bugfixes, some of which has broke ABI compatibility as well. Some
> > of them
> > were my fault (as in, i could've foreseen the need for those
> > changes, but
> > didn't), but others came as a result of people using these new
> > features in
> > the wild and reporting issues/problems/suggestions - i am but one
> > man, after
> > all. Plus, you know, there's only 24 hours in a day, and some stuff
> > takes
> > time to implement :)
> >
> > Since this rework goes right at the heart of DPDK (arguably there
> > isn't a
> > more "core" API than memory!), there is no (sane) way in the
> > universe to 1)
> > keep backwards compatibility for this, or 2) keep two parallel
> > versions of
> > it. We also need to test all that, and, to be honest, one
> > validation cycle
> > for a release wouldn't be enough to figure out all of the kinks and
> > implications of such a case. It was really great that memory rework
> > has
> > landed in 18.05 and we had time to improve and prepare it for an
> > 18.11 LTS -
> > i think everyone can say that it's in much better shape in 18.11
> > than it was
> > in 18.05, but if we couldn't do an ABI break here or there, this
> > rate of
> > improvements would have slowed down significantly.
> >
> > Now, i understand that this is probably a highly exceptional case,
> > but i'm
> > sure that maintainers of other parts of DPDK will have their own
> > examples of
> > similar things happening.
> >
> > I have no idea what a proper solution would look like. Any
> > "splitting" of
> > the trees into "experimental" vs. "stable" will end up causing the
> > same
> > issue - people choose to use stable over experimental because,
> > well, it's
> > more stable, and new/experimental features don't get tested as much
> > because
> > no one runs the thing in the first place.
> >
> > TL;DR we have to be careful not to constrain the pace of
> > development/bugfixing just for the sake of having a stable API/ABI
> > :)
> >
>
> Actually, I think we *do* need to constrain the pace of development
> for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project -
> it
> should just start acting like it.
>
> Now, in terms of features like the memory rework, that is indeed a
> case
> that there was no alternative other than a massive ABI break.
> However, for
> that rework there was a strong need for improvement in that area that
> we
> can make the case for an ABI break to support it - and it is of a
> scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are
> of
> that scale.
Fully agree.
It's normal for new project, big and small, to start without a
stability promise as development ramps up, and then steer toward
stability as the user base grows. Sometimes the switch is made explicit
by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
I don't think we crossed that boundary yet in this project, and I
believe that's the main question Ray was trying to raise: has the time
finally come for DPDK to do this phase shift?
Of course it comes with a price for all developers, and that's again
common.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should
> reduce
> the scope for ABI breaks.
Yes, I'm a big fan of accessors and opaque structs.
> 2. Once done, I think we should commit to having an ABI break only in
> the
> rarest of circumstances, and only with very large justification. I
> want us
> to get to the point where DPDK releases can immediately be picked up
> by all
> linux distros and rolled out because they are ABI compatible.
>
> I'm not sure I like the idea of planned ABI break releases - that
> strikes
> me as a plan where we end up with the same number of ABI breaks as
> before,
> just balled into one release.
I think that was intended as a compromise, especially as we move from
one model to the other, and more of a "if a breakage has to happen, it
must be in the X release" rather than "let's always break in the X
release" :-)
> Question for Kevin, Luca and others who look at distro-packaging: is
> it the
> case that each distro will only ship one version of DPDK, or is it
> possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
We can ship multiple versions, although it's more work so there should
be a good reason to do it. At the moment in Debian and Ubuntu we don't,
and we tend to ship whatever the latest LTS version is at the distro
freeze milestone - for example Debian 10 which will be released soon
(TM) will have 18.11.0.
> So, in short, I'm generally in favour of a zero-tolerance approach
> for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory
> layout or
> similar.
>
> Regards,
> /Bruce
>
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 12:02 4% ` Luca Boccassi
@ 2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:56 7% ` Kevin Traynor
4 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 12:52 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: dev, Kevin Traynor, techboard
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:
>>> Hi folks,
>>>
[SNIP]
>>
>> Hi Ray,
>>
>> My somewhat rambly 2 cents :)
>>
>> While i think some solution has to be found for the situation, we also have
>> to balance this against speed of development and new features rollout.
>>
>> For example, let's consider what i am intimately familiar with - the memory
>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>> remain as ABI/API compatible as possible, but there were a couple of API
>> calls that were removed, and there couldn't have been any replacements
>> (these API's were exposing internal structures that shouldn't have been
>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>> because there was no way to do it without it (shared internal structures
>> needed to change in part to support multiprocess).
>>
>> So, if i understand your proposal correctly, assuming a 2-year waiting
>> period for the deprecation of core API's, you would essentially still be
>> waiting for the memory rework to land for a year more. Moreover, even
>> *after* it has landed, there was a continuous stream of improvements and
>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>> were my fault (as in, i could've foreseen the need for those changes, but
>> didn't), but others came as a result of people using these new features in
>> the wild and reporting issues/problems/suggestions - i am but one man, after
>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>> time to implement :)
>>
>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>> keep backwards compatibility for this, or 2) keep two parallel versions of
>> it. We also need to test all that, and, to be honest, one validation cycle
>> for a release wouldn't be enough to figure out all of the kinks and
>> implications of such a case. It was really great that memory rework has
>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>> i think everyone can say that it's in much better shape in 18.11 than it was
>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>> improvements would have slowed down significantly.
>>
>> Now, i understand that this is probably a highly exceptional case, but i'm
>> sure that maintainers of other parts of DPDK will have their own examples of
>> similar things happening.
>>
>> I have no idea what a proper solution would look like. Any "splitting" of
>> the trees into "experimental" vs. "stable" will end up causing the same
>> issue - people choose to use stable over experimental because, well, it's
>> more stable, and new/experimental features don't get tested as much because
>> no one runs the thing in the first place.
>>
>> TL;DR we have to be careful not to constrain the pace of
>> development/bugfixing just for the sake of having a stable API/ABI :)
>>
>
> Actually, I think we *do* need to constrain the pace of development for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project - it
> should just start acting like it.
I 100% agree.
If you break your users stuff regularly enough, they will eventually
start looking around for an alternative that doesn't break their stuff
quiet so regularly.
We often use the pace of innovation in DPDK as justification for ABI/API
breakages, but that approach is a real rarity among the Open Source
community. I can't think of any mature project off-hand that share's it.
I would ask is Linux any less innovative because they offer a stable API
and have an absolute commitment to never breaking userspace? Would Linux
have ever been as popular as it is today it they broke userspace every
quarter?
They reality is that they (Linux) find workarounds and compromise
because there is an uber-maintainer Linus who had a strong ethos from
the start not to break their users stuff - we need the same ethos in DPDK.
>
> Now, in terms of features like the memory rework, that is indeed a case
> that there was no alternative other than a massive ABI break. However, for
> that rework there was a strong need for improvement in that area that we
> can make the case for an ABI break to support it - and it is of a scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are of
> that scale.
I would also be inclined to agree with Bruce's points on memory rework
was somewhat of an outlier, we don't see many like it.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
The work that Anatoly describes removing APIs that exposed internal
structures and Stephen H's RFC similarly are good examples of the kind
of work required to prepare for this change. We need to take a good look
at the API and reduce the number of unnecessary internal structures
exposed.
I never expected it going to to be a big bang - but is a definite
direction we need to move towards over the next few release.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
I agree, with this approach you just delaying the evil day and when that
day comes it will 10-times more painful. This is no substitute for a
don't break our users stuff ethos.
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:52 7% ` Ray Kinsella
@ 2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 14:07 9% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 12:52 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: dev, Kevin Traynor, techboard
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:
>>> Hi folks,
>>>
[SNIP]
>>
>> Hi Ray,
>>
>> My somewhat rambly 2 cents :)
>>
>> While i think some solution has to be found for the situation, we also have
>> to balance this against speed of development and new features rollout.
>>
>> For example, let's consider what i am intimately familiar with - the memory
>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>> remain as ABI/API compatible as possible, but there were a couple of API
>> calls that were removed, and there couldn't have been any replacements
>> (these API's were exposing internal structures that shouldn't have been
>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>> because there was no way to do it without it (shared internal structures
>> needed to change in part to support multiprocess).
>>
>> So, if i understand your proposal correctly, assuming a 2-year waiting
>> period for the deprecation of core API's, you would essentially still be
>> waiting for the memory rework to land for a year more. Moreover, even
>> *after* it has landed, there was a continuous stream of improvements and
>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>> were my fault (as in, i could've foreseen the need for those changes, but
>> didn't), but others came as a result of people using these new features in
>> the wild and reporting issues/problems/suggestions - i am but one man, after
>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>> time to implement :)
>>
>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>> keep backwards compatibility for this, or 2) keep two parallel versions of
>> it. We also need to test all that, and, to be honest, one validation cycle
>> for a release wouldn't be enough to figure out all of the kinks and
>> implications of such a case. It was really great that memory rework has
>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>> i think everyone can say that it's in much better shape in 18.11 than it was
>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>> improvements would have slowed down significantly.
>>
>> Now, i understand that this is probably a highly exceptional case, but i'm
>> sure that maintainers of other parts of DPDK will have their own examples of
>> similar things happening.
>>
>> I have no idea what a proper solution would look like. Any "splitting" of
>> the trees into "experimental" vs. "stable" will end up causing the same
>> issue - people choose to use stable over experimental because, well, it's
>> more stable, and new/experimental features don't get tested as much because
>> no one runs the thing in the first place.
>>
>> TL;DR we have to be careful not to constrain the pace of
>> development/bugfixing just for the sake of having a stable API/ABI :)
>>
>
> Actually, I think we *do* need to constrain the pace of development for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project - it
> should just start acting like it.
I 100% agree.
If you break your users stuff regularly enough, they will eventually
start looking around for an alternative that doesn't break their stuff
quiet so regularly.
We often use the pace of innovation in DPDK as justification for ABI/API
breakages, but that approach is a real rarity among the Open Source
community. I can't think of any mature project off-hand that share's it.
I would ask is Linux any less innovative because they offer a stable API
and have an absolute commitment to never breaking userspace? Would Linux
have ever been as popular as it is today it they broke userspace every
quarter?
They reality is that they (Linux) find workarounds and compromise
because there is an uber-maintainer Linus who had a strong ethos from
the start not to break their users stuff - we need the same ethos in DPDK.
>
> Now, in terms of features like the memory rework, that is indeed a case
> that there was no alternative other than a massive ABI break. However, for
> that rework there was a strong need for improvement in that area that we
> can make the case for an ABI break to support it - and it is of a scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are of
> that scale.
I would also be inclined to agree with Bruce's points on memory rework
was somewhat of an outlier, we don't see many like it.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
The work that Anatoly describes removing APIs that exposed internal
structures and Stephen H's RFC similarly are good examples of the kind
of work required to prepare for this change. We need to take a good look
at the API and reduce the number of unnecessary internal structures
exposed.
I never expected it going to to be a big bang - but is a definite
direction we need to move towards over the next few release.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
I agree, with this approach you just delaying the evil day and when that
day comes it will 10-times more painful. This is no substitute for a
don't break our users stuff ethos.
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 12:02 4% ` Luca Boccassi
@ 2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 13:05 UTC (permalink / raw)
To: Luca Boccassi, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On 04/04/2019 13:02, Luca Boccassi wrote:
> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development
>> for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project -
>> it
>> should just start acting like it.
>>
>> Now, in terms of features like the memory rework, that is indeed a
>> case
>> that there was no alternative other than a massive ABI break.
>> However, for
>> that rework there was a strong need for improvement in that area that
>> we
>> can make the case for an ABI break to support it - and it is of a
>> scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are
>> of
>> that scale.
>
> Fully agree.
>
> It's normal for new project, big and small, to start without a
> stability promise as development ramps up, and then steer toward
> stability as the user base grows. Sometimes the switch is made explicit
> by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> I don't think we crossed that boundary yet in this project, and I
> believe that's the main question Ray was trying to raise: has the time
> finally come for DPDK to do this phase shift?
Yes - we never had a 1.0, where we cut an API and stood behind it
similar to GStreamer. There a number of reasons why this happened not
worth going into, however you make the point very well Luca - this phase
shift is long over due.
>
> Of course it comes with a price for all developers, and that's again
> common.
Agreed - nothing is for free.
The question is this something we value and is it something worth doing.
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should
>> reduce
>> the scope for ABI breaks.
>
> Yes, I'm a big fan of accessors and opaque structs.
+1, me too.
>
>> 2. Once done, I think we should commit to having an ABI break only in
>> the
>> rarest of circumstances, and only with very large justification. I
>> want us
>> to get to the point where DPDK releases can immediately be picked up
>> by all
>> linux distros and rolled out because they are ABI compatible.
>>
>> I'm not sure I like the idea of planned ABI break releases - that
>> strikes
>> me as a plan where we end up with the same number of ABI breaks as
>> before,
>> just balled into one release.
>
> I think that was intended as a compromise, especially as we move from
> one model to the other, and more of a "if a breakage has to happen, it
> must be in the X release" rather than "let's always break in the X
> release" :-)
>
>> Question for Kevin, Luca and others who look at distro-packaging: is
>> it the
>> case that each distro will only ship one version of DPDK, or is it
>> possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
> We can ship multiple versions, although it's more work so there should
> be a good reason to do it.
Well you already kind of do right.
You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9 backports.
> At the moment in Debian and Ubuntu we don't,
> and we tend to ship whatever the latest LTS version is at the distro
> freeze milestone - for example Debian 10 which will be released soon
> (TM) will have 18.11.0.
Presumably when 19.11 arrives, it will land in Debian 10 backports
similarly.
I assume anything that lands in backports is not guaranteed to be ABI
compatible with stable?
>
>> So, in short, I'm generally in favour of a zero-tolerance approach
>> for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory
>> layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:05 7% ` Ray Kinsella
@ 2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:21 4% ` Luca Boccassi
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 13:05 UTC (permalink / raw)
To: Luca Boccassi, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On 04/04/2019 13:02, Luca Boccassi wrote:
> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development
>> for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project -
>> it
>> should just start acting like it.
>>
>> Now, in terms of features like the memory rework, that is indeed a
>> case
>> that there was no alternative other than a massive ABI break.
>> However, for
>> that rework there was a strong need for improvement in that area that
>> we
>> can make the case for an ABI break to support it - and it is of a
>> scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are
>> of
>> that scale.
>
> Fully agree.
>
> It's normal for new project, big and small, to start without a
> stability promise as development ramps up, and then steer toward
> stability as the user base grows. Sometimes the switch is made explicit
> by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> I don't think we crossed that boundary yet in this project, and I
> believe that's the main question Ray was trying to raise: has the time
> finally come for DPDK to do this phase shift?
Yes - we never had a 1.0, where we cut an API and stood behind it
similar to GStreamer. There a number of reasons why this happened not
worth going into, however you make the point very well Luca - this phase
shift is long over due.
>
> Of course it comes with a price for all developers, and that's again
> common.
Agreed - nothing is for free.
The question is this something we value and is it something worth doing.
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should
>> reduce
>> the scope for ABI breaks.
>
> Yes, I'm a big fan of accessors and opaque structs.
+1, me too.
>
>> 2. Once done, I think we should commit to having an ABI break only in
>> the
>> rarest of circumstances, and only with very large justification. I
>> want us
>> to get to the point where DPDK releases can immediately be picked up
>> by all
>> linux distros and rolled out because they are ABI compatible.
>>
>> I'm not sure I like the idea of planned ABI break releases - that
>> strikes
>> me as a plan where we end up with the same number of ABI breaks as
>> before,
>> just balled into one release.
>
> I think that was intended as a compromise, especially as we move from
> one model to the other, and more of a "if a breakage has to happen, it
> must be in the X release" rather than "let's always break in the X
> release" :-)
>
>> Question for Kevin, Luca and others who look at distro-packaging: is
>> it the
>> case that each distro will only ship one version of DPDK, or is it
>> possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
> We can ship multiple versions, although it's more work so there should
> be a good reason to do it.
Well you already kind of do right.
You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9 backports.
> At the moment in Debian and Ubuntu we don't,
> and we tend to ship whatever the latest LTS version is at the distro
> freeze milestone - for example Debian 10 which will be released soon
> (TM) will have 18.11.0.
Presumably when 19.11 arrives, it will land in Debian 10 backports
similarly.
I assume anything that lands in backports is not guaranteed to be ABI
compatible with stable?
>
>> So, in short, I'm generally in favour of a zero-tolerance approach
>> for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory
>> layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
@ 2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-04 13:21 4% ` Luca Boccassi
2 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 13:10 UTC (permalink / raw)
To: Ray Kinsella
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>
>
> On 04/04/2019 13:02, Luca Boccassi wrote:
> > On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >>>
> >>
> >> Actually, I think we *do* need to constrain the pace of development
> >> for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project -
> >> it
> >> should just start acting like it.
> >>
> >> Now, in terms of features like the memory rework, that is indeed a
> >> case
> >> that there was no alternative other than a massive ABI break.
> >> However, for
> >> that rework there was a strong need for improvement in that area that
> >> we
> >> can make the case for an ABI break to support it - and it is of a
> >> scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are
> >> of
> >> that scale.
> >
> > Fully agree.
> >
> > It's normal for new project, big and small, to start without a
> > stability promise as development ramps up, and then steer toward
> > stability as the user base grows. Sometimes the switch is made explicit
> > by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> > I don't think we crossed that boundary yet in this project, and I
> > believe that's the main question Ray was trying to raise: has the time
> > finally come for DPDK to do this phase shift?
>
> Yes - we never had a 1.0, where we cut an API and stood behind it
> similar to GStreamer. There a number of reasons why this happened not
> worth going into, however you make the point very well Luca - this phase
> shift is long over due.
>
> >
> > Of course it comes with a price for all developers, and that's again
> > common.
>
> Agreed - nothing is for free.
> The question is this something we value and is it something worth doing.
>
> >
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should
> >> reduce
> >> the scope for ABI breaks.
> >
> > Yes, I'm a big fan of accessors and opaque structs.
>
> +1, me too.
>
I would be too, with certain exceptions - rte_mbuf for one. Any structures
that are used by applications cannot be made opaque, as apps do not want to
pay the cost of having to call a function every time they want to access
something from one of those structures.
Thankfully for us, we have plenty of other structures that we can work on
in the meantime that can be made private to avoid ABI breaks! :-) I suggest
we work through those first, allowing us to hone our ABI-break avoidance
skills.
/Bruce
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:10 8% ` Bruce Richardson
@ 2019-04-04 13:10 8% ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 13:10 UTC (permalink / raw)
To: Ray Kinsella
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>
>
> On 04/04/2019 13:02, Luca Boccassi wrote:
> > On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >>>
> >>
> >> Actually, I think we *do* need to constrain the pace of development
> >> for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project -
> >> it
> >> should just start acting like it.
> >>
> >> Now, in terms of features like the memory rework, that is indeed a
> >> case
> >> that there was no alternative other than a massive ABI break.
> >> However, for
> >> that rework there was a strong need for improvement in that area that
> >> we
> >> can make the case for an ABI break to support it - and it is of a
> >> scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are
> >> of
> >> that scale.
> >
> > Fully agree.
> >
> > It's normal for new project, big and small, to start without a
> > stability promise as development ramps up, and then steer toward
> > stability as the user base grows. Sometimes the switch is made explicit
> > by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> > I don't think we crossed that boundary yet in this project, and I
> > believe that's the main question Ray was trying to raise: has the time
> > finally come for DPDK to do this phase shift?
>
> Yes - we never had a 1.0, where we cut an API and stood behind it
> similar to GStreamer. There a number of reasons why this happened not
> worth going into, however you make the point very well Luca - this phase
> shift is long over due.
>
> >
> > Of course it comes with a price for all developers, and that's again
> > common.
>
> Agreed - nothing is for free.
> The question is this something we value and is it something worth doing.
>
> >
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should
> >> reduce
> >> the scope for ABI breaks.
> >
> > Yes, I'm a big fan of accessors and opaque structs.
>
> +1, me too.
>
I would be too, with certain exceptions - rte_mbuf for one. Any structures
that are used by applications cannot be made opaque, as apps do not want to
pay the cost of having to call a function every time they want to access
something from one of those structures.
Thankfully for us, we have plenty of other structures that we can work on
in the meantime that can be made private to avoid ABI breaks! :-) I suggest
we work through those first, allowing us to hone our ABI-break avoidance
skills.
/Bruce
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
2019-04-04 9:47 4% ` Kevin Traynor
@ 2019-04-04 13:16 7% ` Ray Kinsella
2019-04-04 13:16 7% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-04 13:16 UTC (permalink / raw)
To: Kevin Traynor, dev, techboard
On 04/04/2019 10:47, Kevin Traynor wrote:
> On 03/04/2019 16:42, Ray Kinsella wrote:
>> Hi folks,
>>
[SNIP]
>>
>> 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".
>> 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.
>>
>
> +1
>
>> 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.
>>
>
> I don't think they automatically graduate in the current scheme, so it
> would seem to be no change to the process.
You are correct ...
"New APIs will be marked as experimental for at least one release to
allow any issues found by users of the new API to be fixed quickly."
https://doc.dpdk.org/guides-18.11/contributing/versioning.html
>
> One thing to note is that in the current experimental API scheme those
> API are tagged as deprecated which can cause problems with application
> build/CI if they are used. But this is more related to implementation
> rather than the classification indicating the API may change. It might
> need to change if there was a trend for keeping API as experimental for
> a longer time.
Others have said this to me also - we need to make experimental less
scary - so people won't be quiet as eager to remove the tag. Depreciated
should stay scary however.
>
>> 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.
>
> I agree with the sentiment but it needs real buy in from authors.
Well I would say it needs real buy in from the Maintainers, at the end
of the day they are the gatekeepers in this instance.
> Otherwise the burden falls on the reviewer to spend time
> exploring/finding a way not to change the API.
I think most of the time, Maintainers will have a good sense of when a
ABI/API change is actually warranted.
>
>> 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.
>>
>> ABI Versioning
>> 7. New quarterly releases of DPDK will remain ABI compatible with the
>> most recent DPDK LTS release.
>> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
>> 8. New DPDK LTS releases will remain ABI compatible with the previous
>> two DPDK LTS releases.
>> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
>> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
>> 8. & 9. will be achieved with ABI symbol versioning.
>>
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 13:16 7% ` Ray Kinsella
@ 2019-04-04 13:16 7% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 13:16 UTC (permalink / raw)
To: Kevin Traynor, dev, techboard
On 04/04/2019 10:47, Kevin Traynor wrote:
> On 03/04/2019 16:42, Ray Kinsella wrote:
>> Hi folks,
>>
[SNIP]
>>
>> 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".
>> 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.
>>
>
> +1
>
>> 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.
>>
>
> I don't think they automatically graduate in the current scheme, so it
> would seem to be no change to the process.
You are correct ...
"New APIs will be marked as experimental for at least one release to
allow any issues found by users of the new API to be fixed quickly."
https://doc.dpdk.org/guides-18.11/contributing/versioning.html
>
> One thing to note is that in the current experimental API scheme those
> API are tagged as deprecated which can cause problems with application
> build/CI if they are used. But this is more related to implementation
> rather than the classification indicating the API may change. It might
> need to change if there was a trend for keeping API as experimental for
> a longer time.
Others have said this to me also - we need to make experimental less
scary - so people won't be quiet as eager to remove the tag. Depreciated
should stay scary however.
>
>> 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.
>
> I agree with the sentiment but it needs real buy in from authors.
Well I would say it needs real buy in from the Maintainers, at the end
of the day they are the gatekeepers in this instance.
> Otherwise the burden falls on the reviewer to spend time
> exploring/finding a way not to change the API.
I think most of the time, Maintainers will have a good sense of when a
ABI/API change is actually warranted.
>
>> 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.
>>
>> ABI Versioning
>> 7. New quarterly releases of DPDK will remain ABI compatible with the
>> most recent DPDK LTS release.
>> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
>> 8. New DPDK LTS releases will remain ABI compatible with the previous
>> two DPDK LTS releases.
>> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
>> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
>> 8. & 9. will be achieved with ABI symbol versioning.
>>
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:10 8% ` Bruce Richardson
@ 2019-04-04 13:21 4% ` Luca Boccassi
2019-04-04 13:21 4% ` Luca Boccassi
2 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2019-04-04 13:21 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 14:05 +0100, Ray Kinsella wrote:
> > > Question for Kevin, Luca and others who look at distro-packaging:
> > > is
> > > it the
> > > case that each distro will only ship one version of DPDK, or is
> > > it
> > > possible
> > > that if we have ABI breaks, a distro will provide two copies of
> > > DPDK
> > > simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
> >
> > We can ship multiple versions, although it's more work so there
> > should
> > be a good reason to do it.
>
> Well you already kind of do right.
> You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9
> backports.
Yes indeed - backports has a different policy and is not part of
"Debian main" - for example, stability and security support are not
guaranteed. Also there is no guarantee of compatibility of co-
installability - while you can have the individual libraries from each
version at the same time, you can't have both libdpdk-dev packages
which are necessary to build an application. So you have to choose and
install either libdpdk-dev=16.11 or libdpdk-dev=18.11.
It is possible to have multiple versions in the same archive at the
same time, and with multiple -dev packages, and that's what I meant
when I mentioned it was more work.
> > At the moment in Debian and Ubuntu we don't,
> > and we tend to ship whatever the latest LTS version is at the
> > distro
> > freeze milestone - for example Debian 10 which will be released
> > soon
> > (TM) will have 18.11.0.
>
> Presumably when 19.11 arrives, it will land in Debian 10 backports
> similarly.
>
> I assume anything that lands in backports is not guaranteed to be ABI
> compatible with stable?
Yes, there's no guarantee.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:21 4% ` Luca Boccassi
@ 2019-04-04 13:21 4% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-04 13:21 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 14:05 +0100, Ray Kinsella wrote:
> > > Question for Kevin, Luca and others who look at distro-packaging:
> > > is
> > > it the
> > > case that each distro will only ship one version of DPDK, or is
> > > it
> > > possible
> > > that if we have ABI breaks, a distro will provide two copies of
> > > DPDK
> > > simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
> >
> > We can ship multiple versions, although it's more work so there
> > should
> > be a good reason to do it.
>
> Well you already kind of do right.
> You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9
> backports.
Yes indeed - backports has a different policy and is not part of
"Debian main" - for example, stability and security support are not
guaranteed. Also there is no guarantee of compatibility of co-
installability - while you can have the individual libraries from each
version at the same time, you can't have both libdpdk-dev packages
which are necessary to build an application. So you have to choose and
install either libdpdk-dev=16.11 or libdpdk-dev=18.11.
It is possible to have multiple versions in the same archive at the
same time, and with multiple -dev packages, and that's what I meant
when I mentioned it was more work.
> > At the moment in Debian and Ubuntu we don't,
> > and we tend to ship whatever the latest LTS version is at the
> > distro
> > freeze milestone - for example Debian 10 which will be released
> > soon
> > (TM) will have 18.11.0.
>
> Presumably when 19.11 arrives, it will land in Debian 10 backports
> similarly.
>
> I assume anything that lands in backports is not guaranteed to be ABI
> compatible with stable?
Yes, there's no guarantee.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
@ 2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 14:07 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson; +Cc: dev, Kevin Traynor, techboard
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:
>>>> Hi folks,
>>>>
> [SNIP]
>>>
>>> Hi Ray,
>>>
>>> My somewhat rambly 2 cents :)
>>>
>>> While i think some solution has to be found for the situation, we also have
>>> to balance this against speed of development and new features rollout.
>>>
>>> For example, let's consider what i am intimately familiar with - the memory
>>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>>> remain as ABI/API compatible as possible, but there were a couple of API
>>> calls that were removed, and there couldn't have been any replacements
>>> (these API's were exposing internal structures that shouldn't have been
>>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>>> because there was no way to do it without it (shared internal structures
>>> needed to change in part to support multiprocess).
>>>
>>> So, if i understand your proposal correctly, assuming a 2-year waiting
>>> period for the deprecation of core API's, you would essentially still be
>>> waiting for the memory rework to land for a year more. Moreover, even
>>> *after* it has landed, there was a continuous stream of improvements and
>>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>>> were my fault (as in, i could've foreseen the need for those changes, but
>>> didn't), but others came as a result of people using these new features in
>>> the wild and reporting issues/problems/suggestions - i am but one man, after
>>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>>> time to implement :)
>>>
>>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>>> keep backwards compatibility for this, or 2) keep two parallel versions of
>>> it. We also need to test all that, and, to be honest, one validation cycle
>>> for a release wouldn't be enough to figure out all of the kinks and
>>> implications of such a case. It was really great that memory rework has
>>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>>> i think everyone can say that it's in much better shape in 18.11 than it was
>>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>>> improvements would have slowed down significantly.
>>>
>>> Now, i understand that this is probably a highly exceptional case, but i'm
>>> sure that maintainers of other parts of DPDK will have their own examples of
>>> similar things happening.
>>>
>>> I have no idea what a proper solution would look like. Any "splitting" of
>>> the trees into "experimental" vs. "stable" will end up causing the same
>>> issue - people choose to use stable over experimental because, well, it's
>>> more stable, and new/experimental features don't get tested as much because
>>> no one runs the thing in the first place.
>>>
>>> TL;DR we have to be careful not to constrain the pace of
>>> development/bugfixing just for the sake of having a stable API/ABI :)
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project - it
>> should just start acting like it.
>
> I 100% agree.
>
> If you break your users stuff regularly enough, they will eventually
> start looking around for an alternative that doesn't break their stuff
> quiet so regularly.
>
> We often use the pace of innovation in DPDK as justification for ABI/API
> breakages, but that approach is a real rarity among the Open Source
> community. I can't think of any mature project off-hand that share's it.
>
> I would ask is Linux any less innovative because they offer a stable API
> and have an absolute commitment to never breaking userspace? Would Linux
> have ever been as popular as it is today it they broke userspace every
> quarter?
>
> They reality is that they (Linux) find workarounds and compromise
> because there is an uber-maintainer Linus who had a strong ethos from
> the start not to break their users stuff - we need the same ethos in DPDK.
>
>>
>> Now, in terms of features like the memory rework, that is indeed a case
>> that there was no alternative other than a massive ABI break. However, for
>> that rework there was a strong need for improvement in that area that we
>> can make the case for an ABI break to support it - and it is of a scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are of
>> that scale.
>
> I would also be inclined to agree with Bruce's points on memory rework
> was somewhat of an outlier, we don't see many like it.
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> The work that Anatoly describes removing APIs that exposed internal
> structures and Stephen H's RFC similarly are good examples of the kind
> of work required to prepare for this change. We need to take a good look
> at the API and reduce the number of unnecessary internal structures
> exposed.
>
> I never expected it going to to be a big bang - but is a definite
> direction we need to move towards over the next few release.
...in this case, we have to think long and hard about the fabled EAL
rework/split, and in general *specifying* what is it that we want to
support, and the use cases that we want to target. Right now there is a
huge mountain of technical debt and kludges and workarounds that has
accumulated over the years, and it exists precisely because "every
change breaks someone's workflow".
For example, just in memory subsystem alone, we have legacy mem, because
some use cases require huge amounts of contiguous memory, and not
everyone is using VFIO; there's all of the 32-bit related workarounds
and hacks; there's the single-file-segments stuff that could have been
the default if not for the fact that we support kernels that don't
support fallocate(); there are two different ways of doing in-memory
mode, because not all kernels support memfd's; there is a gargantuan
pile of workarounds (and "known issues", and just code in general) all
over the DPDK codebase just to support our multiprocess model and all of
the various warts that come with it.
In fact, i would even go as far as to say that *most* of EAL ABI breaks
have been due to the fact that we store data in shared memory because of
multiprocess - so there is simply no way we can change these internal
data structures without ABI breaks, because even if they're not exposed
through user-facing API, they are still exposed by virtue of secondary
processes basically having an ABI contract with primary process instances.
So, if we are to cement our core API - we have to make a concrete effort
to specify what goes and what stays, if we want it to be maintainable.
The DPDK 1.0 specification, if you will :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 14:07 9% ` Burakov, Anatoly
@ 2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 14:07 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson; +Cc: dev, Kevin Traynor, techboard
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:
>>>> Hi folks,
>>>>
> [SNIP]
>>>
>>> Hi Ray,
>>>
>>> My somewhat rambly 2 cents :)
>>>
>>> While i think some solution has to be found for the situation, we also have
>>> to balance this against speed of development and new features rollout.
>>>
>>> For example, let's consider what i am intimately familiar with - the memory
>>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>>> remain as ABI/API compatible as possible, but there were a couple of API
>>> calls that were removed, and there couldn't have been any replacements
>>> (these API's were exposing internal structures that shouldn't have been
>>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>>> because there was no way to do it without it (shared internal structures
>>> needed to change in part to support multiprocess).
>>>
>>> So, if i understand your proposal correctly, assuming a 2-year waiting
>>> period for the deprecation of core API's, you would essentially still be
>>> waiting for the memory rework to land for a year more. Moreover, even
>>> *after* it has landed, there was a continuous stream of improvements and
>>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>>> were my fault (as in, i could've foreseen the need for those changes, but
>>> didn't), but others came as a result of people using these new features in
>>> the wild and reporting issues/problems/suggestions - i am but one man, after
>>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>>> time to implement :)
>>>
>>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>>> keep backwards compatibility for this, or 2) keep two parallel versions of
>>> it. We also need to test all that, and, to be honest, one validation cycle
>>> for a release wouldn't be enough to figure out all of the kinks and
>>> implications of such a case. It was really great that memory rework has
>>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>>> i think everyone can say that it's in much better shape in 18.11 than it was
>>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>>> improvements would have slowed down significantly.
>>>
>>> Now, i understand that this is probably a highly exceptional case, but i'm
>>> sure that maintainers of other parts of DPDK will have their own examples of
>>> similar things happening.
>>>
>>> I have no idea what a proper solution would look like. Any "splitting" of
>>> the trees into "experimental" vs. "stable" will end up causing the same
>>> issue - people choose to use stable over experimental because, well, it's
>>> more stable, and new/experimental features don't get tested as much because
>>> no one runs the thing in the first place.
>>>
>>> TL;DR we have to be careful not to constrain the pace of
>>> development/bugfixing just for the sake of having a stable API/ABI :)
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project - it
>> should just start acting like it.
>
> I 100% agree.
>
> If you break your users stuff regularly enough, they will eventually
> start looking around for an alternative that doesn't break their stuff
> quiet so regularly.
>
> We often use the pace of innovation in DPDK as justification for ABI/API
> breakages, but that approach is a real rarity among the Open Source
> community. I can't think of any mature project off-hand that share's it.
>
> I would ask is Linux any less innovative because they offer a stable API
> and have an absolute commitment to never breaking userspace? Would Linux
> have ever been as popular as it is today it they broke userspace every
> quarter?
>
> They reality is that they (Linux) find workarounds and compromise
> because there is an uber-maintainer Linus who had a strong ethos from
> the start not to break their users stuff - we need the same ethos in DPDK.
>
>>
>> Now, in terms of features like the memory rework, that is indeed a case
>> that there was no alternative other than a massive ABI break. However, for
>> that rework there was a strong need for improvement in that area that we
>> can make the case for an ABI break to support it - and it is of a scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are of
>> that scale.
>
> I would also be inclined to agree with Bruce's points on memory rework
> was somewhat of an outlier, we don't see many like it.
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> The work that Anatoly describes removing APIs that exposed internal
> structures and Stephen H's RFC similarly are good examples of the kind
> of work required to prepare for this change. We need to take a good look
> at the API and reduce the number of unnecessary internal structures
> exposed.
>
> I never expected it going to to be a big bang - but is a definite
> direction we need to move towards over the next few release.
...in this case, we have to think long and hard about the fabled EAL
rework/split, and in general *specifying* what is it that we want to
support, and the use cases that we want to target. Right now there is a
huge mountain of technical debt and kludges and workarounds that has
accumulated over the years, and it exists precisely because "every
change breaks someone's workflow".
For example, just in memory subsystem alone, we have legacy mem, because
some use cases require huge amounts of contiguous memory, and not
everyone is using VFIO; there's all of the 32-bit related workarounds
and hacks; there's the single-file-segments stuff that could have been
the default if not for the fact that we support kernels that don't
support fallocate(); there are two different ways of doing in-memory
mode, because not all kernels support memfd's; there is a gargantuan
pile of workarounds (and "known issues", and just code in general) all
over the DPDK codebase just to support our multiprocess model and all of
the various warts that come with it.
In fact, i would even go as far as to say that *most* of EAL ABI breaks
have been due to the fact that we store data in shared memory because of
multiprocess - so there is simply no way we can change these internal
data structures without ABI breaks, because even if they're not exposed
through user-facing API, they are still exposed by virtue of secondary
processes basically having an ABI contract with primary process instances.
So, if we are to cement our core API - we have to make a concrete effort
to specify what goes and what stays, if we want it to be maintainable.
The DPDK 1.0 specification, if you will :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
` (2 preceding siblings ...)
2019-04-04 12:52 7% ` Ray Kinsella
@ 2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:56 7% ` Kevin Traynor
4 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-04 15:51 UTC (permalink / raw)
To: Bruce Richardson
Cc: Burakov, Anatoly, Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 4 Apr 2019 11:54:47 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
I would also like to propose "you get one ABI break" which means each
API/ABI change must hide more infrastructure than the last. This is
the "fool me once, ..." saying in API's.
For example,
the memory rework it would have been good if the structure of mempools etc
were hidden inside EAL and not exposed. but as usual hindsight is 20/20
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 15:51 8% ` Stephen Hemminger
@ 2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:37 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-04 15:51 UTC (permalink / raw)
To: Bruce Richardson
Cc: Burakov, Anatoly, Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 4 Apr 2019 11:54:47 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
I would also like to propose "you get one ABI break" which means each
API/ABI change must hide more infrastructure than the last. This is
the "fool me once, ..." saying in API's.
For example,
the memory rework it would have been good if the structure of mempools etc
were hidden inside EAL and not exposed. but as usual hindsight is 20/20
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
2019-04-04 8:51 2% ` Xiaolong Ye
@ 2019-04-04 16:13 0% ` Ferruh Yigit
2019-04-04 16:13 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-04 16:13 UTC (permalink / raw)
To: Xiaolong Ye, dev, Stephen Hemminger, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz
On 4/4/2019 9:51 AM, Xiaolong Ye wrote:
> Overview
> ========
>
> This patchset adds a new PMD driver for AF_XDP which is a proposed
> faster version of AF_PACKET interface in Linux, see below links [1] [2] for
> details of AF_XDP introduction:
>
> AF_XDP roadmap
> ==============
> - AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
> in libbpf has been merged in v5.1-rc1.
> - Now i40e and ixgbe drivers have supported zero copy mode.
>
> Change logs
> ===========
> v11:
>
> - fix the meson build issue
>
> v10:
>
> - refine the Makefile, remove RTE_KERNELDIR related CFLAGS
> - add a new internal file af_xdp_deps.h to handle the dependency for
> asm/barrier.h
> - fix a typo observed by Stephen
> - rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
> /usr/local/include/bpf
> - add libbpf build steps in af_xdp.rst
>
>
> v9:
> - adjust header files order according to Stephen's suggestion
>
> v8:
> - address Ferruh's comments on V7
> - replace posix_memalign with rte_memzone_reserve_aligned to get better
> performance
> - keep the first patch only as Oliver suggested as zero copy part
> implementation is still in suspense, we may provide the related patch
> later.
>
> v7:
> - mention mtu limitation in af_xdp.rst
> - fix the vdev name in af_xdp.rst
>
> V6:
>
> - remove the newline in AF_XDP_LOG definition to avoid double new lines
> issue.
> - rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
>
> V5:
>
> - disable AF_XDP pmd by default due to it requires kernel more recent
> than minimum kernel version supported by DPDK
> - address other review comments of Maxime
>
> V4:
>
> - change vdev name to net_af_xdp
> - adopt dynamic log type for all logging
> - Fix other style issues raised by Stephen
>
> V3:
>
> - Fix all style issues pointed by Stephen, Mattias, David.
> - Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
> mempool driver to handle the application use of AF_XDP's zero copy feature.
>
> V2:
> - Fix a NULL pointer reference crash issue
> - Fix txonly stop sending traffic in zc mode
> - Refactor rte_mbuf.c to avoid ABI breakage.
> - Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
>
> changes vs RFC sent by Qi last Aug:
>
> - Re-work base on AF_XDP's interface changes since the new libbpf has
> provided higher-level APIs that hide many of the details of the AP_XDP
> uapi. After the rework, it helps to reduce 300+ lines of code.
>
> - multi-queues is not supported due to current libbpf doesn't support
> multi-sockets on a single umem.
>
> - No extra steps to load xdp program manually, since the current behavior of
> libbpf would load a default xdp program when user calls xsk_socket__create.
> userspace application only needs to handle the cleanup.
>
> How to try
> ==========
>
> 1. take the kernel >= v5.1-rc1, build kernel and replace your host
> kernel with it.
>
> make sure you turn on XDP sockets when compiling
>
> Networking support -->
> Networking options -->
> [ * ] XDP sockets
>
> 2. build & install libbpf in tools/lib/bpf
>
> cd tools/lib/bpf
> make install_lib
> make install_headers
>
> 3. ethtool -L enp59s0f0 combined 1
>
> 4. extra step to build dpdk
>
> explicitly enable AF_XDP pmd by adding below line to
> config/common_linux
>
> CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
>
> 5. start testpmd
>
> ./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
>
> in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
> network traffics travel to queue 0 will be redirected to af_xdp socket.
>
> Xiaolong Ye (1):
> net/af_xdp: introduce AF XDP PMD driver
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-04 16:13 0% ` Ferruh Yigit
@ 2019-04-04 16:13 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-04 16:13 UTC (permalink / raw)
To: Xiaolong Ye, dev, Stephen Hemminger, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz
On 4/4/2019 9:51 AM, Xiaolong Ye wrote:
> Overview
> ========
>
> This patchset adds a new PMD driver for AF_XDP which is a proposed
> faster version of AF_PACKET interface in Linux, see below links [1] [2] for
> details of AF_XDP introduction:
>
> AF_XDP roadmap
> ==============
> - AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
> in libbpf has been merged in v5.1-rc1.
> - Now i40e and ixgbe drivers have supported zero copy mode.
>
> Change logs
> ===========
> v11:
>
> - fix the meson build issue
>
> v10:
>
> - refine the Makefile, remove RTE_KERNELDIR related CFLAGS
> - add a new internal file af_xdp_deps.h to handle the dependency for
> asm/barrier.h
> - fix a typo observed by Stephen
> - rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
> /usr/local/include/bpf
> - add libbpf build steps in af_xdp.rst
>
>
> v9:
> - adjust header files order according to Stephen's suggestion
>
> v8:
> - address Ferruh's comments on V7
> - replace posix_memalign with rte_memzone_reserve_aligned to get better
> performance
> - keep the first patch only as Oliver suggested as zero copy part
> implementation is still in suspense, we may provide the related patch
> later.
>
> v7:
> - mention mtu limitation in af_xdp.rst
> - fix the vdev name in af_xdp.rst
>
> V6:
>
> - remove the newline in AF_XDP_LOG definition to avoid double new lines
> issue.
> - rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
>
> V5:
>
> - disable AF_XDP pmd by default due to it requires kernel more recent
> than minimum kernel version supported by DPDK
> - address other review comments of Maxime
>
> V4:
>
> - change vdev name to net_af_xdp
> - adopt dynamic log type for all logging
> - Fix other style issues raised by Stephen
>
> V3:
>
> - Fix all style issues pointed by Stephen, Mattias, David.
> - Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
> mempool driver to handle the application use of AF_XDP's zero copy feature.
>
> V2:
> - Fix a NULL pointer reference crash issue
> - Fix txonly stop sending traffic in zc mode
> - Refactor rte_mbuf.c to avoid ABI breakage.
> - Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
>
> changes vs RFC sent by Qi last Aug:
>
> - Re-work base on AF_XDP's interface changes since the new libbpf has
> provided higher-level APIs that hide many of the details of the AP_XDP
> uapi. After the rework, it helps to reduce 300+ lines of code.
>
> - multi-queues is not supported due to current libbpf doesn't support
> multi-sockets on a single umem.
>
> - No extra steps to load xdp program manually, since the current behavior of
> libbpf would load a default xdp program when user calls xsk_socket__create.
> userspace application only needs to handle the cleanup.
>
> How to try
> ==========
>
> 1. take the kernel >= v5.1-rc1, build kernel and replace your host
> kernel with it.
>
> make sure you turn on XDP sockets when compiling
>
> Networking support -->
> Networking options -->
> [ * ] XDP sockets
>
> 2. build & install libbpf in tools/lib/bpf
>
> cd tools/lib/bpf
> make install_lib
> make install_headers
>
> 3. ethtool -L enp59s0f0 combined 1
>
> 4. extra step to build dpdk
>
> explicitly enable AF_XDP pmd by adding below line to
> config/common_linux
>
> CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
>
> 5. start testpmd
>
> ./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
>
> in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
> network traffics travel to queue 0 will be redirected to af_xdp socket.
>
> Xiaolong Ye (1):
> net/af_xdp: introduce AF XDP PMD driver
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 15:51 8% ` Stephen Hemminger
@ 2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:37 4% ` Burakov, Anatoly
1 sibling, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-04-04 16:37 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On 04-Apr-19 4:51 PM, Stephen Hemminger wrote:
> On Thu, 4 Apr 2019 11:54:47 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> I would also like to propose "you get one ABI break" which means each
> API/ABI change must hide more infrastructure than the last. This is
> the "fool me once, ..." saying in API's.
>
> For example,
> the memory rework it would have been good if the structure of mempools etc
> were hidden inside EAL and not exposed. but as usual hindsight is 20/20
>
Mempools is not part of "memory rework" - it's a separate library built
on top of EAL's memory subsystem :) When i talk about "memory API's", i
mean memzone/malloc and friends, not mempool.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 16:37 4% ` Burakov, Anatoly
@ 2019-04-04 16:37 4% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 16:37 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On 04-Apr-19 4:51 PM, Stephen Hemminger wrote:
> On Thu, 4 Apr 2019 11:54:47 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> I would also like to propose "you get one ABI break" which means each
> API/ABI change must hide more infrastructure than the last. This is
> the "fool me once, ..." saying in API's.
>
> For example,
> the memory rework it would have been good if the structure of mempools etc
> were hidden inside EAL and not exposed. but as usual hindsight is 20/20
>
Mempools is not part of "memory rework" - it's a separate library built
on top of EAL's memory subsystem :) When i talk about "memory API's", i
mean memzone/malloc and friends, not mempool.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
` (3 preceding siblings ...)
2019-04-04 15:51 8% ` Stephen Hemminger
@ 2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 19:08 8% ` Wiles, Keith
4 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 16:56 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: Ray Kinsella, dev, techboard
On 04/04/2019 11:54, Bruce Richardson wrote:
<snip>
>
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
>
Maybe techboard should explicitly approve ABI breaks and new APIs (or
APIs at transition from experimental to core). Just as a way to get more
eyeballs and scrutiny on them.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
It would probably double validation and maintenance, so it would require
a lot of extra effort.
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 16:56 7% ` Kevin Traynor
@ 2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 19:08 8% ` Wiles, Keith
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 16:56 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: Ray Kinsella, dev, techboard
On 04/04/2019 11:54, Bruce Richardson wrote:
<snip>
>
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
>
Maybe techboard should explicitly approve ABI breaks and new APIs (or
APIs at transition from experimental to core). Just as a way to get more
eyeballs and scrutiny on them.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
It would probably double validation and maintenance, so it would require
a lot of extra effort.
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 16:56 7% ` Kevin Traynor
@ 2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Wiles, Keith @ 2019-04-04 19:08 UTC (permalink / raw)
To: Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 04/04/2019 11:54, Bruce Richardson wrote:
> <snip>
>
>>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>>
>
> Maybe techboard should explicitly approve ABI breaks and new APIs (or
> APIs at transition from experimental to core). Just as a way to get more
> eyeballs and scrutiny on them.
ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>
>> I'm not sure I like the idea of planned ABI break releases - that strikes
>> me as a plan where we end up with the same number of ABI breaks as before,
>> just balled into one release.
>>
>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>> case that each distro will only ship one version of DPDK, or is it possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>
>
> It would probably double validation and maintenance, so it would require
> a lot of extra effort.
>
>>
>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
>
Regards,
Keith
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 19:08 8% ` Wiles, Keith
@ 2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:29 4% ` Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2019-04-04 19:08 UTC (permalink / raw)
To: Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 04/04/2019 11:54, Bruce Richardson wrote:
> <snip>
>
>>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>>
>
> Maybe techboard should explicitly approve ABI breaks and new APIs (or
> APIs at transition from experimental to core). Just as a way to get more
> eyeballs and scrutiny on them.
ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>
>> I'm not sure I like the idea of planned ABI break releases - that strikes
>> me as a plan where we end up with the same number of ABI breaks as before,
>> just balled into one release.
>>
>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>> case that each distro will only ship one version of DPDK, or is it possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>
>
> It would probably double validation and maintenance, so it would require
> a lot of extra effort.
>
>>
>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
>
Regards,
Keith
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
@ 2019-04-04 20:13 8% ` Kevin Traynor
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 20:13 UTC (permalink / raw)
To: Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
>>
>>>
>>> My thoughts on the matter are:
>>> 1. I think we really need to do work to start hiding more of our data
>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>> the scope for ABI breaks.
>>> 2. Once done, I think we should commit to having an ABI break only in the
>>> rarest of circumstances, and only with very large justification. I want us
>>> to get to the point where DPDK releases can immediately be picked up by all
>>> linux distros and rolled out because they are ABI compatible.
>>>
>>
>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>> APIs at transition from experimental to core). Just as a way to get more
>> eyeballs and scrutiny on them.
>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>
We'll only find out if they are bad when they need ABI breaks later :-)
My point is a good way to avoid future ABI breaks is to have more
reviews on the APIs in the first place. Techboard approval might be one
way, or 3 acks or something else.
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 20:13 8% ` Kevin Traynor
@ 2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 20:13 UTC (permalink / raw)
To: Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
>>
>>>
>>> My thoughts on the matter are:
>>> 1. I think we really need to do work to start hiding more of our data
>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>> the scope for ABI breaks.
>>> 2. Once done, I think we should commit to having an ABI break only in the
>>> rarest of circumstances, and only with very large justification. I want us
>>> to get to the point where DPDK releases can immediately be picked up by all
>>> linux distros and rolled out because they are ABI compatible.
>>>
>>
>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>> APIs at transition from experimental to core). Just as a way to get more
>> eyeballs and scrutiny on them.
>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>
We'll only find out if they are bad when they need ABI breaks later :-)
My point is a good way to avoid future ABI breaks is to have more
reviews on the APIs in the first place. Techboard approval might be one
way, or 3 acks or something else.
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
@ 2019-04-04 22:28 0% ` Eads, Gage
2019-04-04 22:28 0% ` Eads, Gage
0 siblings, 1 reply; 200+ results
From: Eads, Gage @ 2019-04-04 22:28 UTC (permalink / raw)
To: Ola Liljedahl, stephen
Cc: jerinj, mczekaj, nd, Ananyev, Konstantin, Richardson, Bruce, dev,
olivier.matz, arybchenko
> On Mon, 2019-04-01 at 19:23 +0000, Eads, Gage wrote:
> > >
> > >
> > > On Mon, 18 Mar 2019 21:49:44 +0000
> > > "Eads, Gage" <gage.eads@intel.com> wrote:
> > >
> > > >
> > > > Hi all,
> > > >
> > > > Friendly reminder that in order to get this feature into 19.08
> > > > (assuming
> > > folks also want that :)), the API deprecation notice needs to be
> > > merged into 19.05.
> > > >
> > > >
> > > > Thanks,
> > > > Gage
> > > Given the recent API/ABI stability discussion, this is the kind of
> > > patch that really needs to be examined and justified.
> > Can you point me to the discussion (assuming it was on the ML)? I'm
> > aware of Ferruh's changes to the docs, but not the discussion you
> referenced.
> >
> > The lock-free ring functionality itself is a valuable addition to
> > DPDK, primarily because it lacks the standard ring's non-preemptive
> > constraint. The non-preemptive constraint is important in an
> > application with both high priority, performance-sensitive data-plane
> > components and low-priority control-plane components. This was
> > important enough to warrant further clarification recently[1], and has
> > been a discussion topic for some time[2][3].
> >
> > The modified API, rte_ring_get_memsize(), was added to allow users to
> > initialize rings in separately allocated memory. This function isn't
> > called in DPDK's examples/apps/drivers, and a quick google search
> > didn't turn up any open source projects that call the function, so I
> > suspect that a majority of ring code uses rte_ring_create() instead of
> > rte_ring_get_memsize() + rte_ring_init(). So I suspect this interface
> > change will affect a small percentage of DPDK users.
> >
> > As a straw-man counter-proposal, we could instead introduce a
> > lock-free specific function rte_lf_ring_get_memsize() that lock-free
> > ring users would call instead of rte_ring_get_memsize(). This would
> > avoid the API modification,
> > but:
> > - It's awkward to have one rte_lf_ring_* function and otherwise access
> > the lock-free ring through rte_ring_* functions.
> > - It's also easy to envision a user incorrectly calling
> > rte_ring_get_memsize() rather than rte_lf_ring_get_memsize() for a
> > lock-free ring, since otherwise
> > rte_ring_* functions are used. DPDK would have no way to detect that
> > the allocated memory is too small, and if such a bug occurs it would
> > manifest itself as memory corruption.
> > - Changing rte_ring_get_memsize() to take a flags argument may be the
> > better long-term design, if another flag is introduced that likewise
> > uses a different ring size.
> >
> > Another approach is to break out the lock-free ring into a fully separate
> API.
> As in the RFC I posted: http://patches.dpdk.org/patch/50095/
> Cleaner API, simpler implementation.
>
> > One of the goals of my patchset was to allow applications to switch to lock-
> > free rings with minimal code change; I think the value of the lock-free ring
> > warrants such an approach.
>
> A noble goal but personally I think DPDK API's and implementations are
> getting more and more messy and thus difficult to use and difficult to
> maintain.
> Is it so much worse to have separate but structurally equivalent API's?
No -- I think both are valid options, with their own tradeoffs.
> Yes, blocking vs non-blocking can no longer be selected at runtime (startup
> time), I think this is the biggest limitation.
Run-time selection with the LF flag means we can easily re-use a large amount of pre-existing ring code -- e.g. the way the ring tests are re-purposed for lock-free rings in this patchset.
The implementation may not be as easily maintained, but we don't have to maintain LF-specific tests/benchmarks/etc.
Maintainers/tech leads, do y'all have a preference?
Thanks,
Gage
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-04-04 22:28 0% ` Eads, Gage
@ 2019-04-04 22:28 0% ` Eads, Gage
0 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-04-04 22:28 UTC (permalink / raw)
To: Ola Liljedahl, stephen
Cc: jerinj, mczekaj, nd, Ananyev, Konstantin, Richardson, Bruce, dev,
olivier.matz, arybchenko
> On Mon, 2019-04-01 at 19:23 +0000, Eads, Gage wrote:
> > >
> > >
> > > On Mon, 18 Mar 2019 21:49:44 +0000
> > > "Eads, Gage" <gage.eads@intel.com> wrote:
> > >
> > > >
> > > > Hi all,
> > > >
> > > > Friendly reminder that in order to get this feature into 19.08
> > > > (assuming
> > > folks also want that :)), the API deprecation notice needs to be
> > > merged into 19.05.
> > > >
> > > >
> > > > Thanks,
> > > > Gage
> > > Given the recent API/ABI stability discussion, this is the kind of
> > > patch that really needs to be examined and justified.
> > Can you point me to the discussion (assuming it was on the ML)? I'm
> > aware of Ferruh's changes to the docs, but not the discussion you
> referenced.
> >
> > The lock-free ring functionality itself is a valuable addition to
> > DPDK, primarily because it lacks the standard ring's non-preemptive
> > constraint. The non-preemptive constraint is important in an
> > application with both high priority, performance-sensitive data-plane
> > components and low-priority control-plane components. This was
> > important enough to warrant further clarification recently[1], and has
> > been a discussion topic for some time[2][3].
> >
> > The modified API, rte_ring_get_memsize(), was added to allow users to
> > initialize rings in separately allocated memory. This function isn't
> > called in DPDK's examples/apps/drivers, and a quick google search
> > didn't turn up any open source projects that call the function, so I
> > suspect that a majority of ring code uses rte_ring_create() instead of
> > rte_ring_get_memsize() + rte_ring_init(). So I suspect this interface
> > change will affect a small percentage of DPDK users.
> >
> > As a straw-man counter-proposal, we could instead introduce a
> > lock-free specific function rte_lf_ring_get_memsize() that lock-free
> > ring users would call instead of rte_ring_get_memsize(). This would
> > avoid the API modification,
> > but:
> > - It's awkward to have one rte_lf_ring_* function and otherwise access
> > the lock-free ring through rte_ring_* functions.
> > - It's also easy to envision a user incorrectly calling
> > rte_ring_get_memsize() rather than rte_lf_ring_get_memsize() for a
> > lock-free ring, since otherwise
> > rte_ring_* functions are used. DPDK would have no way to detect that
> > the allocated memory is too small, and if such a bug occurs it would
> > manifest itself as memory corruption.
> > - Changing rte_ring_get_memsize() to take a flags argument may be the
> > better long-term design, if another flag is introduced that likewise
> > uses a different ring size.
> >
> > Another approach is to break out the lock-free ring into a fully separate
> API.
> As in the RFC I posted: http://patches.dpdk.org/patch/50095/
> Cleaner API, simpler implementation.
>
> > One of the goals of my patchset was to allow applications to switch to lock-
> > free rings with minimal code change; I think the value of the lock-free ring
> > warrants such an approach.
>
> A noble goal but personally I think DPDK API's and implementations are
> getting more and more messy and thus difficult to use and difficult to
> maintain.
> Is it so much worse to have separate but structurally equivalent API's?
No -- I think both are valid options, with their own tradeoffs.
> Yes, blocking vs non-blocking can no longer be selected at runtime (startup
> time), I think this is the biggest limitation.
Run-time selection with the LF flag means we can easily re-use a large amount of pre-existing ring code -- e.g. the way the ring tests are re-purposed for lock-free rings in this patchset.
The implementation may not be as easily maintained, but we don't have to maintain LF-specific tests/benchmarks/etc.
Maintainers/tech leads, do y'all have a preference?
Thanks,
Gage
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
@ 2019-04-05 8:17 4% David Marchand
2019-04-05 8:17 4% ` David Marchand
2019-04-05 11:22 0% ` Neil Horman
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-04-05 8:17 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
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>
---
devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 020da7e..40eb953 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -105,27 +105,37 @@ check_for_rule_violations()
continue
fi
- if [ "$secname" != "EXPERIMENTAL" ]
+ oldsecname=$(sed -n \
+ "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
+
+ # A symbol can not enter a non experimental
+ # section directly
+ if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
then
- # Symbols that are getting added in a section
- # other than the experimental section
- # to be moving from an already supported
- # section or its a violation
- grep -q \
- "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
- if [ $? -ne 0 ]
- 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
- fi
+ 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
+
+ # This symbol is moving between two sections (the
+ # original section is not experimental).
+ # This can be legit, just warn.
+ if [ "$oldsecname" != 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname is being "
+ echo -n "moved from $oldsecname to $secname. "
+ echo -n "Ensure that it has gone through the "
+ echo "deprecation process"
+ continue
fi
else
- if [ "$secname" != "EXPERIMENTAL" ]
+ if ! grep -q "$mname $symname .* add" "$mapdb" && \
+ [ "$secname" != "EXPERIMENTAL" ]
then
# Just inform users that non-experimenal
# symbols need to go through a deprecation
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 8:17 4% [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
@ 2019-04-05 8:17 4% ` David Marchand
2019-04-05 11:22 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-05 8:17 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
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>
---
devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 020da7e..40eb953 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -105,27 +105,37 @@ check_for_rule_violations()
continue
fi
- if [ "$secname" != "EXPERIMENTAL" ]
+ oldsecname=$(sed -n \
+ "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
+
+ # A symbol can not enter a non experimental
+ # section directly
+ if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
then
- # Symbols that are getting added in a section
- # other than the experimental section
- # to be moving from an already supported
- # section or its a violation
- grep -q \
- "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
- if [ $? -ne 0 ]
- 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
- fi
+ 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
+
+ # This symbol is moving between two sections (the
+ # original section is not experimental).
+ # This can be legit, just warn.
+ if [ "$oldsecname" != 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname is being "
+ echo -n "moved from $oldsecname to $secname. "
+ echo -n "Ensure that it has gone through the "
+ echo "deprecation process"
+ continue
fi
else
- if [ "$secname" != "EXPERIMENTAL" ]
+ if ! grep -q "$mname $symname .* add" "$mapdb" && \
+ [ "$secname" != "EXPERIMENTAL" ]
then
# Just inform users that non-experimenal
# symbols need to go through a deprecation
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
@ 2019-04-05 8:30 4% ` Thomas Monjalon
2019-04-05 8:30 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-05 8:30 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable, Olivier Matz
19/03/2019 18:19, Neil Horman:
> On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> > The doc examples are not aligned on the script following the
> > incriminated commit.
> >
> > Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> > Cc: stable@dpdk.org
> >
> > Cc: Olivier Matz <olivier.matz@6wind.com>
> > Cc: Neil Horman <nhorman@tuxdriver.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
2019-04-05 8:30 4% ` Thomas Monjalon
@ 2019-04-05 8:30 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-05 8:30 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable, Olivier Matz
19/03/2019 18:19, Neil Horman:
> On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> > The doc examples are not aligned on the script following the
> > incriminated commit.
> >
> > Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> > Cc: stable@dpdk.org
> >
> > Cc: Olivier Matz <olivier.matz@6wind.com>
> > Cc: Neil Horman <nhorman@tuxdriver.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
@ 2019-04-05 9:05 3% Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev
---
v5:
1. add ABI break notification in commit log of PATCH 1/5
2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
comments)
V4:
1. rebased to the latest code.
2. deleted misleading statement.
V3:
1. fixed issue in release note.
2. fixed check patch issue.
3. spilted eal related change to a new patch.
V2:
1. move testpmd related changes to a new patch.
2. added release note update.
Qiming Yang (5):
ethdev: add VXLAN-GPE macro
net/i40e: add support for VXLAN-GPE
net/i40e: support VXLAN-GPE classification
app/testpmd: add VXLAN-GPE to tunnel type
doc: add release note for VXLAN-GPE support
app/test-pmd/cmdline.c | 19 ++++++++++++-------
doc/guides/rel_notes/release_19_05.rst | 7 +++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 +++++++----
drivers/net/i40e/i40e_ethdev.c | 16 ++++++++++++----
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
5 files changed, 39 insertions(+), 15 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
@ 2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2 siblings, 2 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev, Qiming Yang
From: Qiming Yang <qiming.yang@intel.com>
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
problem when running with new version of the ethdev shared
library.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae24c..b3416341b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NVGRE,
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
+ RTE_TUNNEL_TYPE_VXLAN_GPE,
RTE_TUNNEL_TYPE_MAX,
};
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
@ 2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev
---
v5:
1. add ABI break notification in commit log of PATCH 1/5
2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
comments)
V4:
1. rebased to the latest code.
2. deleted misleading statement.
V3:
1. fixed issue in release note.
2. fixed check patch issue.
3. spilted eal related change to a new patch.
V2:
1. move testpmd related changes to a new patch.
2. added release note update.
Qiming Yang (5):
ethdev: add VXLAN-GPE macro
net/i40e: add support for VXLAN-GPE
net/i40e: support VXLAN-GPE classification
app/testpmd: add VXLAN-GPE to tunnel type
doc: add release note for VXLAN-GPE support
app/test-pmd/cmdline.c | 19 ++++++++++++-------
doc/guides/rel_notes/release_19_05.rst | 7 +++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 +++++++----
drivers/net/i40e/i40e_ethdev.c | 16 ++++++++++++----
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
5 files changed, 39 insertions(+), 15 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
@ 2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:36 3% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev, Qiming Yang
From: Qiming Yang <qiming.yang@intel.com>
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
problem when running with new version of the ethdev shared
library.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae24c..b3416341b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NVGRE,
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
+ RTE_TUNNEL_TYPE_VXLAN_GPE,
RTE_TUNNEL_TYPE_MAX,
};
--
2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
@ 2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:42 3% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-05 9:36 UTC (permalink / raw)
To: Zhang, Qi Z, Yigit, Ferruh, Zhang, Qi Z, Iremonger, Bernard
Cc: dev, Yang, Qiming
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> Sent: Friday, April 5, 2019 10:06 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>
> From: Qiming Yang <qiming.yang@intel.com>
>
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> problem when running with new version of the ethdev shared
> library.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae24c..b3416341b 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
Not sure, why do you consider it as an ABI breakage?
Konstantin
> RTE_TUNNEL_TYPE_MAX,
> };
>
> --
> 2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:36 3% ` Ananyev, Konstantin
@ 2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:42 3% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-05 9:36 UTC (permalink / raw)
To: Zhang, Qi Z, Yigit, Ferruh, Zhang, Qi Z, Iremonger, Bernard
Cc: dev, Yang, Qiming
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> Sent: Friday, April 5, 2019 10:06 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>
> From: Qiming Yang <qiming.yang@intel.com>
>
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> problem when running with new version of the ethdev shared
> library.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae24c..b3416341b 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
Not sure, why do you consider it as an ABI breakage?
Konstantin
> RTE_TUNNEL_TYPE_MAX,
> };
>
> --
> 2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:36 3% ` Ananyev, Konstantin
@ 2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 10:37 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 9:42 UTC (permalink / raw)
To: Ananyev, Konstantin, Zhang, Qi Z, Iremonger, Bernard; +Cc: dev, Yang, Qiming
On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>> Sent: Friday, April 5, 2019 10:06 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
>> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
>> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>>
>> From: Qiming Yang <qiming.yang@intel.com>
>>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>> problem when running with new version of the ethdev shared
>> library.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae24c..b3416341b 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>
> Not sure, why do you consider it as an ABI breakage?
I think it is API breakage instead of ABI.
This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
If the application is using the MAX enum item, with the new version of the
ethdev the MAX value will be different and this can break the app.
Like:
app_function(..) {
ret = lib_foo()
if (ret == RTE_TUNNEL_TYPE_MAX)
ret -1;
}
lib_foo(..) {
return RTE_TUNNEL_TYPE_MAX;
}
When app compiled, MAX was '7' and app is comparing ret value against '7', but
with new version of DPDK, 'lib_foo()' will return '8' instead.
> Konstantin
>
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>> --
>> 2.13.6
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:42 3% ` Ferruh Yigit
@ 2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 10:37 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 9:42 UTC (permalink / raw)
To: Ananyev, Konstantin, Zhang, Qi Z, Iremonger, Bernard; +Cc: dev, Yang, Qiming
On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>> Sent: Friday, April 5, 2019 10:06 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
>> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
>> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>>
>> From: Qiming Yang <qiming.yang@intel.com>
>>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>> problem when running with new version of the ethdev shared
>> library.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae24c..b3416341b 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>
> Not sure, why do you consider it as an ABI breakage?
I think it is API breakage instead of ABI.
This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
If the application is using the MAX enum item, with the new version of the
ethdev the MAX value will be different and this can break the app.
Like:
app_function(..) {
ret = lib_foo()
if (ret == RTE_TUNNEL_TYPE_MAX)
ret -1;
}
lib_foo(..) {
return RTE_TUNNEL_TYPE_MAX;
}
When app compiled, MAX was '7' and app is comparing ret value against '7', but
with new version of DPDK, 'lib_foo()' will return '8' instead.
> Konstantin
>
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>> --
>> 2.13.6
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 9:42 3% ` Ferruh Yigit
@ 2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 11:12 3% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-05 10:37 UTC (permalink / raw)
To: Ferruh Yigit, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
Hi,
Sorry for not catching it before, but I was not Cc.
Please use git send-email --to-cmd devtools/get-maintainer.sh
05/04/2019 11:42, Ferruh Yigit:
> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> >> From: Qiming Yang <qiming.yang@intel.com>
> >>
> >> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> >> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> >> problem when running with new version of the ethdev shared
> >> library.
> >>
> >> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> >> ---
[...]
> >> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> >> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> >> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> >> RTE_TUNNEL_TYPE_NVGRE,
> >> RTE_TUNNEL_TYPE_IP_IN_GRE,
> >> RTE_L2_TUNNEL_TYPE_E_TAG,
> >> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> >
> > Not sure, why do you consider it as an ABI breakage?
>
> I think it is API breakage instead of ABI.
>
> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
> If the application is using the MAX enum item, with the new version of the
> ethdev the MAX value will be different and this can break the app.
>
> Like:
>
> app_function(..) {
> ret = lib_foo()
> if (ret == RTE_TUNNEL_TYPE_MAX)
> ret -1;
> }
>
> lib_foo(..) {
> return RTE_TUNNEL_TYPE_MAX;
> }
>
>
> When app compiled, MAX was '7' and app is comparing ret value against '7', but
> with new version of DPDK, 'lib_foo()' will return '8' instead.
I would vote for ABI because it is a value change.
Anyway, it must be noticed in the release notes.
As we are already breaking ethdev ABI in this release,
and it is a very basic change, I agree to accept it in 19.05.
In future, we should make sure that such addition is possible
without any breakage.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 10:37 4% ` Thomas Monjalon
@ 2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 11:12 3% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-05 10:37 UTC (permalink / raw)
To: Ferruh Yigit, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
Hi,
Sorry for not catching it before, but I was not Cc.
Please use git send-email --to-cmd devtools/get-maintainer.sh
05/04/2019 11:42, Ferruh Yigit:
> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> >> From: Qiming Yang <qiming.yang@intel.com>
> >>
> >> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> >> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> >> problem when running with new version of the ethdev shared
> >> library.
> >>
> >> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> >> ---
[...]
> >> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> >> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> >> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> >> RTE_TUNNEL_TYPE_NVGRE,
> >> RTE_TUNNEL_TYPE_IP_IN_GRE,
> >> RTE_L2_TUNNEL_TYPE_E_TAG,
> >> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> >
> > Not sure, why do you consider it as an ABI breakage?
>
> I think it is API breakage instead of ABI.
>
> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
> If the application is using the MAX enum item, with the new version of the
> ethdev the MAX value will be different and this can break the app.
>
> Like:
>
> app_function(..) {
> ret = lib_foo()
> if (ret == RTE_TUNNEL_TYPE_MAX)
> ret -1;
> }
>
> lib_foo(..) {
> return RTE_TUNNEL_TYPE_MAX;
> }
>
>
> When app compiled, MAX was '7' and app is comparing ret value against '7', but
> with new version of DPDK, 'lib_foo()' will return '8' instead.
I would vote for ABI because it is a value change.
Anyway, it must be noticed in the release notes.
As we are already breaking ethdev ABI in this release,
and it is a very basic change, I agree to accept it in 19.05.
In future, we should make sure that such addition is possible
without any breakage.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 10:37 4% ` Thomas Monjalon
@ 2019-04-05 11:12 3% ` Ferruh Yigit
2019-04-05 11:12 3% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:12 UTC (permalink / raw)
To: Thomas Monjalon, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
On 4/5/2019 11:37 AM, Thomas Monjalon wrote:
> Hi,
>
> Sorry for not catching it before, but I was not Cc.
> Please use git send-email --to-cmd devtools/get-maintainer.sh
>
> 05/04/2019 11:42, Ferruh Yigit:
>> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>>>> From: Qiming Yang <qiming.yang@intel.com>
>>>>
>>>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>>>> problem when running with new version of the ethdev shared
>>>> library.
>>>>
>>>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>>>> ---
> [...]
>>>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>>>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>>>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>>>> RTE_TUNNEL_TYPE_NVGRE,
>>>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>> RTE_L2_TUNNEL_TYPE_E_TAG,
>>>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>
>>> Not sure, why do you consider it as an ABI breakage?
>>
>> I think it is API breakage instead of ABI.
>>
>> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
>> If the application is using the MAX enum item, with the new version of the
>> ethdev the MAX value will be different and this can break the app.
>>
>> Like:
>>
>> app_function(..) {
>> ret = lib_foo()
>> if (ret == RTE_TUNNEL_TYPE_MAX)
>> ret -1;
>> }
>>
>> lib_foo(..) {
>> return RTE_TUNNEL_TYPE_MAX;
>> }
>>
>>
>> When app compiled, MAX was '7' and app is comparing ret value against '7', but
>> with new version of DPDK, 'lib_foo()' will return '8' instead.
>
> I would vote for ABI because it is a value change.
>
> Anyway, it must be noticed in the release notes.
>
> As we are already breaking ethdev ABI in this release,
> and it is a very basic change, I agree to accept it in 19.05.
+1
>
> In future, we should make sure that such addition is possible
> without any breakage.
+1. Otherwise there is no escape from it and adding a new tunnel type shouldn't
cause and ABI/API breakage.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 11:12 3% ` Ferruh Yigit
@ 2019-04-05 11:12 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:12 UTC (permalink / raw)
To: Thomas Monjalon, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
On 4/5/2019 11:37 AM, Thomas Monjalon wrote:
> Hi,
>
> Sorry for not catching it before, but I was not Cc.
> Please use git send-email --to-cmd devtools/get-maintainer.sh
>
> 05/04/2019 11:42, Ferruh Yigit:
>> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>>>> From: Qiming Yang <qiming.yang@intel.com>
>>>>
>>>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>>>> problem when running with new version of the ethdev shared
>>>> library.
>>>>
>>>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>>>> ---
> [...]
>>>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>>>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>>>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>>>> RTE_TUNNEL_TYPE_NVGRE,
>>>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>> RTE_L2_TUNNEL_TYPE_E_TAG,
>>>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>
>>> Not sure, why do you consider it as an ABI breakage?
>>
>> I think it is API breakage instead of ABI.
>>
>> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
>> If the application is using the MAX enum item, with the new version of the
>> ethdev the MAX value will be different and this can break the app.
>>
>> Like:
>>
>> app_function(..) {
>> ret = lib_foo()
>> if (ret == RTE_TUNNEL_TYPE_MAX)
>> ret -1;
>> }
>>
>> lib_foo(..) {
>> return RTE_TUNNEL_TYPE_MAX;
>> }
>>
>>
>> When app compiled, MAX was '7' and app is comparing ret value against '7', but
>> with new version of DPDK, 'lib_foo()' will return '8' instead.
>
> I would vote for ABI because it is a value change.
>
> Anyway, it must be noticed in the release notes.
>
> As we are already breaking ethdev ABI in this release,
> and it is a very basic change, I agree to accept it in 19.05.
+1
>
> In future, we should make sure that such addition is possible
> without any breakage.
+1. Otherwise there is no escape from it and adding a new tunnel type shouldn't
cause and ABI/API breakage.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 8:17 4% [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
2019-04-05 8:17 4% ` David Marchand
@ 2019-04-05 11:22 0% ` Neil Horman
2019-04-05 11:22 0% ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Neil Horman @ 2019-04-05 11:22 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stable
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>
> ---
> devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 020da7e..40eb953 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -105,27 +105,37 @@ check_for_rule_violations()
> continue
> fi
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + oldsecname=$(sed -n \
> + "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
> +
> + # A symbol can not enter a non experimental
> + # section directly
> + if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
> then
> - # Symbols that are getting added in a section
> - # other than the experimental section
> - # to be moving from an already supported
> - # section or its a violation
> - grep -q \
> - "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
> - if [ $? -ne 0 ]
> - 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
> - fi
> + 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
> +
> + # This symbol is moving between two sections (the
> + # original section is not experimental).
> + # This can be legit, just warn.
> + if [ "$oldsecname" != 'EXPERIMENTAL' ]
> + then
> + echo -n "INFO: symbol $symname is being "
> + echo -n "moved from $oldsecname to $secname. "
> + echo -n "Ensure that it has gone through the "
> + echo "deprecation process"
> + continue
> fi
> else
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + if ! grep -q "$mname $symname .* add" "$mapdb" && \
> + [ "$secname" != "EXPERIMENTAL" ]
> then
> # Just inform users that non-experimenal
> # symbols need to go through a deprecation
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 11:22 0% ` Neil Horman
@ 2019-04-05 11:22 0% ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-05 11:22 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stable
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>
> ---
> devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 020da7e..40eb953 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -105,27 +105,37 @@ check_for_rule_violations()
> continue
> fi
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + oldsecname=$(sed -n \
> + "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
> +
> + # A symbol can not enter a non experimental
> + # section directly
> + if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
> then
> - # Symbols that are getting added in a section
> - # other than the experimental section
> - # to be moving from an already supported
> - # section or its a violation
> - grep -q \
> - "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
> - if [ $? -ne 0 ]
> - 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
> - fi
> + 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
> +
> + # This symbol is moving between two sections (the
> + # original section is not experimental).
> + # This can be legit, just warn.
> + if [ "$oldsecname" != 'EXPERIMENTAL' ]
> + then
> + echo -n "INFO: symbol $symname is being "
> + echo -n "moved from $oldsecname to $secname. "
> + echo -n "Ensure that it has gone through the "
> + echo "deprecation process"
> + continue
> fi
> else
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + if ! grep -q "$mname $symname .* add" "$mapdb" && \
> + [ "$secname" != "EXPERIMENTAL" ]
> then
> # Just inform users that non-experimenal
> # symbols need to go through a deprecation
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
@ 2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
2 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:31 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 10:05 AM, Qi Zhang wrote:
> ---
> v5:
> 1. add ABI break notification in commit log of PATCH 1/5
> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
> comments)
>
> V4:
> 1. rebased to the latest code.
> 2. deleted misleading statement.
>
> V3:
> 1. fixed issue in release note.
> 2. fixed check patch issue.
> 3. spilted eal related change to a new patch.
>
> V2:
> 1. move testpmd related changes to a new patch.
> 2. added release note update.
>
>
> Qiming Yang (5):
> ethdev: add VXLAN-GPE macro
> net/i40e: add support for VXLAN-GPE
> net/i40e: support VXLAN-GPE classification
> app/testpmd: add VXLAN-GPE to tunnel type
> doc: add release note for VXLAN-GPE support
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
@ 2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:31 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 10:05 AM, Qi Zhang wrote:
> ---
> v5:
> 1. add ABI break notification in commit log of PATCH 1/5
> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
> comments)
>
> V4:
> 1. rebased to the latest code.
> 2. deleted misleading statement.
>
> V3:
> 1. fixed issue in release note.
> 2. fixed check patch issue.
> 3. spilted eal related change to a new patch.
>
> V2:
> 1. move testpmd related changes to a new patch.
> 2. added release note update.
>
>
> Qiming Yang (5):
> ethdev: add VXLAN-GPE macro
> net/i40e: add support for VXLAN-GPE
> net/i40e: support VXLAN-GPE classification
> app/testpmd: add VXLAN-GPE to tunnel type
> doc: add release note for VXLAN-GPE support
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2019-04-05 11:31 0% ` Ferruh Yigit
@ 2019-04-05 11:40 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:40 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 12:31 PM, Ferruh Yigit wrote:
> On 4/5/2019 10:05 AM, Qi Zhang wrote:
>> ---
>> v5:
>> 1. add ABI break notification in commit log of PATCH 1/5
>> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
>> comments)
>>
>> V4:
>> 1. rebased to the latest code.
>> 2. deleted misleading statement.
>>
>> V3:
>> 1. fixed issue in release note.
>> 2. fixed check patch issue.
>> 3. spilted eal related change to a new patch.
>>
>> V2:
>> 1. move testpmd related changes to a new patch.
>> 2. added release note update.
>>
>>
>> Qiming Yang (5):
>> ethdev: add VXLAN-GPE macro
>> net/i40e: add support for VXLAN-GPE
>> net/i40e: support VXLAN-GPE classification
>> app/testpmd: add VXLAN-GPE to tunnel type
>> doc: add release note for VXLAN-GPE support
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 11:40 0% ` Ferruh Yigit
@ 2019-04-05 11:40 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:40 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 12:31 PM, Ferruh Yigit wrote:
> On 4/5/2019 10:05 AM, Qi Zhang wrote:
>> ---
>> v5:
>> 1. add ABI break notification in commit log of PATCH 1/5
>> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
>> comments)
>>
>> V4:
>> 1. rebased to the latest code.
>> 2. deleted misleading statement.
>>
>> V3:
>> 1. fixed issue in release note.
>> 2. fixed check patch issue.
>> 3. spilted eal related change to a new patch.
>>
>> V2:
>> 1. move testpmd related changes to a new patch.
>> 2. added release note update.
>>
>>
>> Qiming Yang (5):
>> ethdev: add VXLAN-GPE macro
>> net/i40e: add support for VXLAN-GPE
>> net/i40e: support VXLAN-GPE classification
>> app/testpmd: add VXLAN-GPE to tunnel type
>> doc: add release note for VXLAN-GPE support
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:10 8% ` Bruce Richardson
@ 2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:25 UTC (permalink / raw)
To: Bruce Richardson
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On 04/04/2019 14:10, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>>
>>
>> On 04/04/2019 13:02, Luca Boccassi wrote:
>>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>
> I would be too, with certain exceptions - rte_mbuf for one. Any structures
> that are used by applications cannot be made opaque, as apps do not want to
> pay the cost of having to call a function every time they want to access
> something from one of those structures.
These the layout of these structures really must become sacrosanct.
As Stephen points out, there may be room for a one more change - fool me
once - to future poof the structure but after, that these structure will
become very hard to change.
>
> Thankfully for us, we have plenty of other structures that we can work on
> in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> we work through those first, allowing us to hone our ABI-break avoidance
> skills.
>
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:25 4% ` Ray Kinsella
@ 2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:25 UTC (permalink / raw)
To: Bruce Richardson
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On 04/04/2019 14:10, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>>
>>
>> On 04/04/2019 13:02, Luca Boccassi wrote:
>>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>
> I would be too, with certain exceptions - rte_mbuf for one. Any structures
> that are used by applications cannot be made opaque, as apps do not want to
> pay the cost of having to call a function every time they want to access
> something from one of those structures.
These the layout of these structures really must become sacrosanct.
As Stephen points out, there may be room for a one more change - fool me
once - to future poof the structure but after, that these structure will
become very hard to change.
>
> Thankfully for us, we have plenty of other structures that we can work on
> in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> we work through those first, allowing us to hone our ABI-break avoidance
> skills.
>
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 20:13 8% ` Kevin Traynor
@ 2019-04-05 13:29 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-05 13:29 UTC (permalink / raw)
To: Wiles, Keith, Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:29 4% ` Ray Kinsella
@ 2019-04-05 13:29 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:29 UTC (permalink / raw)
To: Wiles, Keith, Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-04 20:13 8% ` Kevin Traynor
@ 2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:30 4% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-05 13:30 UTC (permalink / raw)
To: Kevin Traynor, Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 21:13, Kevin Traynor wrote:
> On 04/04/2019 20:08, Wiles, Keith wrote:
>>
>>
>>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>>
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>> <snip>
>>>
>>>>
>>>> My thoughts on the matter are:
>>>> 1. I think we really need to do work to start hiding more of our data
>>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>>> the scope for ABI breaks.
>>>> 2. Once done, I think we should commit to having an ABI break only in the
>>>> rarest of circumstances, and only with very large justification. I want us
>>>> to get to the point where DPDK releases can immediately be picked up by all
>>>> linux distros and rolled out because they are ABI compatible.
>>>>
>>>
>>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>>> APIs at transition from experimental to core). Just as a way to get more
>>> eyeballs and scrutiny on them.
>>
>> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>>
>
> We'll only find out if they are bad when they need ABI breaks later :-)
>
> My point is a good way to avoid future ABI breaks is to have more
> reviews on the APIs in the first place. Techboard approval might be one
> way, or 3 acks or something else.
+1 on this ... an API break should invite a higher level of scrutiny.
>
>>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>>> me as a plan where we end up with the same number of ABI breaks as before,
>>>> just balled into one release.
>>>>
>>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>>> case that each distro will only ship one version of DPDK, or is it possible
>>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>>
>>>
>>> It would probably double validation and maintenance, so it would require
>>> a lot of extra effort.
>>>
>>>>
>>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>>> similar.
>>>>
>>>> Regards,
>>>> /Bruce
>>>>
>>>
>>
>> Regards,
>> Keith
>>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:30 4% ` Ray Kinsella
@ 2019-04-05 13:30 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:30 UTC (permalink / raw)
To: Kevin Traynor, Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 21:13, Kevin Traynor wrote:
> On 04/04/2019 20:08, Wiles, Keith wrote:
>>
>>
>>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>>
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>> <snip>
>>>
>>>>
>>>> My thoughts on the matter are:
>>>> 1. I think we really need to do work to start hiding more of our data
>>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>>> the scope for ABI breaks.
>>>> 2. Once done, I think we should commit to having an ABI break only in the
>>>> rarest of circumstances, and only with very large justification. I want us
>>>> to get to the point where DPDK releases can immediately be picked up by all
>>>> linux distros and rolled out because they are ABI compatible.
>>>>
>>>
>>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>>> APIs at transition from experimental to core). Just as a way to get more
>>> eyeballs and scrutiny on them.
>>
>> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>>
>
> We'll only find out if they are bad when they need ABI breaks later :-)
>
> My point is a good way to avoid future ABI breaks is to have more
> reviews on the APIs in the first place. Techboard approval might be one
> way, or 3 acks or something else.
+1 on this ... an API break should invite a higher level of scrutiny.
>
>>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>>> me as a plan where we end up with the same number of ABI breaks as before,
>>>> just balled into one release.
>>>>
>>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>>> case that each distro will only ship one version of DPDK, or is it possible
>>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>>
>>>
>>> It would probably double validation and maintenance, so it would require
>>> a lot of extra effort.
>>>
>>>>
>>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>>> similar.
>>>>
>>>> Regards,
>>>> /Bruce
>>>>
>>>
>>
>> Regards,
>> Keith
>>
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] power: fix non thread-safe power env modification
@ 2019-04-05 14:35 4% ` Hajkowski
2019-04-05 14:35 4% ` Hajkowski
0 siblings, 1 reply; 200+ results
From: Hajkowski @ 2019-04-05 14:35 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable, Anatoly Burakov
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] power: fix non thread-safe power env modification
2019-04-05 14:35 4% ` [dpdk-dev] [PATCH] " Hajkowski
@ 2019-04-05 14:35 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-04-05 14:35 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable, Anatoly Burakov
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
@ 2019-04-05 20:30 3% Stephen Hemminger
2019-04-05 20:30 3% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-05 20:30 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The symbols in the EXPERIMENTAL were close to alphabetic
order but running sort showed several mistakes.
This has no impact on code, API, ABI or otherwise.
Purely for humans.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/rte_eal_version.map | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..33f2c303a361 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -277,6 +277,14 @@ EXPERIMENTAL {
rte_class_unregister;
rte_ctrl_thread_create;
rte_delay_us_sleep;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dev_dma_map;
rte_dev_dma_unmap;
rte_dev_event_callback_process;
@@ -289,14 +297,6 @@ EXPERIMENTAL {
rte_dev_is_probed;
rte_dev_iterator_init;
rte_dev_iterator_next;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
rte_eal_cleanup;
rte_extmem_attach;
rte_extmem_detach;
@@ -306,19 +306,19 @@ EXPERIMENTAL {
rte_fbarray_destroy;
rte_fbarray_detach;
rte_fbarray_dump_metadata;
- rte_fbarray_find_idx;
rte_fbarray_find_biggest_free;
rte_fbarray_find_biggest_used;
+ rte_fbarray_find_contig_free;
+ rte_fbarray_find_contig_used;
+ rte_fbarray_find_idx;
rte_fbarray_find_next_free;
- rte_fbarray_find_next_used;
rte_fbarray_find_next_n_free;
rte_fbarray_find_next_n_used;
+ rte_fbarray_find_next_used;
rte_fbarray_find_prev_free;
- rte_fbarray_find_prev_used;
rte_fbarray_find_prev_n_free;
rte_fbarray_find_prev_n_used;
- rte_fbarray_find_contig_free;
- rte_fbarray_find_contig_used;
+ rte_fbarray_find_prev_used;
rte_fbarray_find_rev_biggest_free;
rte_fbarray_find_rev_biggest_used;
rte_fbarray_find_rev_contig_free;
@@ -346,24 +346,24 @@ EXPERIMENTAL {
rte_mem_event_callback_register;
rte_mem_event_callback_unregister;
rte_mem_iova2virt;
- rte_mem_set_dma_mask;
- rte_mem_virt2memseg;
- rte_mem_virt2memseg_list;
rte_memseg_contig_walk;
rte_memseg_contig_walk_thread_unsafe;
rte_memseg_get_fd;
rte_memseg_get_fd_offset;
- rte_memseg_get_fd_thread_unsafe;
rte_memseg_get_fd_offset_thread_unsafe;
+ rte_memseg_get_fd_thread_unsafe;
rte_memseg_list_walk;
rte_memseg_list_walk_thread_unsafe;
rte_memseg_walk;
rte_memseg_walk_thread_unsafe;
+ rte_mem_set_dma_mask;
+ rte_mem_virt2memseg;
+ rte_mem_virt2memseg_list;
rte_mp_action_register;
rte_mp_action_unregister;
rte_mp_reply;
- rte_mp_request_sync;
rte_mp_request_async;
+ rte_mp_request_sync;
rte_mp_sendmsg;
rte_option_register;
rte_realloc_socket;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
2019-04-05 20:30 3% [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
@ 2019-04-05 20:30 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-05 20:30 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The symbols in the EXPERIMENTAL were close to alphabetic
order but running sort showed several mistakes.
This has no impact on code, API, ABI or otherwise.
Purely for humans.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/rte_eal_version.map | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..33f2c303a361 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -277,6 +277,14 @@ EXPERIMENTAL {
rte_class_unregister;
rte_ctrl_thread_create;
rte_delay_us_sleep;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dev_dma_map;
rte_dev_dma_unmap;
rte_dev_event_callback_process;
@@ -289,14 +297,6 @@ EXPERIMENTAL {
rte_dev_is_probed;
rte_dev_iterator_init;
rte_dev_iterator_next;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
rte_eal_cleanup;
rte_extmem_attach;
rte_extmem_detach;
@@ -306,19 +306,19 @@ EXPERIMENTAL {
rte_fbarray_destroy;
rte_fbarray_detach;
rte_fbarray_dump_metadata;
- rte_fbarray_find_idx;
rte_fbarray_find_biggest_free;
rte_fbarray_find_biggest_used;
+ rte_fbarray_find_contig_free;
+ rte_fbarray_find_contig_used;
+ rte_fbarray_find_idx;
rte_fbarray_find_next_free;
- rte_fbarray_find_next_used;
rte_fbarray_find_next_n_free;
rte_fbarray_find_next_n_used;
+ rte_fbarray_find_next_used;
rte_fbarray_find_prev_free;
- rte_fbarray_find_prev_used;
rte_fbarray_find_prev_n_free;
rte_fbarray_find_prev_n_used;
- rte_fbarray_find_contig_free;
- rte_fbarray_find_contig_used;
+ rte_fbarray_find_prev_used;
rte_fbarray_find_rev_biggest_free;
rte_fbarray_find_rev_biggest_used;
rte_fbarray_find_rev_contig_free;
@@ -346,24 +346,24 @@ EXPERIMENTAL {
rte_mem_event_callback_register;
rte_mem_event_callback_unregister;
rte_mem_iova2virt;
- rte_mem_set_dma_mask;
- rte_mem_virt2memseg;
- rte_mem_virt2memseg_list;
rte_memseg_contig_walk;
rte_memseg_contig_walk_thread_unsafe;
rte_memseg_get_fd;
rte_memseg_get_fd_offset;
- rte_memseg_get_fd_thread_unsafe;
rte_memseg_get_fd_offset_thread_unsafe;
+ rte_memseg_get_fd_thread_unsafe;
rte_memseg_list_walk;
rte_memseg_list_walk_thread_unsafe;
rte_memseg_walk;
rte_memseg_walk_thread_unsafe;
+ rte_mem_set_dma_mask;
+ rte_mem_virt2memseg;
+ rte_mem_virt2memseg_list;
rte_mp_action_register;
rte_mp_action_unregister;
rte_mp_reply;
- rte_mp_request_sync;
rte_mp_request_async;
+ rte_mp_request_sync;
rte_mp_sendmsg;
rte_option_register;
rte_realloc_socket;
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
@ 2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:37 UTC (permalink / raw)
To: techboard
Cc: Ray Kinsella, Bruce Richardson, Luca Boccassi, Burakov, Anatoly,
dev, Kevin Traynor
05/04/2019 15:25, Ray Kinsella:
> On 04/04/2019 14:10, Bruce Richardson wrote:
> > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> >> On 04/04/2019 13:02, Luca Boccassi wrote:
> >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >>
> > I would be too, with certain exceptions - rte_mbuf for one. Any structures
> > that are used by applications cannot be made opaque, as apps do not want to
> > pay the cost of having to call a function every time they want to access
> > something from one of those structures.
>
> These the layout of these structures really must become sacrosanct.
> As Stephen points out, there may be room for a one more change - fool me
> once - to future poof the structure but after, that these structure will
> become very hard to change.
Yes, looks like a good plan.
> > Thankfully for us, we have plenty of other structures that we can work on
> > in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> > we work through those first, allowing us to hone our ABI-break avoidance
> > skills.
+1 to work on obvious cases first.
I think we should not wait too much to improve mbuf
with some dynamically registered fields, because it may be
long to achieve such an important feature and make everybody happy.
Note: we may have to sacrifice a few cycles for some features
like distributor or IPsec.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:37 4% ` Thomas Monjalon
@ 2019-04-07 9:37 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:37 UTC (permalink / raw)
To: techboard
Cc: Ray Kinsella, Bruce Richardson, Luca Boccassi, Burakov, Anatoly,
dev, Kevin Traynor
05/04/2019 15:25, Ray Kinsella:
> On 04/04/2019 14:10, Bruce Richardson wrote:
> > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> >> On 04/04/2019 13:02, Luca Boccassi wrote:
> >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >>
> > I would be too, with certain exceptions - rte_mbuf for one. Any structures
> > that are used by applications cannot be made opaque, as apps do not want to
> > pay the cost of having to call a function every time they want to access
> > something from one of those structures.
>
> These the layout of these structures really must become sacrosanct.
> As Stephen points out, there may be room for a one more change - fool me
> once - to future poof the structure but after, that these structure will
> become very hard to change.
Yes, looks like a good plan.
> > Thankfully for us, we have plenty of other structures that we can work on
> > in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> > we work through those first, allowing us to hone our ABI-break avoidance
> > skills.
+1 to work on obvious cases first.
I think we should not wait too much to improve mbuf
with some dynamically registered fields, because it may be
long to achieve such an important feature and make everybody happy.
Note: we may have to sacrifice a few cycles for some features
like distributor or IPsec.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 14:07 9% ` Burakov, Anatoly
@ 2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:48 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: techboard, Ray Kinsella, Bruce Richardson, dev, Kevin Traynor
04/04/2019 16:07, Burakov, Anatoly:
> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > On 04/04/2019 11:54, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >> Actually, I think we *do* need to constrain the pace of development for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project - it
> >> should just start acting like it.
> >
> > I 100% agree.
> >
> > If you break your users stuff regularly enough, they will eventually
> > start looking around for an alternative that doesn't break their stuff
> > quiet so regularly.
> >
> > We often use the pace of innovation in DPDK as justification for ABI/API
> > breakages, but that approach is a real rarity among the Open Source
> > community. I can't think of any mature project off-hand that share's it.
> >
> > I would ask is Linux any less innovative because they offer a stable API
> > and have an absolute commitment to never breaking userspace? Would Linux
> > have ever been as popular as it is today it they broke userspace every
> > quarter?
> >
> > They reality is that they (Linux) find workarounds and compromise
> > because there is an uber-maintainer Linus who had a strong ethos from
> > the start not to break their users stuff - we need the same ethos in DPDK.
> >
> >>
> >> Now, in terms of features like the memory rework, that is indeed a case
> >> that there was no alternative other than a massive ABI break. However, for
> >> that rework there was a strong need for improvement in that area that we
> >> can make the case for an ABI break to support it - and it is of a scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are of
> >> that scale.
> >
> > I would also be inclined to agree with Bruce's points on memory rework
> > was somewhat of an outlier, we don't see many like it.
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should reduce
> >> the scope for ABI breaks.
> >> 2. Once done, I think we should commit to having an ABI break only in the
> >> rarest of circumstances, and only with very large justification. I want us
> >> to get to the point where DPDK releases can immediately be picked up by all
> >> linux distros and rolled out because they are ABI compatible.
> >
> > The work that Anatoly describes removing APIs that exposed internal
> > structures and Stephen H's RFC similarly are good examples of the kind
> > of work required to prepare for this change. We need to take a good look
> > at the API and reduce the number of unnecessary internal structures
> > exposed.
> >
> > I never expected it going to to be a big bang - but is a definite
> > direction we need to move towards over the next few release.
>
> ...in this case, we have to think long and hard about the fabled EAL
> rework/split, and in general *specifying* what is it that we want to
> support, and the use cases that we want to target. Right now there is a
> huge mountain of technical debt and kludges and workarounds that has
> accumulated over the years, and it exists precisely because "every
> change breaks someone's workflow".
>
> For example, just in memory subsystem alone, we have legacy mem, because
> some use cases require huge amounts of contiguous memory, and not
> everyone is using VFIO; there's all of the 32-bit related workarounds
> and hacks; there's the single-file-segments stuff that could have been
> the default if not for the fact that we support kernels that don't
> support fallocate(); there are two different ways of doing in-memory
> mode, because not all kernels support memfd's; there is a gargantuan
> pile of workarounds (and "known issues", and just code in general) all
> over the DPDK codebase just to support our multiprocess model and all of
> the various warts that come with it.
>
> In fact, i would even go as far as to say that *most* of EAL ABI breaks
> have been due to the fact that we store data in shared memory because of
> multiprocess - so there is simply no way we can change these internal
> data structures without ABI breaks, because even if they're not exposed
> through user-facing API, they are still exposed by virtue of secondary
> processes basically having an ABI contract with primary process instances.
>
> So, if we are to cement our core API - we have to make a concrete effort
> to specify what goes and what stays, if we want it to be maintainable.
> The DPDK 1.0 specification, if you will :)
"DPDK 1.0 specification", that's a great project name :-)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:48 4% ` Thomas Monjalon
@ 2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:48 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: techboard, Ray Kinsella, Bruce Richardson, dev, Kevin Traynor
04/04/2019 16:07, Burakov, Anatoly:
> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > On 04/04/2019 11:54, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >> Actually, I think we *do* need to constrain the pace of development for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project - it
> >> should just start acting like it.
> >
> > I 100% agree.
> >
> > If you break your users stuff regularly enough, they will eventually
> > start looking around for an alternative that doesn't break their stuff
> > quiet so regularly.
> >
> > We often use the pace of innovation in DPDK as justification for ABI/API
> > breakages, but that approach is a real rarity among the Open Source
> > community. I can't think of any mature project off-hand that share's it.
> >
> > I would ask is Linux any less innovative because they offer a stable API
> > and have an absolute commitment to never breaking userspace? Would Linux
> > have ever been as popular as it is today it they broke userspace every
> > quarter?
> >
> > They reality is that they (Linux) find workarounds and compromise
> > because there is an uber-maintainer Linus who had a strong ethos from
> > the start not to break their users stuff - we need the same ethos in DPDK.
> >
> >>
> >> Now, in terms of features like the memory rework, that is indeed a case
> >> that there was no alternative other than a massive ABI break. However, for
> >> that rework there was a strong need for improvement in that area that we
> >> can make the case for an ABI break to support it - and it is of a scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are of
> >> that scale.
> >
> > I would also be inclined to agree with Bruce's points on memory rework
> > was somewhat of an outlier, we don't see many like it.
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should reduce
> >> the scope for ABI breaks.
> >> 2. Once done, I think we should commit to having an ABI break only in the
> >> rarest of circumstances, and only with very large justification. I want us
> >> to get to the point where DPDK releases can immediately be picked up by all
> >> linux distros and rolled out because they are ABI compatible.
> >
> > The work that Anatoly describes removing APIs that exposed internal
> > structures and Stephen H's RFC similarly are good examples of the kind
> > of work required to prepare for this change. We need to take a good look
> > at the API and reduce the number of unnecessary internal structures
> > exposed.
> >
> > I never expected it going to to be a big bang - but is a definite
> > direction we need to move towards over the next few release.
>
> ...in this case, we have to think long and hard about the fabled EAL
> rework/split, and in general *specifying* what is it that we want to
> support, and the use cases that we want to target. Right now there is a
> huge mountain of technical debt and kludges and workarounds that has
> accumulated over the years, and it exists precisely because "every
> change breaks someone's workflow".
>
> For example, just in memory subsystem alone, we have legacy mem, because
> some use cases require huge amounts of contiguous memory, and not
> everyone is using VFIO; there's all of the 32-bit related workarounds
> and hacks; there's the single-file-segments stuff that could have been
> the default if not for the fact that we support kernels that don't
> support fallocate(); there are two different ways of doing in-memory
> mode, because not all kernels support memfd's; there is a gargantuan
> pile of workarounds (and "known issues", and just code in general) all
> over the DPDK codebase just to support our multiprocess model and all of
> the various warts that come with it.
>
> In fact, i would even go as far as to say that *most* of EAL ABI breaks
> have been due to the fact that we store data in shared memory because of
> multiprocess - so there is simply no way we can change these internal
> data structures without ABI breaks, because even if they're not exposed
> through user-facing API, they are still exposed by virtue of secondary
> processes basically having an ABI contract with primary process instances.
>
> So, if we are to cement our core API - we have to make a concrete effort
> to specify what goes and what stays, if we want it to be maintainable.
> The DPDK 1.0 specification, if you will :)
"DPDK 1.0 specification", that's a great project name :-)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
@ 2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 9:04 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 07/04/2019 10:48, Thomas Monjalon wrote:
> 04/04/2019 16:07, Burakov, Anatoly:
>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>> So, if we are to cement our core API - we have to make a concrete effort
>> to specify what goes and what stays, if we want it to be maintainable.
>> The DPDK 1.0 specification, if you will :)
>
> "DPDK 1.0 specification", that's a great project name :-)
>
Honestly - I would say that I am nervous of this.
The definition of a DPDK 1.0 specification as a gate to API stability,
feels like a "great plan tomorrow" instead of a "good plan" today. I
think that getting people to dedicate time to such a specification might
prove problematic and I could see this effort being very time consuming.
It might never get completed.
My preference would be to instead adopt a well-publicised community
timeline for adopting more conservative API maintenance rules.
Perhaps we could give ourselves as a community a time-limited window in
which to address concerns around the API before they become hardened -
perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
to 9 months.
We then would know the timeline when niggles like exposure of internal
structures and mbuf structure needed to be sorted by and could
prioritize accordingly.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
@ 2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-14 0:42 9% ` Neil Horman
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 9:04 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 07/04/2019 10:48, Thomas Monjalon wrote:
> 04/04/2019 16:07, Burakov, Anatoly:
>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>> So, if we are to cement our core API - we have to make a concrete effort
>> to specify what goes and what stays, if we want it to be maintainable.
>> The DPDK 1.0 specification, if you will :)
>
> "DPDK 1.0 specification", that's a great project name :-)
>
Honestly - I would say that I am nervous of this.
The definition of a DPDK 1.0 specification as a gate to API stability,
feels like a "great plan tomorrow" instead of a "good plan" today. I
think that getting people to dedicate time to such a specification might
prove problematic and I could see this effort being very time consuming.
It might never get completed.
My preference would be to instead adopt a well-publicised community
timeline for adopting more conservative API maintenance rules.
Perhaps we could give ourselves as a community a time-limited window in
which to address concerns around the API before they become hardened -
perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
to 9 months.
We then would know the timeline when niggles like exposure of internal
structures and mbuf structure needed to be sorted by and could
prioritize accordingly.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
@ 2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-14 0:42 9% ` Neil Horman
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 10:15 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
>> 04/04/2019 16:07, Burakov, Anatoly:
>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
>>> So, if we are to cement our core API - we have to make a concrete effort
>>> to specify what goes and what stays, if we want it to be maintainable.
>>> The DPDK 1.0 specification, if you will :)
>>
>> "DPDK 1.0 specification", that's a great project name :-)
>>
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
>
My worry here is that some API's get more attention than others, but
requirements for freezing the API/ABI are applicable to all of them.
Everyone loves discussing specifics of mbufs and dev API's, and I have
no doubt that DPDK community can arrive at a consensus with regards to
mbuf format etc. in a timely manner, since everyone has a vested
interest in those covering their use cases. I have way less confidence
in us possibly having saner and more maintainable platform
initialization code, simply because any attempt to change those will
likely be met with "please keep all of the old stuff working", which
gets us right back to where we started.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 10:15 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
>> 04/04/2019 16:07, Burakov, Anatoly:
>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
>>> So, if we are to cement our core API - we have to make a concrete effort
>>> to specify what goes and what stays, if we want it to be maintainable.
>>> The DPDK 1.0 specification, if you will :)
>>
>> "DPDK 1.0 specification", that's a great project name :-)
>>
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
>
My worry here is that some API's get more attention than others, but
requirements for freezing the API/ABI are applicable to all of them.
Everyone loves discussing specifics of mbufs and dev API's, and I have
no doubt that DPDK community can arrive at a consensus with regards to
mbuf format etc. in a timely manner, since everyone has a vested
interest in those covering their use cases. I have way less confidence
in us possibly having saner and more maintainable platform
initialization code, simply because any attempt to change those will
likely be met with "please keep all of the old stuff working", which
gets us right back to where we started.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 13:00 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 11:15, Burakov, Anatoly wrote:
> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>> [SNIP]
[SNIP]
>
> My worry here is that some API's get more attention than others, but
> requirements for freezing the API/ABI are applicable to all of them.
>
> Everyone loves discussing specifics of mbufs and dev API's, and I have
> no doubt that DPDK community can arrive at a consensus with regards to
> mbuf format etc. in a timely manner, since everyone has a vested
> interest in those covering their use cases.
> I have way less confidence
> in us possibly having saner and more maintainable platform
> initialization code,
I think you are right, however its that same lack of enthusiasm that
would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
specification effort becoming an endless process, as it would always be
low on DPDK contributors priority list.
Instead I recommend we set an API freeze date to focus peoples minds,
advertise what it means and contributors will respond and look after the
areas they care/are responsible for.
> simply because any attempt to change those will
> likely be met with "please keep all of the old stuff working", which
> gets us right back to where we started.
>
And to be honest that is a fair enough expectation from them, right?
To Stephen's if we need to break it, let's do it once more and then
never again.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:00 4% ` Ray Kinsella
@ 2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 13:00 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 11:15, Burakov, Anatoly wrote:
> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>> [SNIP]
[SNIP]
>
> My worry here is that some API's get more attention than others, but
> requirements for freezing the API/ABI are applicable to all of them.
>
> Everyone loves discussing specifics of mbufs and dev API's, and I have
> no doubt that DPDK community can arrive at a consensus with regards to
> mbuf format etc. in a timely manner, since everyone has a vested
> interest in those covering their use cases.
> I have way less confidence
> in us possibly having saner and more maintainable platform
> initialization code,
I think you are right, however its that same lack of enthusiasm that
would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
specification effort becoming an endless process, as it would always be
low on DPDK contributors priority list.
Instead I recommend we set an API freeze date to focus peoples minds,
advertise what it means and contributors will respond and look after the
areas they care/are responsible for.
> simply because any attempt to change those will
> likely be met with "please keep all of the old stuff working", which
> gets us right back to where we started.
>
And to be honest that is a fair enough expectation from them, right?
To Stephen's if we need to break it, let's do it once more and then
never again.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
@ 2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 13:38 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>
>
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
>
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
>
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
>
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
>
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
>
Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
specification" i don't mean there literally should be a document with a
formal specification :)
Rather, i'm thinking more along the lines of, let's take a look at what
we have, and think of ways we can reduce the amount of code and improve
things without causing major inconveniences to great majority of users.
As in, if we want to "break once more and then never again", then maybe
instead of small incremental fixes here and there, we could actually do
a more drastic change that keeps perhaps 90% users happy instead of
100%, but which reduces maintenance/validation effort from 100% down to 30%.
As a concrete proposal, my number one dream would be to see multiprocess
gone. I also recall desire for "DPDK to be more lightweight", and i
maintain that DPDK *cannot* be lightweight if we are to support
multiprocess - we can have one or the other, but not both. However,
realistically, i don't think dropping multiprocess is ever going to
happen - not only it is too entrenched in DPDK use cases, it is actually
quite useful despite its flaws.
However, what *could* be realistic is to trim down complexity in EAL
init and system code in general - to me (again, a concrete proposal!),
that would be dropping igb_uio and supporting upstream kernel modules
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
support and legacy mem modes, and perhaps bumping kernel version and
removing some compatibility code as well. This would remove potentially
thousands of lines of code and keep EAL cleaner and more maintainable:
right now, we have two different hotplug mechanisms (UIO and VFIO), lots
of different memory/interrupt modes, etc., for no reason that is readily
apparent to me.
So, as you can see, an effort to review and delineate what we want to
support would be necessary if we want to ease the maintenance burden for
either myself or anyone that inherits this code, as well as reducing the
number of moving parts and, as a consequence, validation effort and
amount of bugs. We can't simply do it in a random release "just
because", but if we were to "break once more and then never again",
perhaps this is something that could be considered.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
@ 2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 13:38 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>
>
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
>
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
>
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
>
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
>
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
>
Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
specification" i don't mean there literally should be a document with a
formal specification :)
Rather, i'm thinking more along the lines of, let's take a look at what
we have, and think of ways we can reduce the amount of code and improve
things without causing major inconveniences to great majority of users.
As in, if we want to "break once more and then never again", then maybe
instead of small incremental fixes here and there, we could actually do
a more drastic change that keeps perhaps 90% users happy instead of
100%, but which reduces maintenance/validation effort from 100% down to 30%.
As a concrete proposal, my number one dream would be to see multiprocess
gone. I also recall desire for "DPDK to be more lightweight", and i
maintain that DPDK *cannot* be lightweight if we are to support
multiprocess - we can have one or the other, but not both. However,
realistically, i don't think dropping multiprocess is ever going to
happen - not only it is too entrenched in DPDK use cases, it is actually
quite useful despite its flaws.
However, what *could* be realistic is to trim down complexity in EAL
init and system code in general - to me (again, a concrete proposal!),
that would be dropping igb_uio and supporting upstream kernel modules
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
support and legacy mem modes, and perhaps bumping kernel version and
removing some compatibility code as well. This would remove potentially
thousands of lines of code and keep EAL cleaner and more maintainable:
right now, we have two different hotplug mechanisms (UIO and VFIO), lots
of different memory/interrupt modes, etc., for no reason that is readily
apparent to me.
So, as you can see, an effort to review and delineate what we want to
support would be necessary if we want to ease the maintenance burden for
either myself or anyone that inherits this code, as well as reducing the
number of moving parts and, as a consequence, validation effort and
amount of bugs. We can't simply do it in a random release "just
because", but if we were to "break once more and then never again",
perhaps this is something that could be considered.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
@ 2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-04-08 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
Well, honestly, I'd like to hear about this.
What are the real usecases for multi process support?
Do we have even a single opensource project that uses it?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-08 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
Well, honestly, I'd like to hear about this.
What are the real usecases for multi process support?
Do we have even a single opensource project that uses it?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 14:02 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 2:58 PM, David Marchand wrote:
> On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> As a concrete proposal, my number one dream would be to see
> multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is
> actually
> quite useful despite its flaws.
>
>
> Well, honestly, I'd like to hear about this.
> What are the real usecases for multi process support?
> Do we have even a single opensource project that uses it?
>
I'm aware of a few closed source usages of multiprocess. I also think
current versions of collectd rely on secondary process (there's been a
Telemetry API added to avoid that, but AFAIK the support for Telemetry
is not upstream in collectd yet), and so do/would any dump-style
applications - in fact, we ourselves include one such application in our
codebase (pdump, proc-info, etc.).
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:02 4% ` Burakov, Anatoly
@ 2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 14:02 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 2:58 PM, David Marchand wrote:
> On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> As a concrete proposal, my number one dream would be to see
> multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is
> actually
> quite useful despite its flaws.
>
>
> Well, honestly, I'd like to hear about this.
> What are the real usecases for multi process support?
> Do we have even a single opensource project that uses it?
>
I'm aware of a few closed source usages of multiprocess. I also think
current versions of collectd rely on secondary process (there's been a
Telemetry API added to avoid that, but AFAIK the support for Telemetry
is not upstream in collectd yet), and so do/would any dump-style
applications - in fact, we ourselves include one such application in our
codebase (pdump, proc-info, etc.).
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
@ 2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: David Marchand @ 2019-04-08 14:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight", and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both. However,
> > realistically, i don't think dropping multiprocess is ever going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in our
> codebase (pdump, proc-info, etc.).
>
Sorry, I don't want to highjack this thread, I can start a separate thread
if people feel like it.
If we go with stabilisation, we must be careful that we want to support the
features.
So about multiprocess, again, in those closed source projects you know of,
what are the usecases?
For what we provide in dpdk pdump, proc-info, referring to oneself is not
that convincing to me as I don't use those tools.
I don't see what we could not achieve the same with a control thread
running in the dpdk process and handling commands.
It would be open to the outside via a more standard channel, like a UNIX
socket or something like this.
If we need to declare a dynamic channel, it can be constructed as an
extension of the existing standard channel: we can open something like a
POSIX shm and push things in it.
Was this explored ?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
@ 2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-04-08 14:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight", and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both. However,
> > realistically, i don't think dropping multiprocess is ever going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in our
> codebase (pdump, proc-info, etc.).
>
Sorry, I don't want to highjack this thread, I can start a separate thread
if people feel like it.
If we go with stabilisation, we must be careful that we want to support the
features.
So about multiprocess, again, in those closed source projects you know of,
what are the usecases?
For what we provide in dpdk pdump, proc-info, referring to oneself is not
that convincing to me as I don't use those tools.
I don't see what we could not achieve the same with a control thread
running in the dpdk process and handling commands.
It would be open to the outside via a more standard channel, like a UNIX
socket or something like this.
If we need to declare a dynamic channel, it can be constructed as an
extension of the existing standard channel: we can open something like a
POSIX shm and push things in it.
Was this explored ?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
@ 2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 15:13 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, Ray Kinsella, Thomas Monjalon, techboard,
Bruce Richardson, dev, Kevin Traynor
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
>
> > On 08-Apr-19 2:58 PM, David Marchand wrote:
> > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> > >
> > > As a concrete proposal, my number one dream would be to see
> > > multiprocess
> > > gone. I also recall desire for "DPDK to be more lightweight", and i
> > > maintain that DPDK *cannot* be lightweight if we are to support
> > > multiprocess - we can have one or the other, but not both. However,
> > > realistically, i don't think dropping multiprocess is ever going to
> > > happen - not only it is too entrenched in DPDK use cases, it is
> > > actually
> > > quite useful despite its flaws.
> > >
> > >
> > > Well, honestly, I'd like to hear about this.
> > > What are the real usecases for multi process support?
> > > Do we have even a single opensource project that uses it?
> > >
> >
> > I'm aware of a few closed source usages of multiprocess. I also think
> > current versions of collectd rely on secondary process (there's been a
> > Telemetry API added to avoid that, but AFAIK the support for Telemetry
> > is not upstream in collectd yet), and so do/would any dump-style
> > applications - in fact, we ourselves include one such application in our
> > codebase (pdump, proc-info, etc.).
> >
>
> Sorry, I don't want to highjack this thread, I can start a separate thread
> if people feel like it.
> If we go with stabilisation, we must be careful that we want to support the
> features.
>
> So about multiprocess, again, in those closed source projects you know of,
> what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is not
> that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
>
>
Yes, there are several closed source applications using multi-process.
But the problem with that is no one tests with all the drivers, api's and
configurations in DPDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:13 4% ` Stephen Hemminger
@ 2019-04-08 15:13 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 15:13 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, Ray Kinsella, Thomas Monjalon, techboard,
Bruce Richardson, dev, Kevin Traynor
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
>
> > On 08-Apr-19 2:58 PM, David Marchand wrote:
> > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> > >
> > > As a concrete proposal, my number one dream would be to see
> > > multiprocess
> > > gone. I also recall desire for "DPDK to be more lightweight", and i
> > > maintain that DPDK *cannot* be lightweight if we are to support
> > > multiprocess - we can have one or the other, but not both. However,
> > > realistically, i don't think dropping multiprocess is ever going to
> > > happen - not only it is too entrenched in DPDK use cases, it is
> > > actually
> > > quite useful despite its flaws.
> > >
> > >
> > > Well, honestly, I'd like to hear about this.
> > > What are the real usecases for multi process support?
> > > Do we have even a single opensource project that uses it?
> > >
> >
> > I'm aware of a few closed source usages of multiprocess. I also think
> > current versions of collectd rely on secondary process (there's been a
> > Telemetry API added to avoid that, but AFAIK the support for Telemetry
> > is not upstream in collectd yet), and so do/would any dump-style
> > applications - in fact, we ourselves include one such application in our
> > codebase (pdump, proc-info, etc.).
> >
>
> Sorry, I don't want to highjack this thread, I can start a separate thread
> if people feel like it.
> If we go with stabilisation, we must be careful that we want to support the
> features.
>
> So about multiprocess, again, in those closed source projects you know of,
> what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is not
> that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
>
>
Yes, there are several closed source applications using multi-process.
But the problem with that is no one tests with all the drivers, api's and
configurations in DPDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
` (2 preceding siblings ...)
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:50 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:50 4% ` Burakov, Anatoly
@ 2019-04-08 15:50 4% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:50 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
@ 2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:49 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:49 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 0/5] make lcore_config internal
@ 2019-04-08 18:25 3% Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure
internal to EAL and not part of the ABI. It supersedes
earlier RFC.
The first 4 would go into current release, and the
last would go into later release to make it fully
internal.
The same should be done for rte_config, but that
is more difficult.
Stephen Hemminger (5):
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
eal: make lcore_config private
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 ++---
app/test/test_ring_perf.c | 22 ++++---
app/test/test_stack_perf.c | 20 +++---
doc/guides/rel_notes/release_19_05.rst | 7 +++
drivers/bus/dpaa/dpaa_bus.c | 6 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 4 +-
lib/librte_eal/common/eal_common_launch.c | 2 +
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++
lib/librte_eal/common/eal_private.h | 22 +++++++
lib/librte_eal/common/include/rte_lcore.h | 76 +++++++++++------------
lib/librte_eal/common/rte_service.c | 2 +
lib/librte_eal/rte_eal_version.map | 12 +++-
14 files changed, 159 insertions(+), 73 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
@ 2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Most of these functions are not marked as experimental since
we want applications to convert over asap. The one exception is
the return_code, which is only used by some tests now and not
clear that it is even that useful.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 52 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..4beea5705be7 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..c3cf5a06269d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7687fe650f64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
@@ -193,7 +215,7 @@ rte_lcore_to_socket_id(unsigned lcore_id)
* True if the given lcore is enabled; false otherwise.
*/
static inline int
-rte_lcore_is_enabled(unsigned lcore_id)
+rte_lcore_is_enabled(unsigned int lcore_id)
{
struct rte_config *cfg = rte_eal_get_configuration();
if (lcore_id >= RTE_MAX_LCORE)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v1 0/5] make lcore_config internal
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
@ 2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure
internal to EAL and not part of the ABI. It supersedes
earlier RFC.
The first 4 would go into current release, and the
last would go into later release to make it fully
internal.
The same should be done for rte_config, but that
is more difficult.
Stephen Hemminger (5):
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
eal: make lcore_config private
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 ++---
app/test/test_ring_perf.c | 22 ++++---
app/test/test_stack_perf.c | 20 +++---
doc/guides/rel_notes/release_19_05.rst | 7 +++
drivers/bus/dpaa/dpaa_bus.c | 6 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 4 +-
lib/librte_eal/common/eal_common_launch.c | 2 +
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++
lib/librte_eal/common/eal_private.h | 22 +++++++
lib/librte_eal/common/include/rte_lcore.h | 76 +++++++++++------------
lib/librte_eal/common/rte_service.c | 2 +
lib/librte_eal/rte_eal_version.map | 12 +++-
14 files changed, 159 insertions(+), 73 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
THIS BREAKS ABI OF PREVIOUS RELEASES.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7687fe650f64..bc416bc8c19f 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f6688327cad3..2f175f58ed42 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-08 18:25 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Most of these functions are not marked as experimental since
we want applications to convert over asap. The one exception is
the return_code, which is only used by some tests now and not
clear that it is even that useful.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 52 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..4beea5705be7 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..c3cf5a06269d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7687fe650f64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
@@ -193,7 +215,7 @@ rte_lcore_to_socket_id(unsigned lcore_id)
* True if the given lcore is enabled; false otherwise.
*/
static inline int
-rte_lcore_is_enabled(unsigned lcore_id)
+rte_lcore_is_enabled(unsigned int lcore_id)
{
struct rte_config *cfg = rte_eal_get_configuration();
if (lcore_id >= RTE_MAX_LCORE)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-08 18:25 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
THIS BREAKS ABI OF PREVIOUS RELEASES.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7687fe650f64..bc416bc8c19f 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f6688327cad3..2f175f58ed42 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-09 9:42 4% ` Ray Kinsella
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-09 9:42 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 14:38, Burakov, Anatoly wrote:
> On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>>
>>
>> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> [SNIP]
>> [SNIP]
[SNIP]
>>
>
> Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
> specification" i don't mean there literally should be a document with a
> formal specification :)
When I hear the word specification I think encyclopedia-like stacks of
paper.
>
> Rather, i'm thinking more along the lines of, let's take a look at what
> we have, and think of ways we can reduce the amount of code and improve
> things without causing major inconveniences to great majority of users.
> As in, if we want to "break once more and then never again", then maybe
> instead of small incremental fixes here and there, we could actually do
> a more drastic change that keeps perhaps 90% users happy instead of
> 100%, but which reduces maintenance/validation effort from 100% down to
> 30%.
Agreed - all I would propose on top of this is that we give ourselves a
real deadline.
The DPDK API has been iterating since 2012 and while we can spare a few
more months to do tidy-up and get it right, we _do_ need to draw a line
in the sand at the same time.
>
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
> However, what *could* be realistic is to trim down complexity in EAL
> init and system code in general - to me (again, a concrete proposal!),
> that would be dropping igb_uio and supporting upstream kernel modules
> only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
> support and legacy mem modes, and perhaps bumping kernel version and
> removing some compatibility code as well. This would remove potentially
> thousands of lines of code and keep EAL cleaner and more maintainable:
> right now, we have two different hotplug mechanisms (UIO and VFIO), lots
> of different memory/interrupt modes, etc., for no reason that is readily
> apparent to me.
>
> So, as you can see, an effort to review and delineate what we want to
> support would be necessary if we want to ease the maintenance burden for
> either myself or anyone that inherits this code, as well as reducing the
> number of moving parts and, as a consequence, validation effort and
> amount of bugs. We can't simply do it in a random release "just
> because", but if we were to "break once more and then never again",
> perhaps this is something that could be considered.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-09 9:42 4% ` Ray Kinsella
@ 2019-04-09 9:42 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-09 9:42 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 14:38, Burakov, Anatoly wrote:
> On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>>
>>
>> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> [SNIP]
>> [SNIP]
[SNIP]
>>
>
> Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
> specification" i don't mean there literally should be a document with a
> formal specification :)
When I hear the word specification I think encyclopedia-like stacks of
paper.
>
> Rather, i'm thinking more along the lines of, let's take a look at what
> we have, and think of ways we can reduce the amount of code and improve
> things without causing major inconveniences to great majority of users.
> As in, if we want to "break once more and then never again", then maybe
> instead of small incremental fixes here and there, we could actually do
> a more drastic change that keeps perhaps 90% users happy instead of
> 100%, but which reduces maintenance/validation effort from 100% down to
> 30%.
Agreed - all I would propose on top of this is that we give ourselves a
real deadline.
The DPDK API has been iterating since 2012 and while we can spare a few
more months to do tidy-up and get it right, we _do_ need to draw a line
in the sand at the same time.
>
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
> However, what *could* be realistic is to trim down complexity in EAL
> init and system code in general - to me (again, a concrete proposal!),
> that would be dropping igb_uio and supporting upstream kernel modules
> only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
> support and legacy mem modes, and perhaps bumping kernel version and
> removing some compatibility code as well. This would remove potentially
> thousands of lines of code and keep EAL cleaner and more maintainable:
> right now, we have two different hotplug mechanisms (UIO and VFIO), lots
> of different memory/interrupt modes, etc., for no reason that is readily
> apparent to me.
>
> So, as you can see, an effort to review and delineate what we want to
> support would be necessary if we want to ease the maintenance burden for
> either myself or anyone that inherits this code, as well as reducing the
> number of moving parts and, as a consequence, validation effort and
> amount of bugs. We can't simply do it in a random release "just
> because", but if we were to "break once more and then never again",
> perhaps this is something that could be considered.
>
^ permalink raw reply [relevance 4%]
* [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%]
* [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%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 15:42 9% [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
` (3 preceding siblings ...)
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
@ 2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
` (2 more replies)
4 siblings, 3 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-10 5:14 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: Honnappa Nagarahalli, nd, nd
>
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received from
> a number of users of DPDK about ABI churn. In turn this feedback then
> prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
This link can be used to check which structures are not needed to be exposed to the application.
For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> I guess the short story is that DPDK ABI hasn't really settled down as the
> project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive releases
> since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant re-integration
> and re-validation effort for new versions of DPDK. This effort from their
> perspective may not add value to their consuming project, particular if
> they are only updating to "stay current".
Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their projects
> to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS releases.
> A final removal notice will be published to the DPDK Mailing List, and if
> there are no strong objections only then an API may be removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
+1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
<snip>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 5:14 9% ` 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%]
* [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%]
* [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%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-04-10 8:35 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 5:52 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
However, there are two use cases that i can think of that are either
> hard or outright not possible without our multiprocess API's. The first
> one is dumping functionality. For example, dpdk_proc_info can display
> info from a currently-running or defunct process - list its
> memzones/mempools/etc. - basically, everything there is to know about
> the shared memory can be known that way. While this isn't a "real" use
> case, it is useful for debugging.
>
On the principle (there might be some corner cases I don't have an idea of)
attaching an existing process is something that can be done with PTRACE_*.
As for dumping post mortem, again, this could be done without dpdk assist.
The only thing that should come from dpdk is the knowledge of where and how
to dump the objects.
> More importantly, our multiprocess model provides resilience. In an
> event of a crash, the entire application is not brought down - instead,
> only the crashed process goes down. It's not /perfect/ resilience, of
> course, and there are caveats (memory leaking, locks, etc.), but you do
> get /some/ resilience that way - your process went down, you spin
> another secondary and you're back up and running again.
>
Never witnessed a recover, and yes I would suspect quite some funny
situations like locks, dirty memory etc...
Okay, thanks for the inputs.
--
David Marchand
^ permalink raw reply [relevance 4%]
* 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%]
* [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%]
* [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%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 5:14 9% ` 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%]
* 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] [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] [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] DPDK ABI/API Stability
2019-04-10 5:14 9% ` 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] 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%]
* [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
` (2 preceding siblings ...)
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
3 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure less visible
as part of the ABI. This version does not break the ABI (yet)
follow on patch moves lcore_config into eal_private.h
The changes in v2 is to:
- new patch to use unsigned int in lcore.h first
- incorporate feedback from David
- don't include last patch to make it private
(to avoid accidental early merge)
Stephen Hemminger (5):
eal: use unsigned int in rte_lcore.h functions
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 +++---
app/test/test_ring_perf.c | 22 +++++----
app/test/test_stack_perf.c | 20 ++++----
doc/guides/rel_notes/release_19_05.rst | 6 +++
drivers/bus/dpaa/dpaa_bus.c | 6 ++-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 5 +-
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 58 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 136 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
@ 2019-04-10 17:16 9% ` Stephen Hemminger
2019-04-10 17:16 9% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark return code functions as experimental
since this value might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/release_19_05.rst | 6 +++
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 50 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..32aae5d3bcfa 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,12 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..6cf4d7abb0bd 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 959ef9ece4b2..dc9f3dc0843d 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int __rte_experimental
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned int
-rte_lcore_to_socket_id(unsigned int lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
@ 2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure less visible
as part of the ABI. This version does not break the ABI (yet)
follow on patch moves lcore_config into eal_private.h
The changes in v2 is to:
- new patch to use unsigned int in lcore.h first
- incorporate feedback from David
- don't include last patch to make it private
(to avoid accidental early merge)
Stephen Hemminger (5):
eal: use unsigned int in rte_lcore.h functions
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 +++---
app/test/test_ring_perf.c | 22 +++++----
app/test/test_stack_perf.c | 20 ++++----
doc/guides/rel_notes/release_19_05.rst | 6 +++
drivers/bus/dpaa/dpaa_bus.c | 6 ++-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 5 +-
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 58 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 136 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-10 17:16 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark return code functions as experimental
since this value might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/release_19_05.rst | 6 +++
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 50 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..32aae5d3bcfa 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,12 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..6cf4d7abb0bd 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 959ef9ece4b2..dc9f3dc0843d 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int __rte_experimental
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned int
-rte_lcore_to_socket_id(unsigned int lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [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] [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] [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] [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 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 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%]
* 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%]
* 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
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 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] [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] [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
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: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: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: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] [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] [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] [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] [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
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: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: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 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] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
2 siblings, 2 replies; 200+ results
From: Neil Horman @ 2019-04-14 0:42 UTC (permalink / raw)
To: Ray Kinsella; +Cc: dev
On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
> > 04/04/2019 16:07, Burakov, Anatoly:
> >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >> So, if we are to cement our core API - we have to make a concrete effort
> >> to specify what goes and what stays, if we want it to be maintainable.
> >> The DPDK 1.0 specification, if you will :)
> >
> > "DPDK 1.0 specification", that's a great project name :-)
> >
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
I'm hesitant to say this, because I'm not usually a fan of throwing up
barricades to progress, but might some level of CI integration be useful here?
Part of the problem, as I've seen it (and I think you've noted previously in
this thread), is that ABI stability just hasn't been a priority, and not
something that developers look at when making changes, nor when reviewers review
patches. When I wrote the early ABI checking tools for DPDK, while the reaction
was generally positive (I think), the results were informational, and treated as
such (something to take note of perhaps, but something that could be ignored if
there were more pressing issues). Perhaps a concrete step might be to run the
ABI checker during a CI run on every commit, and block acceptance of a patch if
it modifies the ABI. That would at least put a procedural break in ABI
modification without clear approval from the board.
Neil
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [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
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-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] [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] [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-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 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 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 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 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 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 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 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%]
* [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%]
* [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%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 11:22 0% ` Neil Horman
2019-04-05 11:22 0% ` Neil Horman
@ 2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-15 22:14 0% ` Thomas Monjalon
1 sibling, 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%]
* 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 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 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 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 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
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: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: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 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 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: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 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 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 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 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 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 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 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
1 sibling, 1 reply; 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-17 1:45 0% ` Honnappa Nagarahalli
@ 2019-04-17 1:45 0% ` Honnappa Nagarahalli
0 siblings, 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%]
* [dpdk-dev] ABI and inline functions
@ 2019-04-17 5:12 9% Honnappa Nagarahalli
0 siblings, 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%]
Results 5401-5600 of ~18000 next (newer) | prev (older) | 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-03-01 8:09 [dpdk-dev] [PATCH v1 0/6] Introduce AF_XDP PMD Xiaolong Ye
2019-04-03 16:59 2% ` [dpdk-dev] [PATCH v10 0/1] " Xiaolong Ye
2019-04-03 16:59 2% ` Xiaolong Ye
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 16:13 0% ` Ferruh Yigit
2019-04-04 16:13 0% ` Ferruh Yigit
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 15:03 [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-18 21:35 ` [dpdk-dev] [PATCH v7 " Gage Eads
2019-03-18 21:49 ` Eads, Gage
2019-03-19 15:51 ` Stephen Hemminger
2019-04-01 19:23 ` Eads, Gage
2019-04-02 10:16 ` Ola Liljedahl
2019-04-04 22:28 0% ` Eads, Gage
2019-04-04 22:28 0% ` Eads, Gage
2019-03-06 17:20 [dpdk-dev] [PATCH v4 0/2] Timer library changes Erik Gabriel Carrillo
2019-04-15 21:41 5% ` [dpdk-dev] [PATCH v5 " Erik Gabriel Carrillo
2019-04-15 21:41 5% ` Erik Gabriel Carrillo
2019-03-14 15:12 [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes David Marchand
2019-03-19 17:18 ` [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API Ferruh Yigit
2019-03-26 9:29 ` David Marchand
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
2019-04-12 16:05 0% ` Stephen Hemminger
2019-03-18 11:56 [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification Hajkowski
2019-04-05 14:35 4% ` [dpdk-dev] [PATCH] " Hajkowski
2019-04-05 14:35 4% ` Hajkowski
2019-03-19 14:05 [dpdk-dev] [PATCH] doc: fix abi check script examples David Marchand
2019-03-19 17:19 ` Neil Horman
2019-04-05 8:30 4% ` Thomas Monjalon
2019-04-05 8:30 4% ` Thomas Monjalon
2019-03-26 19:25 [dpdk-dev] [RFC] eal: rename state values in rte_lcore_state Stephen Hemminger
2019-04-02 15:57 ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
2019-04-02 20:15 ` David Marchand
2019-04-02 20:48 ` Stephen Hemminger
2019-04-02 21:03 ` David Marchand
2019-04-02 21:07 ` Stephen Hemminger
2019-04-02 21:07 4% ` Stephen Hemminger
2019-04-02 21:21 0% ` David Marchand
2019-04-02 21:21 0% ` David Marchand
2019-04-03 3:04 4% [dpdk-dev] EAL lcore config Stephen Hemminger
2019-04-03 3:04 4% ` Stephen Hemminger
2019-04-03 9:58 0% ` Burakov, Anatoly
2019-04-03 9:58 0% ` Burakov, Anatoly
2019-04-03 13:26 1% [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell John McNamara
2019-04-03 13:26 1% ` John McNamara
2019-04-03 15:42 9% [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
2019-04-03 15:42 9% ` Ray Kinsella
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-04 13:21 4% ` Luca Boccassi
2019-04-04 13:21 4% ` Luca Boccassi
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-09 9:42 4% ` Ray Kinsella
2019-04-09 9:42 4% ` Ray Kinsella
2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
2019-04-15 9:10 4% ` Bruce Richardson
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 13:16 7% ` Ray Kinsella
2019-04-04 13:16 7% ` Ray Kinsella
2019-04-10 5:14 9% ` 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-03 17:16 [dpdk-dev] [RFC 0/5] make lcore_config less visible Stephen Hemminger
2019-04-03 17:16 9% ` [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-03 17:16 9% ` Stephen Hemminger
2019-04-03 17:16 3% ` [dpdk-dev] [RFC 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-03 17:16 3% ` Stephen Hemminger
2019-04-05 8:17 4% [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
2019-04-05 8:17 4% ` David Marchand
2019-04-05 11:22 0% ` Neil Horman
2019-04-05 11:22 0% ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 11:12 3% ` Ferruh Yigit
2019-04-05 11:12 3% ` Ferruh Yigit
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
2019-04-05 20:30 3% [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
2019-04-05 20:30 3% ` Stephen Hemminger
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-10 17:16 9% ` Stephen Hemminger
2019-04-09 17:36 4% [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission Rami Rosen
2019-04-09 17:36 4% ` Rami Rosen
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 11:18 [dpdk-dev] [PATCH 00/10] add MACSEC hw offload to atlantic PMD Igor Russkikh
2019-04-10 11:18 ` [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops Igor Russkikh
2019-04-12 18:26 ` Ferruh Yigit
2019-04-13 7:24 ` Igor Russkikh
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
2019-04-16 10:19 0% ` Igor Russkikh
2019-04-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
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).