* [PATCH 1/3] version: 23.11-rc0
@ 2023-07-31 9:43 6% ` David Marchand
0 siblings, 0 replies; 53+ results
From: David Marchand @ 2023-07-31 9:43 UTC (permalink / raw)
To: dev
Cc: thomas, Aaron Conole, Michael Santana, Nicolas Chautru,
Hemant Agrawal, Sachin Saxena, Chenbo Xia, Nipun Gupta,
Tomasz Duszynski, Long Li, Anoob Joseph, Kai Ji, Gagandeep Singh,
Timothy McDaniel, Ashwin Sekhar T K, Pavan Nikhilesh,
Igor Russkikh, Ajit Khaparde, Somnath Kotur, Chas Williams,
Min Hu (Connor),
Nithin Dabilpuram, Kiran Kumar K, Sunil Kumar Kori, Satha Rao,
Yuying Zhang, Beilei Xing, Jingjing Wu, Qiming Yang, Qi Zhang,
Rosen Xu, Wenjun Wu, Matan Azrad, Viacheslav Ovsiienko, Ori Kam,
Suanming Mou, Harman Kalra, Bruce Richardson,
Cristian Dumitrescu, Maxime Coquelin, Tianfei Zhang,
Konstantin Ananyev, Olivier Matz, Akhil Goyal, Fan Zhang,
David Hunt, Byron Marohn, Yipeng Wang, Ferruh Yigit,
Andrew Rybchenko, Jerin Jacob, Vladimir Medvedkin, Jiayu Hu,
Sameh Gobriel, Reshma Pattan, Gaetan Rivet, Stephen Hemminger,
Anatoly Burakov, Honnappa Nagarahalli, Volodymyr Fialko,
Erik Gabriel Carrillo
Start a new release cycle with empty release notes.
The ABI version becomes 24.0.
The map files are updated to the new ABI major number (24).
The ABI exceptions are dropped and CI ABI checks are disabled because
compatibility is not preserved.
The telemetry and vhost libraries compat code is cleaned up in next
commits.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.github/workflows/build.yml | 4 +-
ABI_VERSION | 2 +-
VERSION | 2 +-
devtools/libabigail.abignore | 5 -
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_23_11.rst | 136 +++++++++++++++++++++
drivers/baseband/acc/version.map | 2 +-
drivers/baseband/fpga_5gnr_fec/version.map | 2 +-
drivers/baseband/fpga_lte_fec/version.map | 2 +-
drivers/bus/fslmc/version.map | 2 +-
drivers/bus/pci/version.map | 2 +-
drivers/bus/platform/version.map | 2 +-
drivers/bus/vdev/version.map | 2 +-
drivers/bus/vmbus/version.map | 2 +-
drivers/crypto/octeontx/version.map | 2 +-
drivers/crypto/scheduler/version.map | 2 +-
drivers/dma/dpaa2/version.map | 2 +-
drivers/event/dlb2/version.map | 2 +-
drivers/mempool/cnxk/version.map | 8 +-
drivers/mempool/dpaa2/version.map | 2 +-
drivers/net/atlantic/version.map | 2 +-
drivers/net/bnxt/version.map | 2 +-
drivers/net/bonding/version.map | 2 +-
drivers/net/cnxk/version.map | 2 +-
drivers/net/dpaa/version.map | 2 +-
drivers/net/dpaa2/version.map | 2 +-
drivers/net/i40e/version.map | 2 +-
drivers/net/iavf/version.map | 2 +-
drivers/net/ice/version.map | 2 +-
drivers/net/ipn3ke/version.map | 2 +-
drivers/net/ixgbe/version.map | 2 +-
drivers/net/mlx5/version.map | 2 +-
drivers/net/octeontx/version.map | 2 +-
drivers/net/ring/version.map | 2 +-
drivers/net/softnic/version.map | 2 +-
drivers/net/vhost/version.map | 2 +-
drivers/raw/ifpga/version.map | 2 +-
drivers/version.map | 2 +-
lib/acl/version.map | 2 +-
lib/bbdev/version.map | 2 +-
lib/bitratestats/version.map | 2 +-
lib/bpf/version.map | 2 +-
lib/cfgfile/version.map | 2 +-
lib/cmdline/version.map | 2 +-
lib/cryptodev/version.map | 2 +-
lib/distributor/version.map | 2 +-
lib/eal/version.map | 2 +-
lib/efd/version.map | 2 +-
lib/ethdev/version.map | 2 +-
lib/eventdev/version.map | 2 +-
lib/fib/version.map | 2 +-
lib/gro/version.map | 2 +-
lib/gso/version.map | 2 +-
lib/hash/version.map | 2 +-
lib/ip_frag/version.map | 2 +-
lib/ipsec/version.map | 2 +-
lib/jobstats/version.map | 2 +-
lib/kni/version.map | 2 +-
lib/kvargs/version.map | 2 +-
lib/latencystats/version.map | 2 +-
lib/lpm/version.map | 2 +-
lib/mbuf/version.map | 2 +-
lib/member/version.map | 2 +-
lib/mempool/version.map | 2 +-
lib/meter/version.map | 2 +-
lib/metrics/version.map | 2 +-
lib/net/version.map | 2 +-
lib/pci/version.map | 2 +-
lib/pdump/version.map | 2 +-
lib/pipeline/version.map | 2 +-
lib/port/version.map | 2 +-
lib/power/version.map | 2 +-
lib/rawdev/version.map | 2 +-
lib/rcu/version.map | 2 +-
lib/reorder/version.map | 2 +-
lib/rib/version.map | 2 +-
lib/ring/version.map | 2 +-
lib/sched/version.map | 2 +-
lib/security/version.map | 2 +-
lib/stack/version.map | 2 +-
lib/table/version.map | 2 +-
lib/timer/version.map | 2 +-
82 files changed, 220 insertions(+), 88 deletions(-)
create mode 100644 doc/guides/rel_notes/release_23_11.rst
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index d3bcb160cf..2c1eda9b18 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -27,7 +27,7 @@ jobs:
MINGW: ${{ matrix.config.cross == 'mingw' }}
MINI: ${{ matrix.config.mini != '' }}
PPC64LE: ${{ matrix.config.cross == 'ppc64le' }}
- REF_GIT_TAG: v23.03
+ REF_GIT_TAG: none
RISCV64: ${{ matrix.config.cross == 'riscv64' }}
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
@@ -40,7 +40,7 @@ jobs:
mini: mini
- os: ubuntu-20.04
compiler: gcc
- checks: abi+debug+doc+examples+tests
+ checks: debug+doc+examples+tests
- os: ubuntu-20.04
compiler: clang
checks: asan+doc+tests
diff --git a/ABI_VERSION b/ABI_VERSION
index 3c8ce91a46..d9133a54b6 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-23.2
+24.0
diff --git a/VERSION b/VERSION
index 942d403ae8..1d4e4e7927 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-23.07.0
+23.11.0-rc0
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 03bfbce259..3ff51509de 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -25,7 +25,6 @@
;
; SKIP_LIBRARY=librte_common_mlx5_glue
; SKIP_LIBRARY=librte_net_mlx4_glue
-; SKIP_LIBRARY=librte_net_liquidio
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
@@ -41,7 +40,3 @@
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-
-; Ignore changes to rte_security_ops which are internal to PMD.
-[suppress_type]
- name = rte_security_ops
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index d8dfa621ec..d072815279 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -8,6 +8,7 @@ Release Notes
:maxdepth: 1
:numbered:
+ release_23_11
release_23_07
release_23_03
release_22_11
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
new file mode 100644
index 0000000000..6b4dd21fd0
--- /dev/null
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -0,0 +1,136 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2023 The DPDK contributors
+
+.. include:: <isonum.txt>
+
+DPDK Release 23.11
+==================
+
+.. **Read this first.**
+
+ The text in the sections below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text:
+ ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ ninja -C build doc
+ xdg-open build/doc/guides/html/rel_notes/release_23_11.html
+
+
+New Features
+------------
+
+.. This section should contain new features added in this release.
+ Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
+ - ethdev (lib, PMDs)
+ - cryptodev (lib, PMDs)
+ - eventdev (lib, PMDs)
+ - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Removed Items
+-------------
+
+.. This section should contain removed items in this release. Sample format:
+
+ * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+API Changes
+-----------
+
+.. This section should contain API changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the API change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the ABI change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+ * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue
+ in the present tense. Add information on any known workarounds.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested
+ with this release.
+
+ The format is:
+
+ * <vendor> platform with <vendor> <type of devices> combinations
+
+ * List of CPU
+ * List of OS
+ * List of devices
+ * Other relevant details...
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
diff --git a/drivers/baseband/acc/version.map b/drivers/baseband/acc/version.map
index 95ae74dd35..1b6b1cd10d 100644
--- a/drivers/baseband/acc/version.map
+++ b/drivers/baseband/acc/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/baseband/fpga_5gnr_fec/version.map b/drivers/baseband/fpga_5gnr_fec/version.map
index 6b191cf330..2da20cabc1 100644
--- a/drivers/baseband/fpga_5gnr_fec/version.map
+++ b/drivers/baseband/fpga_5gnr_fec/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/baseband/fpga_lte_fec/version.map b/drivers/baseband/fpga_lte_fec/version.map
index aab28a9976..83f3a8a267 100644
--- a/drivers/baseband/fpga_lte_fec/version.map
+++ b/drivers/baseband/fpga_lte_fec/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/bus/fslmc/version.map b/drivers/bus/fslmc/version.map
index a25a9e8ca0..f6bdf877bf 100644
--- a/drivers/bus/fslmc/version.map
+++ b/drivers/bus/fslmc/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_fslmc_vfio_mem_dmamap;
diff --git a/drivers/bus/pci/version.map b/drivers/bus/pci/version.map
index 92fcaca094..a0000f7938 100644
--- a/drivers/bus/pci/version.map
+++ b/drivers/bus/pci/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pci_dump;
diff --git a/drivers/bus/platform/version.map b/drivers/bus/platform/version.map
index bacce4da08..9e7111dd38 100644
--- a/drivers/bus/platform/version.map
+++ b/drivers/bus/platform/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/bus/vdev/version.map b/drivers/bus/vdev/version.map
index 594c48c3db..16f187734b 100644
--- a/drivers/bus/vdev/version.map
+++ b/drivers/bus/vdev/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_vdev_add_custom_scan;
diff --git a/drivers/bus/vmbus/version.map b/drivers/bus/vmbus/version.map
index 430781b29b..08b008b311 100644
--- a/drivers/bus/vmbus/version.map
+++ b/drivers/bus/vmbus/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_vmbus_chan_close;
diff --git a/drivers/crypto/octeontx/version.map b/drivers/crypto/octeontx/version.map
index cc4b6b0970..54a0912e76 100644
--- a/drivers/crypto/octeontx/version.map
+++ b/drivers/crypto/octeontx/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/crypto/scheduler/version.map b/drivers/crypto/scheduler/version.map
index 74491beabb..23380fb3c5 100644
--- a/drivers/crypto/scheduler/version.map
+++ b/drivers/crypto/scheduler/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_cryptodev_scheduler_load_user_scheduler;
diff --git a/drivers/dma/dpaa2/version.map b/drivers/dma/dpaa2/version.map
index 0c020e5249..7dc2d6e185 100644
--- a/drivers/dma/dpaa2/version.map
+++ b/drivers/dma/dpaa2/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/event/dlb2/version.map b/drivers/event/dlb2/version.map
index 1327e3e335..8aabf8b727 100644
--- a/drivers/event/dlb2/version.map
+++ b/drivers/event/dlb2/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/mempool/cnxk/version.map b/drivers/mempool/cnxk/version.map
index 755731e3b5..775d46d934 100644
--- a/drivers/mempool/cnxk/version.map
+++ b/drivers/mempool/cnxk/version.map
@@ -1,10 +1,10 @@
- DPDK_23 {
+DPDK_24 {
local: *;
- };
+};
- EXPERIMENTAL {
+EXPERIMENTAL {
global:
rte_pmd_cnxk_mempool_is_hwpool;
rte_pmd_cnxk_mempool_mbuf_exchange;
rte_pmd_cnxk_mempool_range_check_disable;
- };
+};
diff --git a/drivers/mempool/dpaa2/version.map b/drivers/mempool/dpaa2/version.map
index 0023765843..b2bf63eb79 100644
--- a/drivers/mempool/dpaa2/version.map
+++ b/drivers/mempool/dpaa2/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_dpaa2_mbuf_from_buf_addr;
diff --git a/drivers/net/atlantic/version.map b/drivers/net/atlantic/version.map
index e301b105fe..b063baa7a4 100644
--- a/drivers/net/atlantic/version.map
+++ b/drivers/net/atlantic/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/net/bnxt/version.map b/drivers/net/bnxt/version.map
index 075bb37a36..ff82396ca1 100644
--- a/drivers/net/bnxt/version.map
+++ b/drivers/net/bnxt/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_bnxt_get_vf_rx_status;
diff --git a/drivers/net/bonding/version.map b/drivers/net/bonding/version.map
index 9333923b4e..bd28ee78a5 100644
--- a/drivers/net/bonding/version.map
+++ b/drivers/net/bonding/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_eth_bond_8023ad_agg_selection_get;
diff --git a/drivers/net/cnxk/version.map b/drivers/net/cnxk/version.map
index 3ef3e76bb0..7ae6d80bf0 100644
--- a/drivers/net/cnxk/version.map
+++ b/drivers/net/cnxk/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/net/dpaa/version.map b/drivers/net/dpaa/version.map
index 5268d39ef6..c06f4a56de 100644
--- a/drivers/net/dpaa/version.map
+++ b/drivers/net/dpaa/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_dpaa_set_tx_loopback;
diff --git a/drivers/net/dpaa2/version.map b/drivers/net/dpaa2/version.map
index d6535343b1..283bcb42c1 100644
--- a/drivers/net/dpaa2/version.map
+++ b/drivers/net/dpaa2/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_dpaa2_mux_flow_create;
diff --git a/drivers/net/i40e/version.map b/drivers/net/i40e/version.map
index 4d1ac59226..3ba31f4768 100644
--- a/drivers/net/i40e/version.map
+++ b/drivers/net/i40e/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_i40e_add_vf_mac_addr;
diff --git a/drivers/net/iavf/version.map b/drivers/net/iavf/version.map
index 4796c2884f..135a4ccd3d 100644
--- a/drivers/net/iavf/version.map
+++ b/drivers/net/iavf/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/net/ice/version.map b/drivers/net/ice/version.map
index d70c250e9a..4e924c8f4d 100644
--- a/drivers/net/ice/version.map
+++ b/drivers/net/ice/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/net/ipn3ke/version.map b/drivers/net/ipn3ke/version.map
index 4c48499993..4a8f5e499a 100644
--- a/drivers/net/ipn3ke/version.map
+++ b/drivers/net/ipn3ke/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/net/ixgbe/version.map b/drivers/net/ixgbe/version.map
index 94693ccc1a..2c9d977f5c 100644
--- a/drivers/net/ixgbe/version.map
+++ b/drivers/net/ixgbe/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_ixgbe_bypass_event_show;
diff --git a/drivers/net/mlx5/version.map b/drivers/net/mlx5/version.map
index 7ef598027b..99f5ab754a 100644
--- a/drivers/net/mlx5/version.map
+++ b/drivers/net/mlx5/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/drivers/net/octeontx/version.map b/drivers/net/octeontx/version.map
index ae37d32d04..219933550d 100644
--- a/drivers/net/octeontx/version.map
+++ b/drivers/net/octeontx/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_octeontx_pchan_map;
diff --git a/drivers/net/ring/version.map b/drivers/net/ring/version.map
index 84e52064e0..62d9a77f9c 100644
--- a/drivers/net/ring/version.map
+++ b/drivers/net/ring/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_eth_from_ring;
diff --git a/drivers/net/softnic/version.map b/drivers/net/softnic/version.map
index 4dac46ecd5..f67475684c 100644
--- a/drivers/net/softnic/version.map
+++ b/drivers/net/softnic/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_softnic_manage;
diff --git a/drivers/net/vhost/version.map b/drivers/net/vhost/version.map
index e42c89f1eb..4825afd411 100644
--- a/drivers/net/vhost/version.map
+++ b/drivers/net/vhost/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_eth_vhost_get_queue_event;
diff --git a/drivers/raw/ifpga/version.map b/drivers/raw/ifpga/version.map
index 916da8a4f2..7fc1b5e8ae 100644
--- a/drivers/raw/ifpga/version.map
+++ b/drivers/raw/ifpga/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pmd_ifpga_cleanup;
diff --git a/drivers/version.map b/drivers/version.map
index 78c3585d7c..5535c79061 100644
--- a/drivers/version.map
+++ b/drivers/version.map
@@ -1,3 +1,3 @@
-DPDK_23 {
+DPDK_24 {
local: *;
};
diff --git a/lib/acl/version.map b/lib/acl/version.map
index 4c15dbbb36..fe3127a3a9 100644
--- a/lib/acl/version.map
+++ b/lib/acl/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_acl_add_rules;
diff --git a/lib/bbdev/version.map b/lib/bbdev/version.map
index d0bb835255..4f4bfbbd5e 100644
--- a/lib/bbdev/version.map
+++ b/lib/bbdev/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_bbdev_allocate;
diff --git a/lib/bitratestats/version.map b/lib/bitratestats/version.map
index dc110440e0..08831a62f4 100644
--- a/lib/bitratestats/version.map
+++ b/lib/bitratestats/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_stats_bitrate_calc;
diff --git a/lib/bpf/version.map b/lib/bpf/version.map
index 04bd657a85..c49bf1701f 100644
--- a/lib/bpf/version.map
+++ b/lib/bpf/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_bpf_destroy;
diff --git a/lib/cfgfile/version.map b/lib/cfgfile/version.map
index fdb0f13040..a3fe9b62f3 100644
--- a/lib/cfgfile/version.map
+++ b/lib/cfgfile/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_cfgfile_add_entry;
diff --git a/lib/cmdline/version.map b/lib/cmdline/version.map
index e3d59aaf8d..db4d904ffb 100644
--- a/lib/cmdline/version.map
+++ b/lib/cmdline/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
cirbuf_add_buf_head;
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 24ff90799c..209806cf24 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_crypto_aead_algorithm_strings;
diff --git a/lib/distributor/version.map b/lib/distributor/version.map
index 7a34dfa2f2..2670c4201c 100644
--- a/lib/distributor/version.map
+++ b/lib/distributor/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_distributor_clear_returns;
diff --git a/lib/eal/version.map b/lib/eal/version.map
index ea1b1a7d0a..bdb98cf479 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
__rte_panic;
diff --git a/lib/efd/version.map b/lib/efd/version.map
index 67886414ab..baac60f7bc 100644
--- a/lib/efd/version.map
+++ b/lib/efd/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_efd_create;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index fc492ee839..b965d6aa52 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_eth_add_first_rx_callback;
diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
index 89068a5713..b03c10d99f 100644
--- a/lib/eventdev/version.map
+++ b/lib/eventdev/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
__rte_eventdev_trace_crypto_adapter_enqueue;
diff --git a/lib/fib/version.map b/lib/fib/version.map
index a867d2b7d8..62dbada6bc 100644
--- a/lib/fib/version.map
+++ b/lib/fib/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_fib6_add;
diff --git a/lib/gro/version.map b/lib/gro/version.map
index 105aa64ca3..13803ec814 100644
--- a/lib/gro/version.map
+++ b/lib/gro/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_gro_ctx_create;
diff --git a/lib/gso/version.map b/lib/gso/version.map
index f6b552de6d..f159b3f199 100644
--- a/lib/gso/version.map
+++ b/lib/gso/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_gso_segment;
diff --git a/lib/hash/version.map b/lib/hash/version.map
index bdcebd19c2..daaa9a8901 100644
--- a/lib/hash/version.map
+++ b/lib/hash/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_fbk_hash_create;
diff --git a/lib/ip_frag/version.map b/lib/ip_frag/version.map
index 8aad83957d..7ba446c993 100644
--- a/lib/ip_frag/version.map
+++ b/lib/ip_frag/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_ip_frag_free_death_row;
diff --git a/lib/ipsec/version.map b/lib/ipsec/version.map
index f17a49dd26..f0063af354 100644
--- a/lib/ipsec/version.map
+++ b/lib/ipsec/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_ipsec_pkt_crypto_group;
diff --git a/lib/jobstats/version.map b/lib/jobstats/version.map
index bca7480afb..3b8f9d6ac4 100644
--- a/lib/jobstats/version.map
+++ b/lib/jobstats/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_jobstats_abort;
diff --git a/lib/kni/version.map b/lib/kni/version.map
index 83bbbe880f..13ffaa5bfd 100644
--- a/lib/kni/version.map
+++ b/lib/kni/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_kni_alloc;
diff --git a/lib/kvargs/version.map b/lib/kvargs/version.map
index 781f71cf23..387a94e725 100644
--- a/lib/kvargs/version.map
+++ b/lib/kvargs/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_kvargs_count;
diff --git a/lib/latencystats/version.map b/lib/latencystats/version.map
index 79b8395f12..86ded322cb 100644
--- a/lib/latencystats/version.map
+++ b/lib/latencystats/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_latencystats_get;
diff --git a/lib/lpm/version.map b/lib/lpm/version.map
index e1a7aaedbb..9ba73b2f93 100644
--- a/lib/lpm/version.map
+++ b/lib/lpm/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_lpm6_add;
diff --git a/lib/mbuf/version.map b/lib/mbuf/version.map
index ed486ed14e..f010d4692e 100644
--- a/lib/mbuf/version.map
+++ b/lib/mbuf/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
__rte_pktmbuf_linearize;
diff --git a/lib/member/version.map b/lib/member/version.map
index 35199270ff..9be5068d68 100644
--- a/lib/member/version.map
+++ b/lib/member/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_member_add;
diff --git a/lib/mempool/version.map b/lib/mempool/version.map
index dff2d1cb55..d0bfedd1d8 100644
--- a/lib/mempool/version.map
+++ b/lib/mempool/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_mempool_audit;
diff --git a/lib/meter/version.map b/lib/meter/version.map
index b10b544641..9628bd8cd9 100644
--- a/lib/meter/version.map
+++ b/lib/meter/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_meter_srtcm_config;
diff --git a/lib/metrics/version.map b/lib/metrics/version.map
index 89ffa9be80..4763ac6b8b 100644
--- a/lib/metrics/version.map
+++ b/lib/metrics/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_metrics_deinit;
diff --git a/lib/net/version.map b/lib/net/version.map
index e8fe2b7635..3e293c4715 100644
--- a/lib/net/version.map
+++ b/lib/net/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_eth_random_addr;
diff --git a/lib/pci/version.map b/lib/pci/version.map
index e9282ff49c..aeca8a1c9e 100644
--- a/lib/pci/version.map
+++ b/lib/pci/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pci_addr_cmp;
diff --git a/lib/pdump/version.map b/lib/pdump/version.map
index 25df5a82c2..225830dc85 100644
--- a/lib/pdump/version.map
+++ b/lib/pdump/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pdump_disable;
diff --git a/lib/pipeline/version.map b/lib/pipeline/version.map
index 3a4488cd0e..6e3f5b7e80 100644
--- a/lib/pipeline/version.map
+++ b/lib/pipeline/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_pipeline_ah_packet_drop;
diff --git a/lib/port/version.map b/lib/port/version.map
index af6cf696fd..83dbec7b01 100644
--- a/lib/port/version.map
+++ b/lib/port/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_port_ethdev_reader_ops;
diff --git a/lib/power/version.map b/lib/power/version.map
index 05d544e947..b8b54f768e 100644
--- a/lib/power/version.map
+++ b/lib/power/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_power_exit;
diff --git a/lib/rawdev/version.map b/lib/rawdev/version.map
index 8278aacdea..21064a889b 100644
--- a/lib/rawdev/version.map
+++ b/lib/rawdev/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_rawdev_close;
diff --git a/lib/rcu/version.map b/lib/rcu/version.map
index cabed64fca..9218ed1f33 100644
--- a/lib/rcu/version.map
+++ b/lib/rcu/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_rcu_log_type;
diff --git a/lib/reorder/version.map b/lib/reorder/version.map
index 0b3d4d5685..ea60759106 100644
--- a/lib/reorder/version.map
+++ b/lib/reorder/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_reorder_create;
diff --git a/lib/rib/version.map b/lib/rib/version.map
index ca2815e44b..39da637f75 100644
--- a/lib/rib/version.map
+++ b/lib/rib/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_rib6_create;
diff --git a/lib/ring/version.map b/lib/ring/version.map
index 4d7c27a6d9..9eb6e254c8 100644
--- a/lib/ring/version.map
+++ b/lib/ring/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_ring_create;
diff --git a/lib/sched/version.map b/lib/sched/version.map
index 2f64834c8f..d9ce68be14 100644
--- a/lib/sched/version.map
+++ b/lib/sched/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_approx;
diff --git a/lib/security/version.map b/lib/security/version.map
index 07dcce9ffb..b2097a969d 100644
--- a/lib/security/version.map
+++ b/lib/security/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_security_capabilities_get;
diff --git a/lib/stack/version.map b/lib/stack/version.map
index c0250f5cdf..d191ef7791 100644
--- a/lib/stack/version.map
+++ b/lib/stack/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_stack_create;
diff --git a/lib/table/version.map b/lib/table/version.map
index e32e15a5fc..05ed820119 100644
--- a/lib/table/version.map
+++ b/lib/table/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_table_acl_ops;
diff --git a/lib/timer/version.map b/lib/timer/version.map
index 101f5c18b5..e3d5a04303 100644
--- a/lib/timer/version.map
+++ b/lib/timer/version.map
@@ -1,4 +1,4 @@
-DPDK_23 {
+DPDK_24 {
global:
rte_timer_alt_dump_stats;
--
2.41.0
^ permalink raw reply [relevance 6%]
* RE: [RFC] lib/ethdev: introduce table driven APIs
2023-06-19 9:52 5% ` Jerin Jacob
@ 2023-06-20 1:52 2% ` Zhang, Qi Z
0 siblings, 0 replies; 53+ results
From: Zhang, Qi Z @ 2023-06-20 1:52 UTC (permalink / raw)
To: Jerin Jacob
Cc: Dumitrescu, Cristian, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
david.marchand, Richardson, Bruce, jerinj, ferruh.yigit,
Mcnamara, John, Zhang, Helin, techboard, dev, Ivan Malov
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Monday, June 19, 2023 5:52 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Ori Kam
> <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; david.marchand@redhat.com; Richardson, Bruce
> <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> <ivan.malov@arknetworks.am>
> Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
>
> On Mon, Jun 19, 2023 at 5:53 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Friday, June 16, 2023 9:20 AM
> > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; Dumitrescu, Cristian
> > > <cristian.dumitrescu@intel.com>
> > > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > Richardson, Bruce <bruce.richardson@intel.com>; jerinj@marvell.com;
> > > ferruh.yigit@amd.com; Mcnamara, John <john.mcnamara@intel.com>;
> > > Zhang, Helin <helin.zhang@intel.com>; techboard@dpdk.org;
> > > dev@dpdk.org; Ivan Malov <ivan.malov@arknetworks.am>
> > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> > >
> > > On Thu, Jun 15, 2023 at 7:36 PM Zhang, Qi Z <qi.z.zhang@intel.com>
> wrote:
> > > >
> > >
> > > > > > If we assume that the application is not P4-aware, it will
> > > > > > consume existing
> > > > > rte_flow API for flow offloading. In this case, all we need to
> > > > > do is implement it in the PMD, which will be a highly
> > > > > hardware-specific task. Do you propose generalizing this common
> part?
> > > > > >
> > > > > > On the other hand, if the application is P4-aware, we can
> > > > > > assume that
> > > > > there won't be a need for translation between P4 tokens and
> > > > > rte_flow protocols in the PMD.
> > > > >
> > > > > I agree, Translation is BAD. There are two elements to that.
> > > > > 1)if it is p4 aware application, why bother with DPDK abstraction?
> > > > > 2)Can we use compiler techniques to avoid the cost of
> > > > > translation if
> > > > > P4- aware path is needed in DPDK. Rather than creating yet
> > > > > another library. In this context, that would translate to some
> > > > > of your compiler and FW work making as generic so that _any_
> > > > > other rte_flow based driver can use and improve it.
> > > >
> > > >
> > > > Ok, I would like to gain a better understanding. Below is my
> > > > current
> > > understanding:
> > > >
> > > > There are no plans to introduce any new API from DPDK. However,
> > > > your
> > > proposal suggests the creation of a tool, such as a compiler, which
> > > would assist in generating a translation layer from P4 table/actions
> > > to rte_flow for user application like p4 runtime backend that based on
> DPDK.
> > > >
> > > > Could you provide more details about the design? Specifically, I
> > > > would like
> > > to know what the input for the compiler is and who is responsible
> > > for generating that input, as well as the process involved.
> > > >
> > > > I apologize if I have not grasped the complete picture, but I
> > > > would
> > > appreciate your patience.
> > >
> > > + @Cristian Dumitrescu
> > >
> > > There is already a lot of p4(just based on DPDK lib/pipeline SW, not
> > > with any HW acceleration) with DPDK. Not sure how much it overlaps,
> > > and how clean is this to integrate with existing SW or "create new one"?
> > > I would think, enhancing the current p4-dpdk support by using
> > > rte_flow backend. That would translate to
> > > 1) Update https://github.com/p4lang/p4c/tree/main/backends/dpdk to
> > > understand generic p4 table key token to rte_flow token for spec
> > > file generation.
> >
> > OK, I assume that the compiler should have the capability to comprehend
> the logic of the P4 parser and determine the appropriate mapping of each
> key field in the P4 table to an rte_flow header. This process should be
> independent of any specific vendor.
>
> Yes.
>
> >
> > However, the question arises regarding how to handle vendor-specific data,
> which also can be part of the table / action key and could potentially be
> mapped to either rte_flow_item_tag or rte_flow_item_metadata. I'm
> uncertain about how the P4-DPDK compiler can manage this aspect. Perhaps
> this particular aspect should be addressed by each vendor's individual
> backend compiler, while we focus on defining the specifications for the
> output and providing the common components for parser analysis.
>
> If we take the compiler path, Why we need vendor specific data?
Let's consider the following scenario:
Assume that a hardware device contains metadata that can be passed between different stages of a pipeline.
For instance, in stage A, a rule is matched, and the metadata is set. In stage B, this metadata is used as a match key.
To design the API calls for the above situation using rte_flow, my understanding is that we need to map a rte_flow_item_tag or rte_flow_item_metadata to the corresponding metadata portion (including offset and size).
This way, the driver can understand how to configure the hardware accordingly.
In P4, we define data structures to abstract the metadata, and the vender specific-backend compiler determines the arrangement of the metadata space.
However, in our case, how does the proposed compiler establish the mapping from the P4 metadata key to rte_flow without support from the backend compiler?
>
>
> >
> > > 2) Update https://github.com/p4lang/p4-dpdk-target or introduce
> > > common library in DPDK to map compiler output (spec file) to
> > > rte_flow objects invocations.
> >
> > I'm not quite sure why we need to update the p4-dpdk-target project, as
> its purpose is to utilize DPDK for building a software pipeline using P4.
> However, if we do require the introduction of a common library in DPDK, the
> following questions arise:
> >
> > 1. What will the API of the library look like? Will it still maintain a table-
> driven interface that is compatible with P4 runtime? What are the key
> differences compared to the current proposal?
>
> Not sure why we require table driver interface, The common code will parse
> the compiler output and create the rte_flow objects.
Of course, the DPDK library provides helpful functions for P4 applications to determine how to call rte_flow.
>
> > 2. During runtime, will the library load the spec file (output of the compiler)
> and construct a mapping from P4 tables/actions to the rte_flow API? Is my
> understanding correct?
>
> 1) During the library init time, It will parse the spec file and create the
> specific rte_flow objects
> 2) When p4 runtime is invoked, data and table name comes over runtime
> API. The library can do a look-up to find the rte_flow object from name, and
> do table operations on that object with data provided by the runtime API.
>
>
> > 3. Some hardware vendors already have backend P4 compilers that are
> capable of generating hints for configuring hardware based on tables/actions.
> Is it possible to incorporate a "pass-through" mode within this library?
>
> Not sure, what is the purpose of this library then in first place, Going back to
> original question? Why DPDK abstraction of p4 table is needed in DPDK as
> the p4 is the API contract? Why not a rawdev PMD to leverage EAL services.
This is not a valid question with above understanding.
>
>
> >
> > Thanks
> > Qi
> >
^ permalink raw reply [relevance 2%]
* Re: [RFC] lib/ethdev: introduce table driven APIs
@ 2023-06-19 9:52 5% ` Jerin Jacob
2023-06-20 1:52 2% ` Zhang, Qi Z
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2023-06-19 9:52 UTC (permalink / raw)
To: Zhang, Qi Z
Cc: Dumitrescu, Cristian, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
david.marchand, Richardson, Bruce, jerinj, ferruh.yigit,
Mcnamara, John, Zhang, Helin, techboard, dev, Ivan Malov
On Mon, Jun 19, 2023 at 5:53 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Friday, June 16, 2023 9:20 AM
> > To: Zhang, Qi Z <qi.z.zhang@intel.com>; Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com>
> > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > <thomas@monjalon.net>; david.marchand@redhat.com; Richardson, Bruce
> > <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> > Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> > <ivan.malov@arknetworks.am>
> > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> >
> > On Thu, Jun 15, 2023 at 7:36 PM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> > >
> >
> > > > > If we assume that the application is not P4-aware, it will consume
> > > > > existing
> > > > rte_flow API for flow offloading. In this case, all we need to do is
> > > > implement it in the PMD, which will be a highly hardware-specific
> > > > task. Do you propose generalizing this common part?
> > > > >
> > > > > On the other hand, if the application is P4-aware, we can assume
> > > > > that
> > > > there won't be a need for translation between P4 tokens and rte_flow
> > > > protocols in the PMD.
> > > >
> > > > I agree, Translation is BAD. There are two elements to that.
> > > > 1)if it is p4 aware application, why bother with DPDK abstraction?
> > > > 2)Can we use compiler techniques to avoid the cost of translation if
> > > > P4- aware path is needed in DPDK. Rather than creating yet another
> > > > library. In this context, that would translate to some of your
> > > > compiler and FW work making as generic so that _any_ other rte_flow
> > > > based driver can use and improve it.
> > >
> > >
> > > Ok, I would like to gain a better understanding. Below is my current
> > understanding:
> > >
> > > There are no plans to introduce any new API from DPDK. However, your
> > proposal suggests the creation of a tool, such as a compiler, which would
> > assist in generating a translation layer from P4 table/actions to rte_flow for
> > user application like p4 runtime backend that based on DPDK.
> > >
> > > Could you provide more details about the design? Specifically, I would like
> > to know what the input for the compiler is and who is responsible for
> > generating that input, as well as the process involved.
> > >
> > > I apologize if I have not grasped the complete picture, but I would
> > appreciate your patience.
> >
> > + @Cristian Dumitrescu
> >
> > There is already a lot of p4(just based on DPDK lib/pipeline SW, not with any
> > HW acceleration) with DPDK. Not sure how much it overlaps, and how clean
> > is this to integrate with existing SW or "create new one"?
> > I would think, enhancing the current p4-dpdk support by using rte_flow
> > backend. That would translate to
> > 1) Update https://github.com/p4lang/p4c/tree/main/backends/dpdk to
> > understand generic p4 table key token to rte_flow token for spec file
> > generation.
>
> OK, I assume that the compiler should have the capability to comprehend the logic of the P4 parser and determine the appropriate mapping of each key field in the P4 table to an rte_flow header. This process should be independent of any specific vendor.
Yes.
>
> However, the question arises regarding how to handle vendor-specific data, which also can be part of the table / action key and could potentially be mapped to either rte_flow_item_tag or rte_flow_item_metadata. I'm uncertain about how the P4-DPDK compiler can manage this aspect. Perhaps this particular aspect should be addressed by each vendor's individual backend compiler, while we focus on defining the specifications for the output and providing the common components for parser analysis.
If we take the compiler path, Why we need vendor specific data?
>
> > 2) Update https://github.com/p4lang/p4-dpdk-target or introduce common
> > library in DPDK to map compiler output (spec file) to rte_flow objects
> > invocations.
>
> I'm not quite sure why we need to update the p4-dpdk-target project, as its purpose is to utilize DPDK for building a software pipeline using P4. However, if we do require the introduction of a common library in DPDK, the following questions arise:
>
> 1. What will the API of the library look like? Will it still maintain a table-driven interface that is compatible with P4 runtime? What are the key differences compared to the current proposal?
Not sure why we require table driver interface, The common code will
parse the compiler output and create the rte_flow objects.
> 2. During runtime, will the library load the spec file (output of the compiler) and construct a mapping from P4 tables/actions to the rte_flow API? Is my understanding correct?
1) During the library init time, It will parse the spec file and
create the specific rte_flow objects
2) When p4 runtime is invoked, data and table name comes over runtime
API. The library can do a look-up to find the rte_flow object from
name, and do table operations on that object with data provided by the
runtime API.
> 3. Some hardware vendors already have backend P4 compilers that are capable of generating hints for configuring hardware based on tables/actions. Is it possible to incorporate a "pass-through" mode within this library?
Not sure, what is the purpose of this library then in first place,
Going back to original question? Why DPDK abstraction of p4 table is
needed in DPDK as the p4 is the API contract? Why not a rawdev PMD to
leverage EAL services.
>
> Thanks
> Qi
>
^ permalink raw reply [relevance 5%]
* RE: [RFC] lib/ethdev: introduce table driven APIs
2023-06-15 8:37 4% ` Jerin Jacob
@ 2023-06-15 13:25 2% ` Zhang, Qi Z
0 siblings, 1 reply; 53+ results
From: Zhang, Qi Z @ 2023-06-15 13:25 UTC (permalink / raw)
To: Jerin Jacob
Cc: Ori Kam, NBU-Contact-Thomas Monjalon (EXTERNAL),
david.marchand, Richardson, Bruce, jerinj, ferruh.yigit,
Mcnamara, John, Zhang, Helin, techboard, dev, Ivan Malov
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, June 15, 2023 4:38 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; david.marchand@redhat.com; Richardson, Bruce
> <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> <ivan.malov@arknetworks.am>
> Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
>
> On Thu, Jun 15, 2023 at 1:12 PM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Thursday, June 15, 2023 2:21 PM
> > > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > Richardson, Bruce <bruce.richardson@intel.com>; jerinj@marvell.com;
> > > ferruh.yigit@amd.com; Mcnamara, John <john.mcnamara@intel.com>;
> > > Zhang, Helin <helin.zhang@intel.com>; techboard@dpdk.org;
> > > dev@dpdk.org; Ivan Malov <ivan.malov@arknetworks.am>
> > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> > >
> > > On Thu, Jun 15, 2023 at 11:33 AM Zhang, Qi Z <qi.z.zhang@intel.com>
> wrote:
> > > >
> > > > Hi Jerin:
> > >
> > > Hi Qi
> > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Thursday, June 15, 2023 12:58 PM
> > > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > > > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > > > Richardson, Bruce <bruce.richardson@intel.com>;
> > > > > jerinj@marvell.com; ferruh.yigit@amd.com; Mcnamara, John
> > > > > <john.mcnamara@intel.com>; Zhang, Helin <helin.zhang@intel.com>;
> > > > > techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> > > > > <ivan.malov@arknetworks.am>
> > > > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> > > > >
> > > > > On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z
> > > > > <qi.z.zhang@intel.com>
> > > wrote:
> > > > > >
> > > > > > Hi Ori:
> > > > > >
> > > > > > Thank you for your review!
> > > > > > Comment inline.
> > > > > > Please let me know if anything I missed.
> > > > > >
> > > > > > Thanks
> > > > > > Qi
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ori Kam <orika@nvidia.com>
> > > > > > > Sent: Thursday, June 15, 2023 2:31 AM
> > > > > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; NBU-Contact-Thomas
> > > > > > > Monjalon
> > > > > > > (EXTERNAL) <thomas@monjalon.net>;
> david.marchand@redhat.com;
> > > > > > > Richardson, Bruce <bruce.richardson@intel.com>;
> > > > > > > jerinj@marvell.com; ferruh.yigit@amd.com
> > > > > > > Cc: Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > > > > > > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org
> > > > > > > Subject: RE: [RFC] lib/ethdev:
> > > > > > >
> > > > > > > Hi Qi,
> > > > > > >
> > > > > > >
> > > > > > > 1. it may be useful to get some general calling flow what
> > > > > > > comes from the application, what comes from the compiler.
> > > > > > > Simple example will be good.
> > > > > >
> > > > > > An example of decap VXLAN TCP flow is explained in problem
> > > > > > statement
> > > > > > (http://mails.dpdk.org/archives/dev/2023-May/267719.html)
> > > > > > covering the following information.
> > > > > >
> > > > > > 1. the p4 source code, the definition of the table and actions 2.
> > > > > > the table / action hints generated by the compiler, details to
> > > > > > each
> > > fields.
> > > > > > 3. How the Control Plane Application utilizes the P4 Runtime
> > > > > > API to program the rule with the respective table and action
> > > > > > IDs
> > > > > >
> > > > > > The DPDK PMD is responsible for loading the hints generated by
> > > > > > the
> > > > > compiler.
> > > > > > This enables the PMD to accept requests from the P4 Runtime
> > > > > > and reject
> > > > > any incompatible request.
> > > > >
> > > > > I see two different types of device/system category
> > > > >
> > > > > 1) HW + SW/FW combination that really understands p4 structures
> > > > > and job of the driver to is to give work to HW/SW as p4
> > > > > structure generated from vendor specific compiler and runtime
> > > > > gRPC message
> > > > > 2) Existing HW and SW drivers implements rte-flow driver.
> > > > >
> > > > > For item (1), if end user application is using P4 program and P4
> > > > > runtime and this is _API contract_ to application, Not sure why
> > > > > end user care it is DPDK PMD or not?
> > > >
> > > > That's true. DPDK as a platform that manage the hardware, it is
> > > > required to
> > > provide a channel that connects applications with the hardware
> > > responsible for implementing the contract.
> > > > In this context, the PMD (ethdev) serves as the conduit that can
> > > > fulfill this
> > > requirement.
> > >
> > > I meant vdev + rawdev combo can be used to talk to FW.
> >
> > OK, I will comment this together when vdev + rawdev be mentioned again
> at below.
> >
> > >
> > > > > If driver writer care about using DPDK for driver framework for
> > > > > EAL services, simply using vdev etc would be enough. Right?
> > > >
> > > > I may not fully understand this, a vdev should have a device type,
> > > > I didn't
> > > see any issue for a ethdev vdev to implement the table-driven APIs.
> > >
> > > See above.
> > >
> > > There is a lot of overlap between rte_flow and table driven API is the
> issue.
> > > To make things worst, there is also lib/table/ API.
> >
> > I assume this is just the concern about naming? At least, they are target to
> different usage.
>
> Not the naming of library. Duplicate functional APIs to express a specific use
> case for HW.
>
> >
> > >
> > > >
> > > > >
> > > > > For item (2), I think, interest is how to offload p4 workload to
> > > > > rte_flow. So that _existing_ drivers implements rte_flow can
> > > > > support
> > > > > p4 naturally in addition to existing rte_flow API. If that is
> > > > > direction, then we need to the following.
> > > >
> > > > While the idea of offloading P4 to rte_flow is certainly
> > > > interesting, it
> > > doesn't seem to directly address our initial problem statement.
> > > > The primary objective is to find a solution for offloading
> > > > rte_flow into a P4-
> > > based pipeline.
> > >
> > > Isn't same? If not, Please elaborate on "P4 to rte_flow mapping" vs
> > > "offloading rte_flow into a P4-based pipeline"
> >
> > OK I guess the gap here is I may not fully understand is how we
> > defined the case of item(2) Existing HW and SW drivers implements rte-
> flow driver.
> >
> > If we assume that the application is not P4-aware, it will consume existing
> rte_flow API for flow offloading. In this case, all we need to do is implement
> it in the PMD, which will be a highly hardware-specific task. Do you propose
> generalizing this common part?
> >
> > On the other hand, if the application is P4-aware, we can assume that
> there won't be a need for translation between P4 tokens and rte_flow
> protocols in the PMD.
>
> I agree, Translation is BAD. There are two elements to that.
> 1)if it is p4 aware application, why bother with DPDK abstraction?
> 2)Can we use compiler techniques to avoid the cost of translation if P4-
> aware path is needed in DPDK. Rather than creating yet another library. In
> this context, that would translate to some of your compiler and FW work
> making as generic so that _any_ other rte_flow based driver can use and
> improve it.
Ok, I would like to gain a better understanding. Below is my current understanding:
There are no plans to introduce any new API from DPDK. However, your proposal suggests the creation of a tool, such as a compiler, which would assist in generating a translation layer from P4 table/actions to rte_flow for user application like p4 runtime backend that based on DPDK.
Could you provide more details about the design? Specifically, I would like to know what the input for the compiler is and who is responsible for generating that input, as well as the process involved.
I apologize if I have not grasped the complete picture, but I would appreciate your patience.
>
> >
> > >
> > >
> > > >
> > > > We have identified two distinct use cases:
> > > >
> > > > P4-Aware Applications:
> > > >
> > > > For applications that are already P4 aware, the proposal suggests
> > > > the
> > > introduction of a new set of APIs to rte_flow.
> > > > These APIs aim to facilitate seamless integration between DPDK and
> > > > P4
> > > aware applications.
> > >
> > > Counter argument for that is, If the P4 is API contract then why
> > > bother with DPDK abstraction use vdev + rawdev talk to FW as PMD is
> > > just passing message to FW. FW is doing the heavy lifting anyway.
> >
> > We are attempting to generalize the common aspects, considering that P4
> Runtime is a standard API. It appears worthwhile to expose certain APIs that
> can assist its backend implementation.
>
> I agree. If backend is built on top rte_flow and some compiler bits. I think,
> multiple consumer can use it.
> Otherwise, we are making the API for a p4 FW backend is needed.
>
>
> > I may need some time to understand the concept of vdev +rawdev combo
> solution, currently one question in my mind is: in this solution, is above
> consideration covered?
> >
> > Thanks
> > Qi
> >
> > >
> > >
> > > >
> > > > Non-P4 Aware Applications:
> > > >
> > > > In the case, our focus is on bridging the existing rte_flow API to
> > > > the
> > > underlying P4 pipeline.
> > > > Currently, we haven't identified any significant gaps in the DPDK APIs.
> > > > The key challenge lies in handling the translation process within
> > > > the PMD
> > > >
> > > > Thanks
> > > > Qi
> > > >
> > > > >
> > > > > a)Improve p4-dpdk compiler backend or add new compiler DPDK
> > > backend
> > > > > to understand the rte_flow and have helper library in DPDK to
> > > > > understand the compiler spec file to translate to rte_flow
> > > > > objects b)Similar case for runtime API. i.e Have helper
> > > > > functions to translate
> > > > > p4 MatchField name etc to appropriate rte_flow objects.
> > > > > c)Enhance base rte_flow specification if there are any
> > > > > fundamental gaps to express the new pattern or actions (which is
> > > > > not specific to
> > > > > p4 and applicable for any flow matching use case)
> > > > >
> > > > > If we introduce compiler in the pipeline, a lot of translation
> > > > > will get in the slowpath. And for runtime API, the translation
> > > > > primarily will be name to rte_flow object lookup (which is not
> > > > > that costly) and using rte_flow_template etc. to amortize the cost by
> making it burst.
> > > > >
> > > > > Just my 2c.
> >
^ permalink raw reply [relevance 2%]
* Re: [RFC] lib/ethdev: introduce table driven APIs
2023-06-15 7:42 8% ` Zhang, Qi Z
@ 2023-06-15 8:37 4% ` Jerin Jacob
2023-06-15 13:25 2% ` Zhang, Qi Z
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2023-06-15 8:37 UTC (permalink / raw)
To: Zhang, Qi Z
Cc: Ori Kam, NBU-Contact-Thomas Monjalon (EXTERNAL),
david.marchand, Richardson, Bruce, jerinj, ferruh.yigit,
Mcnamara, John, Zhang, Helin, techboard, dev, Ivan Malov
On Thu, Jun 15, 2023 at 1:12 PM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Thursday, June 15, 2023 2:21 PM
> > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > <thomas@monjalon.net>; david.marchand@redhat.com; Richardson, Bruce
> > <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> > Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> > <ivan.malov@arknetworks.am>
> > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> >
> > On Thu, Jun 15, 2023 at 11:33 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> > >
> > > Hi Jerin:
> >
> > Hi Qi
> >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Thursday, June 15, 2023 12:58 PM
> > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > > Richardson, Bruce <bruce.richardson@intel.com>; jerinj@marvell.com;
> > > > ferruh.yigit@amd.com; Mcnamara, John <john.mcnamara@intel.com>;
> > > > Zhang, Helin <helin.zhang@intel.com>; techboard@dpdk.org;
> > > > dev@dpdk.org; Ivan Malov <ivan.malov@arknetworks.am>
> > > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> > > >
> > > > On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z <qi.z.zhang@intel.com>
> > wrote:
> > > > >
> > > > > Hi Ori:
> > > > >
> > > > > Thank you for your review!
> > > > > Comment inline.
> > > > > Please let me know if anything I missed.
> > > > >
> > > > > Thanks
> > > > > Qi
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ori Kam <orika@nvidia.com>
> > > > > > Sent: Thursday, June 15, 2023 2:31 AM
> > > > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; NBU-Contact-Thomas
> > > > > > Monjalon
> > > > > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > > > > Richardson, Bruce <bruce.richardson@intel.com>;
> > > > > > jerinj@marvell.com; ferruh.yigit@amd.com
> > > > > > Cc: Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > > > > > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org
> > > > > > Subject: RE: [RFC] lib/ethdev:
> > > > > >
> > > > > > Hi Qi,
> > > > > >
> > > > > >
> > > > > > 1. it may be useful to get some general calling flow what comes
> > > > > > from the application, what comes from the compiler.
> > > > > > Simple example will be good.
> > > > >
> > > > > An example of decap VXLAN TCP flow is explained in problem
> > > > > statement
> > > > > (http://mails.dpdk.org/archives/dev/2023-May/267719.html)
> > > > > covering the following information.
> > > > >
> > > > > 1. the p4 source code, the definition of the table and actions 2.
> > > > > the table / action hints generated by the compiler, details to each
> > fields.
> > > > > 3. How the Control Plane Application utilizes the P4 Runtime API
> > > > > to program the rule with the respective table and action IDs
> > > > >
> > > > > The DPDK PMD is responsible for loading the hints generated by the
> > > > compiler.
> > > > > This enables the PMD to accept requests from the P4 Runtime and
> > > > > reject
> > > > any incompatible request.
> > > >
> > > > I see two different types of device/system category
> > > >
> > > > 1) HW + SW/FW combination that really understands p4 structures and
> > > > job of the driver to is to give work to HW/SW as p4 structure
> > > > generated from vendor specific compiler and runtime gRPC message
> > > > 2) Existing HW and SW drivers implements rte-flow driver.
> > > >
> > > > For item (1), if end user application is using P4 program and P4
> > > > runtime and this is _API contract_ to application, Not sure why end
> > > > user care it is DPDK PMD or not?
> > >
> > > That's true. DPDK as a platform that manage the hardware, it is required to
> > provide a channel that connects applications with the hardware responsible
> > for implementing the contract.
> > > In this context, the PMD (ethdev) serves as the conduit that can fulfill this
> > requirement.
> >
> > I meant vdev + rawdev combo can be used to talk to FW.
>
> OK, I will comment this together when vdev + rawdev be mentioned again at below.
>
> >
> > > > If driver writer care about using DPDK for driver framework for EAL
> > > > services, simply using vdev etc would be enough. Right?
> > >
> > > I may not fully understand this, a vdev should have a device type, I didn't
> > see any issue for a ethdev vdev to implement the table-driven APIs.
> >
> > See above.
> >
> > There is a lot of overlap between rte_flow and table driven API is the issue.
> > To make things worst, there is also lib/table/ API.
>
> I assume this is just the concern about naming? At least, they are target to different usage.
Not the naming of library. Duplicate functional APIs to express a
specific use case for HW.
>
> >
> > >
> > > >
> > > > For item (2), I think, interest is how to offload p4 workload to
> > > > rte_flow. So that _existing_ drivers implements rte_flow can support
> > > > p4 naturally in addition to existing rte_flow API. If that is
> > > > direction, then we need to the following.
> > >
> > > While the idea of offloading P4 to rte_flow is certainly interesting, it
> > doesn't seem to directly address our initial problem statement.
> > > The primary objective is to find a solution for offloading rte_flow into a P4-
> > based pipeline.
> >
> > Isn't same? If not, Please elaborate on "P4 to rte_flow mapping" vs
> > "offloading rte_flow into a P4-based pipeline"
>
> OK I guess the gap here is I may not fully understand is
> how we defined the case of item(2) Existing HW and SW drivers implements rte-flow driver.
>
> If we assume that the application is not P4-aware, it will consume existing rte_flow API for flow offloading. In this case, all we need to do is implement it in the PMD, which will be a highly hardware-specific task. Do you propose generalizing this common part?
>
> On the other hand, if the application is P4-aware, we can assume that there won't be a need for translation between P4 tokens and rte_flow protocols in the PMD.
I agree, Translation is BAD. There are two elements to that.
1)if it is p4 aware application, why bother with DPDK abstraction?
2)Can we use compiler techniques to avoid the cost of translation if
P4-aware path is needed in DPDK. Rather than creating yet another
library. In this context, that would translate to some of your
compiler and FW work making as
generic so that _any_ other rte_flow based driver can use and improve it.
>
> >
> >
> > >
> > > We have identified two distinct use cases:
> > >
> > > P4-Aware Applications:
> > >
> > > For applications that are already P4 aware, the proposal suggests the
> > introduction of a new set of APIs to rte_flow.
> > > These APIs aim to facilitate seamless integration between DPDK and P4
> > aware applications.
> >
> > Counter argument for that is, If the P4 is API contract then why bother with
> > DPDK abstraction use vdev + rawdev talk to FW as PMD is just passing
> > message to FW. FW is doing the heavy lifting anyway.
>
> We are attempting to generalize the common aspects, considering that P4 Runtime is a standard API. It appears worthwhile to expose certain APIs that can assist its backend implementation.
I agree. If backend is built on top rte_flow and some compiler bits. I
think, multiple consumer can use it.
Otherwise, we are making the API for a p4 FW backend is needed.
> I may need some time to understand the concept of vdev +rawdev combo solution, currently one question in my mind is: in this solution, is above consideration covered?
>
> Thanks
> Qi
>
> >
> >
> > >
> > > Non-P4 Aware Applications:
> > >
> > > In the case, our focus is on bridging the existing rte_flow API to the
> > underlying P4 pipeline.
> > > Currently, we haven't identified any significant gaps in the DPDK APIs.
> > > The key challenge lies in handling the translation process within the
> > > PMD
> > >
> > > Thanks
> > > Qi
> > >
> > > >
> > > > a)Improve p4-dpdk compiler backend or add new compiler DPDK
> > backend
> > > > to understand the rte_flow and have helper library in DPDK to
> > > > understand the compiler spec file to translate to rte_flow objects
> > > > b)Similar case for runtime API. i.e Have helper functions to
> > > > translate
> > > > p4 MatchField name etc to appropriate rte_flow objects.
> > > > c)Enhance base rte_flow specification if there are any fundamental
> > > > gaps to express the new pattern or actions (which is not specific to
> > > > p4 and applicable for any flow matching use case)
> > > >
> > > > If we introduce compiler in the pipeline, a lot of translation will
> > > > get in the slowpath. And for runtime API, the translation primarily
> > > > will be name to rte_flow object lookup (which is not that costly)
> > > > and using rte_flow_template etc. to amortize the cost by making it burst.
> > > >
> > > > Just my 2c.
>
^ permalink raw reply [relevance 4%]
* RE: [RFC] lib/ethdev: introduce table driven APIs
2023-06-15 6:21 6% ` Jerin Jacob
@ 2023-06-15 7:42 8% ` Zhang, Qi Z
2023-06-15 8:37 4% ` Jerin Jacob
0 siblings, 1 reply; 53+ results
From: Zhang, Qi Z @ 2023-06-15 7:42 UTC (permalink / raw)
To: Jerin Jacob
Cc: Ori Kam, NBU-Contact-Thomas Monjalon (EXTERNAL),
david.marchand, Richardson, Bruce, jerinj, ferruh.yigit,
Mcnamara, John, Zhang, Helin, techboard, dev, Ivan Malov
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, June 15, 2023 2:21 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; david.marchand@redhat.com; Richardson, Bruce
> <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> <ivan.malov@arknetworks.am>
> Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
>
> On Thu, Jun 15, 2023 at 11:33 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> >
> > Hi Jerin:
>
> Hi Qi
>
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Thursday, June 15, 2023 12:58 PM
> > > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > Richardson, Bruce <bruce.richardson@intel.com>; jerinj@marvell.com;
> > > ferruh.yigit@amd.com; Mcnamara, John <john.mcnamara@intel.com>;
> > > Zhang, Helin <helin.zhang@intel.com>; techboard@dpdk.org;
> > > dev@dpdk.org; Ivan Malov <ivan.malov@arknetworks.am>
> > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> > >
> > > On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z <qi.z.zhang@intel.com>
> wrote:
> > > >
> > > > Hi Ori:
> > > >
> > > > Thank you for your review!
> > > > Comment inline.
> > > > Please let me know if anything I missed.
> > > >
> > > > Thanks
> > > > Qi
> > > >
> > > > > -----Original Message-----
> > > > > From: Ori Kam <orika@nvidia.com>
> > > > > Sent: Thursday, June 15, 2023 2:31 AM
> > > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; NBU-Contact-Thomas
> > > > > Monjalon
> > > > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > > > Richardson, Bruce <bruce.richardson@intel.com>;
> > > > > jerinj@marvell.com; ferruh.yigit@amd.com
> > > > > Cc: Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > > > > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org
> > > > > Subject: RE: [RFC] lib/ethdev:
> > > > >
> > > > > Hi Qi,
> > > > >
> > > > >
> > > > > 1. it may be useful to get some general calling flow what comes
> > > > > from the application, what comes from the compiler.
> > > > > Simple example will be good.
> > > >
> > > > An example of decap VXLAN TCP flow is explained in problem
> > > > statement
> > > > (http://mails.dpdk.org/archives/dev/2023-May/267719.html)
> > > > covering the following information.
> > > >
> > > > 1. the p4 source code, the definition of the table and actions 2.
> > > > the table / action hints generated by the compiler, details to each
> fields.
> > > > 3. How the Control Plane Application utilizes the P4 Runtime API
> > > > to program the rule with the respective table and action IDs
> > > >
> > > > The DPDK PMD is responsible for loading the hints generated by the
> > > compiler.
> > > > This enables the PMD to accept requests from the P4 Runtime and
> > > > reject
> > > any incompatible request.
> > >
> > > I see two different types of device/system category
> > >
> > > 1) HW + SW/FW combination that really understands p4 structures and
> > > job of the driver to is to give work to HW/SW as p4 structure
> > > generated from vendor specific compiler and runtime gRPC message
> > > 2) Existing HW and SW drivers implements rte-flow driver.
> > >
> > > For item (1), if end user application is using P4 program and P4
> > > runtime and this is _API contract_ to application, Not sure why end
> > > user care it is DPDK PMD or not?
> >
> > That's true. DPDK as a platform that manage the hardware, it is required to
> provide a channel that connects applications with the hardware responsible
> for implementing the contract.
> > In this context, the PMD (ethdev) serves as the conduit that can fulfill this
> requirement.
>
> I meant vdev + rawdev combo can be used to talk to FW.
OK, I will comment this together when vdev + rawdev be mentioned again at below.
>
> > > If driver writer care about using DPDK for driver framework for EAL
> > > services, simply using vdev etc would be enough. Right?
> >
> > I may not fully understand this, a vdev should have a device type, I didn't
> see any issue for a ethdev vdev to implement the table-driven APIs.
>
> See above.
>
> There is a lot of overlap between rte_flow and table driven API is the issue.
> To make things worst, there is also lib/table/ API.
I assume this is just the concern about naming? At least, they are target to different usage.
>
> >
> > >
> > > For item (2), I think, interest is how to offload p4 workload to
> > > rte_flow. So that _existing_ drivers implements rte_flow can support
> > > p4 naturally in addition to existing rte_flow API. If that is
> > > direction, then we need to the following.
> >
> > While the idea of offloading P4 to rte_flow is certainly interesting, it
> doesn't seem to directly address our initial problem statement.
> > The primary objective is to find a solution for offloading rte_flow into a P4-
> based pipeline.
>
> Isn't same? If not, Please elaborate on "P4 to rte_flow mapping" vs
> "offloading rte_flow into a P4-based pipeline"
OK I guess the gap here is I may not fully understand is
how we defined the case of item(2) Existing HW and SW drivers implements rte-flow driver.
If we assume that the application is not P4-aware, it will consume existing rte_flow API for flow offloading. In this case, all we need to do is implement it in the PMD, which will be a highly hardware-specific task. Do you propose generalizing this common part?
On the other hand, if the application is P4-aware, we can assume that there won't be a need for translation between P4 tokens and rte_flow protocols in the PMD.
>
>
> >
> > We have identified two distinct use cases:
> >
> > P4-Aware Applications:
> >
> > For applications that are already P4 aware, the proposal suggests the
> introduction of a new set of APIs to rte_flow.
> > These APIs aim to facilitate seamless integration between DPDK and P4
> aware applications.
>
> Counter argument for that is, If the P4 is API contract then why bother with
> DPDK abstraction use vdev + rawdev talk to FW as PMD is just passing
> message to FW. FW is doing the heavy lifting anyway.
We are attempting to generalize the common aspects, considering that P4 Runtime is a standard API. It appears worthwhile to expose certain APIs that can assist its backend implementation.
I may need some time to understand the concept of vdev +rawdev combo solution, currently one question in my mind is: in this solution, is above consideration covered?
Thanks
Qi
>
>
> >
> > Non-P4 Aware Applications:
> >
> > In the case, our focus is on bridging the existing rte_flow API to the
> underlying P4 pipeline.
> > Currently, we haven't identified any significant gaps in the DPDK APIs.
> > The key challenge lies in handling the translation process within the
> > PMD
> >
> > Thanks
> > Qi
> >
> > >
> > > a)Improve p4-dpdk compiler backend or add new compiler DPDK
> backend
> > > to understand the rte_flow and have helper library in DPDK to
> > > understand the compiler spec file to translate to rte_flow objects
> > > b)Similar case for runtime API. i.e Have helper functions to
> > > translate
> > > p4 MatchField name etc to appropriate rte_flow objects.
> > > c)Enhance base rte_flow specification if there are any fundamental
> > > gaps to express the new pattern or actions (which is not specific to
> > > p4 and applicable for any flow matching use case)
> > >
> > > If we introduce compiler in the pipeline, a lot of translation will
> > > get in the slowpath. And for runtime API, the translation primarily
> > > will be name to rte_flow object lookup (which is not that costly)
> > > and using rte_flow_template etc. to amortize the cost by making it burst.
> > >
> > > Just my 2c.
^ permalink raw reply [relevance 8%]
* Re: [RFC] lib/ethdev: introduce table driven APIs
@ 2023-06-15 6:21 6% ` Jerin Jacob
2023-06-15 7:42 8% ` Zhang, Qi Z
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2023-06-15 6:21 UTC (permalink / raw)
To: Zhang, Qi Z
Cc: Ori Kam, NBU-Contact-Thomas Monjalon (EXTERNAL),
david.marchand, Richardson, Bruce, jerinj, ferruh.yigit,
Mcnamara, John, Zhang, Helin, techboard, dev, Ivan Malov
On Thu, Jun 15, 2023 at 11:33 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
>
> Hi Jerin:
Hi Qi
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Thursday, June 15, 2023 12:58 PM
> > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > <thomas@monjalon.net>; david.marchand@redhat.com; Richardson, Bruce
> > <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> > Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> > <ivan.malov@arknetworks.am>
> > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> >
> > On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> > >
> > > Hi Ori:
> > >
> > > Thank you for your review!
> > > Comment inline.
> > > Please let me know if anything I missed.
> > >
> > > Thanks
> > > Qi
> > >
> > > > -----Original Message-----
> > > > From: Ori Kam <orika@nvidia.com>
> > > > Sent: Thursday, June 15, 2023 2:31 AM
> > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; NBU-Contact-Thomas Monjalon
> > > > (EXTERNAL) <thomas@monjalon.net>; david.marchand@redhat.com;
> > > > Richardson, Bruce <bruce.richardson@intel.com>; jerinj@marvell.com;
> > > > ferruh.yigit@amd.com
> > > > Cc: Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > > > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org
> > > > Subject: RE: [RFC] lib/ethdev:
> > > >
> > > > Hi Qi,
> > > >
> > > >
> > > > 1. it may be useful to get some general calling flow what comes from
> > > > the application, what comes from the compiler.
> > > > Simple example will be good.
> > >
> > > An example of decap VXLAN TCP flow is explained in problem statement
> > > (http://mails.dpdk.org/archives/dev/2023-May/267719.html)
> > > covering the following information.
> > >
> > > 1. the p4 source code, the definition of the table and actions 2. the
> > > table / action hints generated by the compiler, details to each fields.
> > > 3. How the Control Plane Application utilizes the P4 Runtime API to
> > > program the rule with the respective table and action IDs
> > >
> > > The DPDK PMD is responsible for loading the hints generated by the
> > compiler.
> > > This enables the PMD to accept requests from the P4 Runtime and reject
> > any incompatible request.
> >
> > I see two different types of device/system category
> >
> > 1) HW + SW/FW combination that really understands p4 structures and job
> > of the driver to is to give work to HW/SW as p4 structure generated from
> > vendor specific compiler and runtime gRPC message
> > 2) Existing HW and SW drivers implements rte-flow driver.
> >
> > For item (1), if end user application is using P4 program and P4 runtime and
> > this is _API contract_ to application, Not sure why end user care it is DPDK
> > PMD or not?
>
> That's true. DPDK as a platform that manage the hardware, it is required to provide a channel that connects applications with the hardware responsible for implementing the contract.
> In this context, the PMD (ethdev) serves as the conduit that can fulfill this requirement.
I meant vdev + rawdev combo can be used to talk to FW.
> > If driver writer care about using DPDK for driver framework for
> > EAL services, simply using vdev etc would be enough. Right?
>
> I may not fully understand this, a vdev should have a device type, I didn't see any issue for a ethdev vdev to implement the table-driven APIs.
See above.
There is a lot of overlap between rte_flow and table driven API is the
issue. To make things worst, there is also lib/table/ API.
>
> >
> > For item (2), I think, interest is how to offload p4 workload to rte_flow. So
> > that _existing_ drivers implements rte_flow can support
> > p4 naturally in addition to existing rte_flow API. If that is direction, then we
> > need to the following.
>
> While the idea of offloading P4 to rte_flow is certainly interesting, it doesn't seem to directly address our initial problem statement.
> The primary objective is to find a solution for offloading rte_flow into a P4-based pipeline.
Isn't same? If not, Please elaborate on "P4 to rte_flow mapping" vs
"offloading rte_flow into a P4-based pipeline"
>
> We have identified two distinct use cases:
>
> P4-Aware Applications:
>
> For applications that are already P4 aware, the proposal suggests the introduction of a new set of APIs to rte_flow.
> These APIs aim to facilitate seamless integration between DPDK and P4 aware applications.
Counter argument for that is, If the P4 is API contract then why
bother with DPDK abstraction use vdev + rawdev talk to FW
as PMD is just passing message to FW. FW is doing the heavy lifting anyway.
>
> Non-P4 Aware Applications:
>
> In the case, our focus is on bridging the existing rte_flow API to the underlying P4 pipeline.
> Currently, we haven't identified any significant gaps in the DPDK APIs.
> The key challenge lies in handling the translation process within the PMD
>
> Thanks
> Qi
>
> >
> > a)Improve p4-dpdk compiler backend or add new compiler DPDK backend to
> > understand the rte_flow and have helper library in DPDK to understand the
> > compiler spec file to translate to rte_flow objects b)Similar case for runtime
> > API. i.e Have helper functions to translate
> > p4 MatchField name etc to appropriate rte_flow objects.
> > c)Enhance base rte_flow specification if there are any fundamental gaps to
> > express the new pattern or actions (which is not specific to
> > p4 and applicable for any flow matching use case)
> >
> > If we introduce compiler in the pipeline, a lot of translation will get in the
> > slowpath. And for runtime API, the translation primarily will be name to
> > rte_flow object lookup (which is not that costly) and using
> > rte_flow_template etc. to amortize the cost by making it burst.
> >
> > Just my 2c.
^ permalink raw reply [relevance 6%]
* Re: [dpdk-dev] [PATCH v5 0/8] port ioatfwd app to dmadev
2021-10-26 13:14 8% ` [dpdk-dev] [PATCH v5 " Kevin Laatz
@ 2021-10-27 14:54 0% ` Thomas Monjalon
0 siblings, 0 replies; 53+ results
From: Thomas Monjalon @ 2021-10-27 14:54 UTC (permalink / raw)
To: Kevin Laatz; +Cc: dev, bruce.richardson, fengchengwen, conor.walsh
26/10/2021 15:14, Kevin Laatz:
> This patchset first adds some additional command line options to the
> existing ioatfwd application to enhance usability.
>
> The last 3 patches of this set then port the ioatfwd application to use the
> dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
> all variables etc are renamed to be more appropriate for using with the
> DMAdev library. Lastly, the application itself is renamed to "dmafwd".
Applied, thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 0/8] port ioatfwd app to dmadev
2021-09-10 17:27 8% [dpdk-dev] [PATCH 0/6] port ioatfwd app to dmadev Kevin Laatz
` (2 preceding siblings ...)
2021-10-14 9:53 8% ` [dpdk-dev] [PATCH v4 " Kevin Laatz
@ 2021-10-26 13:14 8% ` Kevin Laatz
2021-10-27 14:54 0% ` Thomas Monjalon
3 siblings, 1 reply; 53+ results
From: Kevin Laatz @ 2021-10-26 13:14 UTC (permalink / raw)
To: dev; +Cc: thomas, bruce.richardson, fengchengwen, conor.walsh, Kevin Laatz
This patchset first adds some additional command line options to the
existing ioatfwd application to enhance usability.
The last 3 patches of this set then port the ioatfwd application to use the
dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
all variables etc are renamed to be more appropriate for using with the
DMAdev library. Lastly, the application itself is renamed to "dmafwd".
---
v5:
- rebase on latest main
- add check to ensure ring_size <= MBUF_RING_SIZE (Chengwen)
v4:
- rebase on dmadev lib v26 patchset
v3:
- add signal-triggered device dump
- add cmd line option to control stats print frequency
- documentation updates
- small miscellaneous changes from review feedback
Kevin Laatz (5):
examples/ioat: add cmd line option to control stats print interval
examples/ioat: add signal-triggered device dumps
examples/ioat: port application to dmadev APIs
examples/ioat: update naming to match change to dmadev
examples/ioat: rename application to dmafwd
Konstantin Ananyev (3):
examples/ioat: always use same lcore for both DMA requests enqueue and
dequeue
examples/ioat: add cmd line option to control DMA batch size
examples/ioat: add cmd line option to control max frame size
.../sample_app_ug/{ioat.rst => dma.rst} | 149 ++--
doc/guides/sample_app_ug/index.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 4 +-
examples/{ioat => dma}/Makefile | 4 +-
examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 638 ++++++++++--------
examples/{ioat => dma}/meson.build | 10 +-
examples/meson.build | 2 +-
7 files changed, 433 insertions(+), 376 deletions(-)
rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (64%)
rename examples/{ioat => dma}/Makefile (97%)
rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (60%)
rename examples/{ioat => dma}/meson.build (63%)
--
2.30.2
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v4 0/8] port ioatfwd app to dmadev
2021-10-14 9:53 8% ` [dpdk-dev] [PATCH v4 " Kevin Laatz
@ 2021-10-26 0:56 0% ` fengchengwen
0 siblings, 0 replies; 53+ results
From: fengchengwen @ 2021-10-26 0:56 UTC (permalink / raw)
To: Kevin Laatz, dev; +Cc: bruce.richardson, conor.walsh
Hi Kevin,
We test whole patch set and found it should add one judgement:
the ring_size should be less than or equal to MBUF_RING_SIZE.
If ring_size greater than MBUF_RING_SIZE, the tracking DMA bufs
may be overwrited when the DMA copy is not in time.
Thanks.
On 2021/10/14 17:53, Kevin Laatz wrote:
> This patchset first adds some additional command line options to the
> existing ioatfwd application to enhance usability.
>
> The last 3 patches of this set then port the ioatfwd application to use the
> dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
> all variables etc are renamed to be more appropriate for using with the
> DMAdev library. Lastly, the application itself is renamed to "dmafwd".
>
> Depends-on: series-19594 ("support dmadev")
>
> ---
> v4:
> - rebase on dmadev lib v26 patchset
> v3:
> - add signal-triggered device dump
> - add cmd line option to control stats print frequency
> - documentation updates
> - small miscellaneous changes from review feedback
>
> Kevin Laatz (5):
> examples/ioat: add cmd line option to control stats print interval
> examples/ioat: add signal-triggered device dumps
> examples/ioat: port application to dmadev APIs
> examples/ioat: update naming to match change to dmadev
> examples/ioat: rename application to dmafwd
>
> Konstantin Ananyev (3):
> examples/ioat: always use same lcore for both DMA requests enqueue and
> dequeue
> examples/ioat: add cmd line option to control DMA batch size
> examples/ioat: add cmd line option to control max frame size
>
> .../sample_app_ug/{ioat.rst => dma.rst} | 149 ++---
> doc/guides/sample_app_ug/index.rst | 2 +-
> doc/guides/sample_app_ug/intro.rst | 4 +-
> examples/{ioat => dma}/Makefile | 4 +-
> examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 632 ++++++++++--------
> examples/{ioat => dma}/meson.build | 10 +-
> examples/meson.build | 2 +-
> 7 files changed, 427 insertions(+), 376 deletions(-)
> rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (64%)
> rename examples/{ioat => dma}/Makefile (97%)
> rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (60%)
> rename examples/{ioat => dma}/meson.build (63%)
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 0/8] port ioatfwd app to dmadev
2021-09-10 17:27 8% [dpdk-dev] [PATCH 0/6] port ioatfwd app to dmadev Kevin Laatz
2021-09-17 16:41 8% ` [dpdk-dev] [PATCH v2 " Kevin Laatz
2021-09-28 16:29 8% ` [dpdk-dev] [PATCH v3 0/8] " Kevin Laatz
@ 2021-10-14 9:53 8% ` Kevin Laatz
2021-10-26 0:56 0% ` fengchengwen
2021-10-26 13:14 8% ` [dpdk-dev] [PATCH v5 " Kevin Laatz
3 siblings, 1 reply; 53+ results
From: Kevin Laatz @ 2021-10-14 9:53 UTC (permalink / raw)
To: dev; +Cc: bruce.richardson, fengchengwen, conor.walsh, Kevin Laatz
This patchset first adds some additional command line options to the
existing ioatfwd application to enhance usability.
The last 3 patches of this set then port the ioatfwd application to use the
dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
all variables etc are renamed to be more appropriate for using with the
DMAdev library. Lastly, the application itself is renamed to "dmafwd".
Depends-on: series-19594 ("support dmadev")
---
v4:
- rebase on dmadev lib v26 patchset
v3:
- add signal-triggered device dump
- add cmd line option to control stats print frequency
- documentation updates
- small miscellaneous changes from review feedback
Kevin Laatz (5):
examples/ioat: add cmd line option to control stats print interval
examples/ioat: add signal-triggered device dumps
examples/ioat: port application to dmadev APIs
examples/ioat: update naming to match change to dmadev
examples/ioat: rename application to dmafwd
Konstantin Ananyev (3):
examples/ioat: always use same lcore for both DMA requests enqueue and
dequeue
examples/ioat: add cmd line option to control DMA batch size
examples/ioat: add cmd line option to control max frame size
.../sample_app_ug/{ioat.rst => dma.rst} | 149 ++---
doc/guides/sample_app_ug/index.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 4 +-
examples/{ioat => dma}/Makefile | 4 +-
examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 632 ++++++++++--------
examples/{ioat => dma}/meson.build | 10 +-
examples/meson.build | 2 +-
7 files changed, 427 insertions(+), 376 deletions(-)
rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (64%)
rename examples/{ioat => dma}/Makefile (97%)
rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (60%)
rename examples/{ioat => dma}/meson.build (63%)
--
2.30.2
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v3 0/8] port ioatfwd app to dmadev
2021-09-10 17:27 8% [dpdk-dev] [PATCH 0/6] port ioatfwd app to dmadev Kevin Laatz
2021-09-17 16:41 8% ` [dpdk-dev] [PATCH v2 " Kevin Laatz
@ 2021-09-28 16:29 8% ` Kevin Laatz
2021-10-14 9:53 8% ` [dpdk-dev] [PATCH v4 " Kevin Laatz
2021-10-26 13:14 8% ` [dpdk-dev] [PATCH v5 " Kevin Laatz
3 siblings, 0 replies; 53+ results
From: Kevin Laatz @ 2021-09-28 16:29 UTC (permalink / raw)
To: dev; +Cc: bruce.richardson, fengchengwen, conor.walsh, Kevin Laatz
This patchset first adds some additional command line options to the
existing ioatfwd application to enhance usability.
The last 3 patches of this set then port the ioatfwd application to use the
dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
all variables etc are renamed to be more appropriate for using with the
DMAdev library. Lastly, the application itself is renamed to "dmafwd".
Depends-on: series-19140 ("support dmadev")
---
v3:
- add signal-triggered device dump
- add cmd line option to control stats print frequency
- documentation updates
- small miscellaneous changes from review feedback
Kevin Laatz (5):
examples/ioat: add cmd line option to control stats print interval
examples/ioat: add signal-triggered device dumps
examples/ioat: port application to dmadev APIs
examples/ioat: update naming to match change to dmadev
examples/ioat: rename application to dmafwd
Konstantin Ananyev (3):
examples/ioat: always use same lcore for both DMA requests enqueue and
dequeue
examples/ioat: add cmd line option to control DMA batch size
examples/ioat: add cmd line option to control max frame size
.../sample_app_ug/{ioat.rst => dma.rst} | 149 ++---
doc/guides/sample_app_ug/index.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 4 +-
examples/{ioat => dma}/Makefile | 4 +-
examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 632 ++++++++++--------
examples/{ioat => dma}/meson.build | 10 +-
examples/meson.build | 2 +-
7 files changed, 427 insertions(+), 376 deletions(-)
rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (64%)
rename examples/{ioat => dma}/Makefile (97%)
rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (60%)
rename examples/{ioat => dma}/meson.build (63%)
--
2.30.2
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v2 0/6] port ioatfwd app to dmadev
2021-09-23 13:53 0% ` fengchengwen
@ 2021-09-23 14:00 0% ` Kevin Laatz
0 siblings, 0 replies; 53+ results
From: Kevin Laatz @ 2021-09-23 14:00 UTC (permalink / raw)
To: fengchengwen, dev; +Cc: bruce.richardson, conor.walsh
Hi Chengwen,
On 23/09/2021 14:53, fengchengwen wrote:
> Hi Kevin,
>
> Can you add the following functions?
> 1. Add dump dmadev which trigger by signal, like:
> ...
> static void
> dma_dump(void)
> {
> uint32_t i, j;
>
> if (copy_mode != COPY_MODE_DMA_NUM)
> return;
>
> for (i = 0; i < cfg.nb_ports; i++) {
> for (j = 0; j < cfg.ports[i].nb_queues; j++)
> rte_dma_dump(cfg.ports[i].dmadev_ids[j], stdout);
> }
> }
> ...
> static void
> signal_handler(int signum)
> {
> if (signum == SIGINT || signum == SIGTERM) {
> printf("\n\nSignal %d received, preparing to exit...\n",
> signum);
> force_quit = true;
> } else if (signum == SIGUSR1) {
> dma_dump();
> }
> }
> ...
> signal(SIGUSR1, signal_handler);
Yes, can add this in the v3.
>
> 2. Controls the output frequency of print_stats. currently fix 1s, hope could control by parameters.
Are you asking for a function to control this? It would probably be
better as a cmdline option IMO. I can add this in v3 also.
Thanks for the feedback!
>
> Thanks.
>
>
> On 2021/9/18 0:41, Kevin Laatz wrote:
>> This patchset first adds some additional command line options to the
>> existing ioatfwd application to enhance usability.
>>
>> The last 3 patches of this set then port the ioatfwd application to use the
>> dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
>> all variables etc are renamed to be more appropriate for using with the
>> DMAdev library. Lastly, the application itself is renamed to "dmafwd".
>>
>> Depends-on: series-18960 ("support dmadev")
>>
>> Kevin Laatz (3):
>> examples/ioat: port application to dmadev APIs
>> examples/ioat: update naming to match change to dmadev
>> examples/ioat: rename application to dmafwd
>>
>> Konstantin Ananyev (3):
>> examples/ioat: always use same lcore for both DMA requests enqueue and
>> dequeue
>> examples/ioat: add cmd-line option to control DMA batch size
>> examples/ioat: add cmd line option to control max frame size
>>
>> MAINTAINERS | 7 +-
>> .../sample_app_ug/{ioat.rst => dma.rst} | 114 ++--
>> doc/guides/sample_app_ug/index.rst | 2 +-
>> doc/guides/sample_app_ug/intro.rst | 4 +-
>> examples/{ioat => dma}/Makefile | 4 +-
>> examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 586 +++++++++---------
>> examples/{ioat => dma}/meson.build | 10 +-
>> examples/meson.build | 2 +-
>> 8 files changed, 380 insertions(+), 349 deletions(-)
>> rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (73%)
>> rename examples/{ioat => dma}/Makefile (97%)
>> rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (63%)
>> rename examples/{ioat => dma}/meson.build (63%)
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/6] port ioatfwd app to dmadev
2021-09-17 16:41 8% ` [dpdk-dev] [PATCH v2 " Kevin Laatz
@ 2021-09-23 13:53 0% ` fengchengwen
2021-09-23 14:00 0% ` Kevin Laatz
0 siblings, 1 reply; 53+ results
From: fengchengwen @ 2021-09-23 13:53 UTC (permalink / raw)
To: Kevin Laatz, dev; +Cc: bruce.richardson, conor.walsh
Hi Kevin,
Can you add the following functions?
1. Add dump dmadev which trigger by signal, like:
...
static void
dma_dump(void)
{
uint32_t i, j;
if (copy_mode != COPY_MODE_DMA_NUM)
return;
for (i = 0; i < cfg.nb_ports; i++) {
for (j = 0; j < cfg.ports[i].nb_queues; j++)
rte_dma_dump(cfg.ports[i].dmadev_ids[j], stdout);
}
}
...
static void
signal_handler(int signum)
{
if (signum == SIGINT || signum == SIGTERM) {
printf("\n\nSignal %d received, preparing to exit...\n",
signum);
force_quit = true;
} else if (signum == SIGUSR1) {
dma_dump();
}
}
...
signal(SIGUSR1, signal_handler);
2. Controls the output frequency of print_stats. currently fix 1s, hope could control by parameters.
Thanks.
On 2021/9/18 0:41, Kevin Laatz wrote:
> This patchset first adds some additional command line options to the
> existing ioatfwd application to enhance usability.
>
> The last 3 patches of this set then port the ioatfwd application to use the
> dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
> all variables etc are renamed to be more appropriate for using with the
> DMAdev library. Lastly, the application itself is renamed to "dmafwd".
>
> Depends-on: series-18960 ("support dmadev")
>
> Kevin Laatz (3):
> examples/ioat: port application to dmadev APIs
> examples/ioat: update naming to match change to dmadev
> examples/ioat: rename application to dmafwd
>
> Konstantin Ananyev (3):
> examples/ioat: always use same lcore for both DMA requests enqueue and
> dequeue
> examples/ioat: add cmd-line option to control DMA batch size
> examples/ioat: add cmd line option to control max frame size
>
> MAINTAINERS | 7 +-
> .../sample_app_ug/{ioat.rst => dma.rst} | 114 ++--
> doc/guides/sample_app_ug/index.rst | 2 +-
> doc/guides/sample_app_ug/intro.rst | 4 +-
> examples/{ioat => dma}/Makefile | 4 +-
> examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 586 +++++++++---------
> examples/{ioat => dma}/meson.build | 10 +-
> examples/meson.build | 2 +-
> 8 files changed, 380 insertions(+), 349 deletions(-)
> rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (73%)
> rename examples/{ioat => dma}/Makefile (97%)
> rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (63%)
> rename examples/{ioat => dma}/meson.build (63%)
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 0/6] port ioatfwd app to dmadev
2021-09-10 17:27 8% [dpdk-dev] [PATCH 0/6] port ioatfwd app to dmadev Kevin Laatz
@ 2021-09-17 16:41 8% ` Kevin Laatz
2021-09-23 13:53 0% ` fengchengwen
2021-09-28 16:29 8% ` [dpdk-dev] [PATCH v3 0/8] " Kevin Laatz
` (2 subsequent siblings)
3 siblings, 1 reply; 53+ results
From: Kevin Laatz @ 2021-09-17 16:41 UTC (permalink / raw)
To: dev; +Cc: bruce.richardson, fengchengwen, conor.walsh, Kevin Laatz
This patchset first adds some additional command line options to the
existing ioatfwd application to enhance usability.
The last 3 patches of this set then port the ioatfwd application to use the
dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
all variables etc are renamed to be more appropriate for using with the
DMAdev library. Lastly, the application itself is renamed to "dmafwd".
Depends-on: series-18960 ("support dmadev")
Kevin Laatz (3):
examples/ioat: port application to dmadev APIs
examples/ioat: update naming to match change to dmadev
examples/ioat: rename application to dmafwd
Konstantin Ananyev (3):
examples/ioat: always use same lcore for both DMA requests enqueue and
dequeue
examples/ioat: add cmd-line option to control DMA batch size
examples/ioat: add cmd line option to control max frame size
MAINTAINERS | 7 +-
.../sample_app_ug/{ioat.rst => dma.rst} | 114 ++--
doc/guides/sample_app_ug/index.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 4 +-
examples/{ioat => dma}/Makefile | 4 +-
examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 586 +++++++++---------
examples/{ioat => dma}/meson.build | 10 +-
examples/meson.build | 2 +-
8 files changed, 380 insertions(+), 349 deletions(-)
rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (73%)
rename examples/{ioat => dma}/Makefile (97%)
rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (63%)
rename examples/{ioat => dma}/meson.build (63%)
--
2.30.2
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH 0/6] port ioatfwd app to dmadev
@ 2021-09-10 17:27 8% Kevin Laatz
2021-09-17 16:41 8% ` [dpdk-dev] [PATCH v2 " Kevin Laatz
` (3 more replies)
0 siblings, 4 replies; 53+ results
From: Kevin Laatz @ 2021-09-10 17:27 UTC (permalink / raw)
To: dev; +Cc: bruce.richardson, fengchengwen, conor.walsh, Kevin Laatz
This patchset first adds some additional command line options to the
existing ioatfwd application to enhance usability.
The last 3 patches of this set then port the ioatfwd application to use the
dmadev library APIs instead of the IOAT rawdev APIs. Following the port,
all variables etc are renamed to be more appropriate for using with the
DMAdev library. Lastly, the application itself is renamed to "dmafwd".
Depends-on: series-18738 ("support dmadev")
Kevin Laatz (3):
examples/ioat: port application to dmadev APIs
examples/ioat: update naming to match change to dmadev
examples/ioat: rename application to dmafwd
Konstantin Ananyev (3):
examples/ioat: always use same lcore for both DMA requests enqueue and
dequeue
examples/ioat: add cmd-line option to control DMA batch size
examples/ioat: add cmd line option to control max frame size
.../sample_app_ug/{ioat.rst => dma.rst} | 114 ++--
doc/guides/sample_app_ug/index.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 4 +-
examples/{ioat => dma}/Makefile | 4 +-
examples/{ioat/ioatfwd.c => dma/dmafwd.c} | 597 +++++++++---------
examples/{ioat => dma}/meson.build | 10 +-
examples/meson.build | 2 +-
7 files changed, 381 insertions(+), 352 deletions(-)
rename doc/guides/sample_app_ug/{ioat.rst => dma.rst} (73%)
rename examples/{ioat => dma}/Makefile (97%)
rename examples/{ioat/ioatfwd.c => dma/dmafwd.c} (62%)
rename examples/{ioat => dma}/meson.build (63%)
--
2.30.2
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
2021-09-02 13:12 0% ` Jerin Jacob
@ 2021-09-06 16:11 0% ` Elena Agostini
0 siblings, 0 replies; 53+ results
From: Elena Agostini @ 2021-09-06 16:11 UTC (permalink / raw)
To: Jerin Jacob
Cc: Wang, Haiyue, NBU-Contact-Thomas Monjalon, Jerin Jacob, dpdk-dev,
Stephen Hemminger, David Marchand, Andrew Rybchenko,
Honnappa Nagarahalli, Yigit, Ferruh, techboard
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, September 2, 2021 3:12 PM
> To: Elena Agostini <eagostini@nvidia.com>
> Cc: Wang, Haiyue <haiyue.wang@intel.com>; NBU-Contact-Thomas
> Monjalon <thomas@monjalon.net>; Jerin Jacob <jerinj@marvell.com>;
> dpdk-dev <dev@dpdk.org>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand
> <david.marchand@redhat.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Honnappa Nagarahalli
> <honnappa.nagarahalli@arm.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing
> library
>
>
> On Wed, Sep 1, 2021 at 9:05 PM Elena Agostini <eagostini@nvidia.com>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wang, Haiyue <haiyue.wang@intel.com>
> > > Sent: Sunday, August 29, 2021 7:33 AM
> > > To: Jerin Jacob <jerinjacobk@gmail.com>; NBU-Contact-Thomas
> Monjalon
> > > <thomas@monjalon.net>
> > > Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>;
> > > Stephen Hemminger <stephen@networkplumber.org>; David Marchand
> > > <david.marchand@redhat.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; Honnappa Nagarahalli
> > > <honnappa.nagarahalli@arm.com>; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; techboard@dpdk.org; Elena Agostini
> > > <eagostini@nvidia.com>
> > > Subject: RE: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing
> > > library
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Friday, August 27, 2021 20:19
> > > > To: Thomas Monjalon <thomas@monjalon.net>
> > > > Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>;
> > > > Stephen
> > > Hemminger
> > > > <stephen@networkplumber.org>; David Marchand
> > > <david.marchand@redhat.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; Wang, Haiyue
> > > > <haiyue.wang@intel.com>;
> > > Honnappa Nagarahalli
> > > > <honnappa.nagarahalli@arm.com>; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>;
> > > techboard@dpdk.org; Elena
> > > > Agostini <eagostini@nvidia.com>
> > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing
> > > > library
> > > >
> > > > On Fri, Aug 27, 2021 at 3:14 PM Thomas Monjalon
> > > > <thomas@monjalon.net>
> > > wrote:
> > > > >
> > > > > 31/07/2021 15:42, Jerin Jacob:
> > > > > > On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon
> > > <thomas@monjalon.net> wrote:
> > > > > > > 31/07/2021 09:06, Jerin Jacob:
> > > > > > > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon
> > > <thomas@monjalon.net> wrote:
> > > > > > > > > From: Elena Agostini <eagostini@nvidia.com>
> > > > > > > > >
> > > > > > > > > In heterogeneous computing system, processing is not
> > > > > > > > > only in the
> > > CPU.
> > > > > > > > > Some tasks can be delegated to devices working in parallel.
> > > > > > > > >
> > > > > > > > > The goal of this new library is to enhance the
> > > > > > > > > collaboration between DPDK, that's primarily a CPU
> > > > > > > > > framework, and other type of devices
> > > like GPUs.
> > > > > > > > >
> > > > > > > > > When mixing network activity with task processing on a
> > > > > > > > > non-CPU
> > > device,
> > > > > > > > > there may be the need to put in communication the CPU
> > > > > > > > > with the
> > > device
> > > > > > > > > in order to manage the memory, synchronize operations,
> > > > > > > > > exchange
> > > info, etc..
> > > > > > > > >
> > > > > > > > > This library provides a number of new features:
> > > > > > > > > - Interoperability with device specific library with
> > > > > > > > > generic handlers
> > > > > > > > > - Possibility to allocate and free memory on the device
> > > > > > > > > - Possibility to allocate and free memory on the CPU but
> > > > > > > > > visible from
> > > the device
> > > > > > > > > - Communication functions to enhance the dialog between
> > > > > > > > > the CPU
> > > and the device
> > > > > > > > >
> > > > > > > > > The infrastructure is prepared to welcome drivers in
> > > > > > > > > drivers/hc/ as the upcoming NVIDIA one, implementing the
> hcdev API.
> > > > > > > > >
> > > > > > > > > Some parts are not complete:
> > > > > > > > > - locks
> > > > > > > > > - memory allocation table
> > > > > > > > > - memory freeing
> > > > > > > > > - guide documentation
> > > > > > > > > - integration in devtools/check-doc-vs-code.sh
> > > > > > > > > - unit tests
> > > > > > > > > - integration in testpmd to enable Rx/Tx to/from GPU
> memory.
> > > > > > > >
> > > > > > > > Since the above line is the crux of the following text, I
> > > > > > > > will start from this point.
> > > > > > > >
> > > > > > > > + Techboard
> > > > > > > >
> > > > > > > > I can give my honest feedback on this.
> > > > > > > >
> > > > > > > > I can map similar stuff in Marvell HW, where we do
> > > > > > > > machine learning as compute offload on a different class
> > > > > > > > of CPU.
> > > > > > > >
> > > > > > > > In terms of RFC patch features
> > > > > > > >
> > > > > > > > 1) memory API - Use cases are aligned
> > > > > > > > 2) communication flag and communication list Our structure
> > > > > > > > is completely different and we are using HW ring kind of
> > > > > > > > interface to post the job to compute interface and the job
> > > > > > > > completion result happens through the event device.
> > > > > > > > Kind of similar to the DMA API that has been discussed on
> > > > > > > > the mailing
> > > list.
> > > > > > >
> > > > > > > Interesting.
> > > > > >
> > > > > > It is hard to generalize the communication mechanism.
> > > > > > Is other GPU vendors have a similar communication mechanism?
> > > > > > AMD,
> > > Intel ??
> > > > >
> > > > > I don't know who to ask in AMD & Intel. Any ideas?
> > > >
> > > > Good question.
> > > >
> > > > At least in Marvell HW, the communication flag and communication
> > > > list is our structure is completely different and we are using HW
> > > > ring kind of interface to post the job to compute interface and
> > > > the job completion result happens through the event device.
> > > > kind of similar to the DMA API that has been discussed on the mailing
> list.
> >
> > Please correct me if I'm wrong but what you are describing is a
> > specific way to submit work on the device. Communication flag/list
> > here is a direct data communication between the CPU and some kind of
> > workload (e.g. GPU kernel) that's already running on the device.
>
> Exactly. What I meant is Communication flag/list is not generic enough to
> express and generic compute device. If all GPU works in this way, we could
> make the library name as GPU specific and add GPU specific communication
> mechanism.
I'm in favor of reverting the name of the library with a more specific gpudev name
instead of hcdev. This library (both memory allocations and fancy features like
communication lists) can be tested on various GPUs but I'm not sure about
other type of devices.
Again, as initial step, I would not complicate things
Let's have a GPU oriented library for now.
>
>
> >
> > The rationale here is that:
> > - some work has been already submitted on the device and it's running
> > - CPU needs a real-time direct interaction through memory with the
> > device
> > - the workload on the device needs some info from the CPU it can't get
> > at submission time
> >
> > This is good enough for NVIDIA and AMD GPU.
> > Need to double check for Intel GPU.
> >
> > > >
> > > > >
> > > > > > > > Now the bigger question is why need to Tx and then Rx
> > > > > > > > something to compute the device Isn't ot offload
> > > > > > > > something? If so, why not add the those offload in
> > > > > > > > respective subsystem to improve the subsystem(ethdev,
> > > > > > > > cryptiodev etc) features set to adapt new features or
> > > > > > > > introduce new subsystem (like ML, Inline Baseband
> > > > > > > > processing) so that it will be an opportunity to implement
> > > > > > > > the same in HW or compute device. For example, if we take
> > > > > > > > this path, ML offloading will be application code like
> > > > > > > > testpmd, which deals with "specific" device commands(aka
> > > > > > > > glorified rawdev) to deal with specific computing device
> > > > > > > > offload "COMMANDS"
> > > > > > > > (The commands will be specific to offload device, the
> > > > > > > > same code wont run on other compute device)
> > > > > > >
> > > > > > > Having specific features API is convenient for compatibility
> > > > > > > between devices, yes, for the set of defined features.
> > > > > > > Our approach is to start with a flexible API that the
> > > > > > > application can use to implement any processing because with
> > > > > > > GPU programming, there is no restriction on what can be
> achieved.
> > > > > > > This approach does not contradict what you propose, it does
> > > > > > > not prevent extending existing classes.
> > > > > >
> > > > > > It does prevent extending the existing classes as no one is
> > > > > > going to extent it there is the path of not doing do.
> > > > >
> > > > > I disagree. Specific API is more convenient for some tasks, so
> > > > > there is an incentive to define or extend specific device class APIs.
> > > > > But it should not forbid doing custom processing.
> > > >
> > > > This is the same as the raw device is in DPDK where the device
> > > > personality is not defined.
> > > >
> > > > Even if define another API and if the personality is not defined,
> > > > it comes similar to the raw device as similar to rawdev enqueue
> > > > and dequeue.
> > > >
> > > > To summarize,
> > > >
> > > > 1) My _personal_ preference is to have specific subsystems to
> > > > improve the DPDK instead of the raw device kind of path.
> > >
> > > Something like rte_memdev to focus on device (GPU) memory
> management ?
> > >
> > > The new DPDK auxiliary bus maybe make life easier to solve the
> > > complex heterogeneous computing library. ;-)
> >
> > To get a concrete idea about what's the best and most comprehensive
> > approach we should start with something that's flexible and simple
> enough.
> >
> > A dedicated library it's a good starting point: easy to implement and
> > embed in DPDK applications, isolated from other components and users
> can play with it learning from the code.
> > As a second step we can think to embed the functionality in some other
> > way within DPDK (e.g. split memory management and communication
> features).
> >
> > >
> > > > 2) If the device personality is not defined, use rawdev
> > > > 3) All computing devices do not use "communication flag" and
> > > > "communication list"
> > > > kind of structure. If are targeting a generic computing device
> > > > then that is not a portable scheme.
> > > > For GPU abstraction if "communication flag" and "communication
> list"
> > > > is the right kind of mechanism
> > > > then we can have a separate library for GPU communication specific
> > > > to GPU <-
> > > >
> > > > DPDK communication needs and explicit for GPU.
> > > >
> > > > I think generic DPDK applications like testpmd should not pollute
> > > > with device-specific functions. Like, call device-specific
> > > > messages from the application which makes the application runs
> > > > only one device. I don't have a strong opinion(expect
> > > > standardizing "communication flag" and "communication list" as
> > > > generic computing device communication mechanism) of others think
> > > > it is OK to do that way in DPDK.
> >
> > I'd like to introduce (with a dedicated option) the memory API in
> > testpmd to provide an example of how to TX/RX packets using device
> memory.
>
> Not sure without embedding sideband communication mechanism how it
> can notify to GPU and back to CPU. If you could share the example API
> sequence that helps to us understand the level of coupling with testpmd.
>
There is no need of communication mechanism here.
Assuming there is not workload to process network packets (to not complicate
things), the steps are:
1) Create a DPDK mempool with device external memory using the hcdev (or gpudev) library
2) Use that mempool to tx/rx/fwd packets
As an example, you look at my l2fwd-nv application here: https://github.com/NVIDIA/l2fwd-nv
>
> >
> > I agree to not embed communication flag/list features.
> >
> > > >
> > > > >
> > > > > > If an application can run only on a specific device, it is
> > > > > > similar to a raw device, where the device definition is not
> > > > > > defined. (i.e JOB metadata is not defined
> > > and
> > > > > > it is specific to the device).
> > > > > >
> > > > > > > > Just my _personal_ preference is to have specific
> > > > > > > > subsystems to improve the DPDK instead of raw device kind
> > > > > > > > of path. If we decide another path as a community it is
> > > > > > > > _fine_ too(as a _project manager_ point of view it will be
> > > > > > > > an easy path to dump SDK stuff to DPDK without introducing
> > > > > > > > the pain of the subsystem nor improving the DPDK).
> > > > > > >
> > > > > > > Adding a new class API is also improving DPDK.
> > > > > >
> > > > > > But the class is similar as raw dev class. The reason I say,
> > > > > > Job submission and response is can be abstracted as
> queue/dequeue APIs.
> > > > > > Taks/Job metadata is specific to compute devices (and it can
> > > > > > not be generalized).
> > > > > > If we generalize it makes sense to have a new class that does
> > > > > > "specific function".
> > > > >
> > > > > Computing device programming is already generalized with
> > > > > languages like
> > > OpenCL.
> > > > > We should not try to reinvent the same.
> > > > > We are just trying to properly integrate the concept in DPDK and
> > > > > allow building on top of it.
> >
> > Agree.
> >
> > > >
> > > > See above.
> > > >
> > > > >
> > > > >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
2021-09-01 15:35 0% ` Elena Agostini
@ 2021-09-02 13:12 0% ` Jerin Jacob
2021-09-06 16:11 0% ` Elena Agostini
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2021-09-02 13:12 UTC (permalink / raw)
To: Elena Agostini
Cc: Wang, Haiyue, NBU-Contact-Thomas Monjalon, Jerin Jacob, dpdk-dev,
Stephen Hemminger, David Marchand, Andrew Rybchenko,
Honnappa Nagarahalli, Yigit, Ferruh, techboard
On Wed, Sep 1, 2021 at 9:05 PM Elena Agostini <eagostini@nvidia.com> wrote:
>
>
> > -----Original Message-----
> > From: Wang, Haiyue <haiyue.wang@intel.com>
> > Sent: Sunday, August 29, 2021 7:33 AM
> > To: Jerin Jacob <jerinjacobk@gmail.com>; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>
> > Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>; Stephen
> > Hemminger <stephen@networkplumber.org>; David Marchand
> > <david.marchand@redhat.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; Honnappa Nagarahalli
> > <honnappa.nagarahalli@arm.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > techboard@dpdk.org; Elena Agostini <eagostini@nvidia.com>
> > Subject: RE: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Friday, August 27, 2021 20:19
> > > To: Thomas Monjalon <thomas@monjalon.net>
> > > Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>; Stephen
> > Hemminger
> > > <stephen@networkplumber.org>; David Marchand
> > <david.marchand@redhat.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; Wang, Haiyue <haiyue.wang@intel.com>;
> > Honnappa Nagarahalli
> > > <honnappa.nagarahalli@arm.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > techboard@dpdk.org; Elena
> > > Agostini <eagostini@nvidia.com>
> > > Subject: Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
> > >
> > > On Fri, Aug 27, 2021 at 3:14 PM Thomas Monjalon <thomas@monjalon.net>
> > wrote:
> > > >
> > > > 31/07/2021 15:42, Jerin Jacob:
> > > > > On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon
> > <thomas@monjalon.net> wrote:
> > > > > > 31/07/2021 09:06, Jerin Jacob:
> > > > > > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon
> > <thomas@monjalon.net> wrote:
> > > > > > > > From: Elena Agostini <eagostini@nvidia.com>
> > > > > > > >
> > > > > > > > In heterogeneous computing system, processing is not only in the
> > CPU.
> > > > > > > > Some tasks can be delegated to devices working in parallel.
> > > > > > > >
> > > > > > > > The goal of this new library is to enhance the collaboration between
> > > > > > > > DPDK, that's primarily a CPU framework, and other type of devices
> > like GPUs.
> > > > > > > >
> > > > > > > > When mixing network activity with task processing on a non-CPU
> > device,
> > > > > > > > there may be the need to put in communication the CPU with the
> > device
> > > > > > > > in order to manage the memory, synchronize operations, exchange
> > info, etc..
> > > > > > > >
> > > > > > > > This library provides a number of new features:
> > > > > > > > - Interoperability with device specific library with generic handlers
> > > > > > > > - Possibility to allocate and free memory on the device
> > > > > > > > - Possibility to allocate and free memory on the CPU but visible from
> > the device
> > > > > > > > - Communication functions to enhance the dialog between the CPU
> > and the device
> > > > > > > >
> > > > > > > > The infrastructure is prepared to welcome drivers in drivers/hc/
> > > > > > > > as the upcoming NVIDIA one, implementing the hcdev API.
> > > > > > > >
> > > > > > > > Some parts are not complete:
> > > > > > > > - locks
> > > > > > > > - memory allocation table
> > > > > > > > - memory freeing
> > > > > > > > - guide documentation
> > > > > > > > - integration in devtools/check-doc-vs-code.sh
> > > > > > > > - unit tests
> > > > > > > > - integration in testpmd to enable Rx/Tx to/from GPU memory.
> > > > > > >
> > > > > > > Since the above line is the crux of the following text, I will start
> > > > > > > from this point.
> > > > > > >
> > > > > > > + Techboard
> > > > > > >
> > > > > > > I can give my honest feedback on this.
> > > > > > >
> > > > > > > I can map similar stuff in Marvell HW, where we do machine learning
> > > > > > > as compute offload
> > > > > > > on a different class of CPU.
> > > > > > >
> > > > > > > In terms of RFC patch features
> > > > > > >
> > > > > > > 1) memory API - Use cases are aligned
> > > > > > > 2) communication flag and communication list
> > > > > > > Our structure is completely different and we are using HW ring kind of
> > > > > > > interface to post the job to compute interface and
> > > > > > > the job completion result happens through the event device.
> > > > > > > Kind of similar to the DMA API that has been discussed on the mailing
> > list.
> > > > > >
> > > > > > Interesting.
> > > > >
> > > > > It is hard to generalize the communication mechanism.
> > > > > Is other GPU vendors have a similar communication mechanism? AMD,
> > Intel ??
> > > >
> > > > I don't know who to ask in AMD & Intel. Any ideas?
> > >
> > > Good question.
> > >
> > > At least in Marvell HW, the communication flag and communication list is
> > > our structure is completely different and we are using HW ring kind of
> > > interface to post the job to compute interface and
> > > the job completion result happens through the event device.
> > > kind of similar to the DMA API that has been discussed on the mailing list.
>
> Please correct me if I'm wrong but what you are describing is a specific way
> to submit work on the device. Communication flag/list here is a direct data
> communication between the CPU and some kind of workload (e.g. GPU kernel)
> that's already running on the device.
Exactly. What I meant is Communication flag/list is not generic enough
to express
and generic compute device. If all GPU works in this way, we could
make the library
name as GPU specific and add GPU specific communication mechanism.
>
> The rationale here is that:
> - some work has been already submitted on the device and it's running
> - CPU needs a real-time direct interaction through memory with the device
> - the workload on the device needs some info from the CPU it can't get at submission time
>
> This is good enough for NVIDIA and AMD GPU.
> Need to double check for Intel GPU.
>
> > >
> > > >
> > > > > > > Now the bigger question is why need to Tx and then Rx something to
> > > > > > > compute the device
> > > > > > > Isn't ot offload something? If so, why not add the those offload in
> > > > > > > respective subsystem
> > > > > > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt
> > > > > > > new features or
> > > > > > > introduce new subsystem (like ML, Inline Baseband processing) so that
> > > > > > > it will be an opportunity to
> > > > > > > implement the same in HW or compute device. For example, if we take
> > > > > > > this path, ML offloading will
> > > > > > > be application code like testpmd, which deals with "specific" device
> > > > > > > commands(aka glorified rawdev)
> > > > > > > to deal with specific computing device offload "COMMANDS"
> > > > > > > (The commands will be specific to offload device, the same code wont
> > > > > > > run on other compute device)
> > > > > >
> > > > > > Having specific features API is convenient for compatibility
> > > > > > between devices, yes, for the set of defined features.
> > > > > > Our approach is to start with a flexible API that the application
> > > > > > can use to implement any processing because with GPU programming,
> > > > > > there is no restriction on what can be achieved.
> > > > > > This approach does not contradict what you propose,
> > > > > > it does not prevent extending existing classes.
> > > > >
> > > > > It does prevent extending the existing classes as no one is going to
> > > > > extent it there is the path of not doing do.
> > > >
> > > > I disagree. Specific API is more convenient for some tasks,
> > > > so there is an incentive to define or extend specific device class APIs.
> > > > But it should not forbid doing custom processing.
> > >
> > > This is the same as the raw device is in DPDK where the device
> > > personality is not defined.
> > >
> > > Even if define another API and if the personality is not defined,
> > > it comes similar to the raw device as similar
> > > to rawdev enqueue and dequeue.
> > >
> > > To summarize,
> > >
> > > 1) My _personal_ preference is to have specific subsystems
> > > to improve the DPDK instead of the raw device kind of path.
> >
> > Something like rte_memdev to focus on device (GPU) memory management ?
> >
> > The new DPDK auxiliary bus maybe make life easier to solve the complex
> > heterogeneous computing library. ;-)
>
> To get a concrete idea about what's the best and most comprehensive
> approach we should start with something that's flexible and simple enough.
>
> A dedicated library it's a good starting point: easy to implement and embed in DPDK applications,
> isolated from other components and users can play with it learning from the code.
> As a second step we can think to embed the functionality in some other way
> within DPDK (e.g. split memory management and communication features).
>
> >
> > > 2) If the device personality is not defined, use rawdev
> > > 3) All computing devices do not use "communication flag" and
> > > "communication list"
> > > kind of structure. If are targeting a generic computing device then
> > > that is not a portable scheme.
> > > For GPU abstraction if "communication flag" and "communication list"
> > > is the right kind of mechanism
> > > then we can have a separate library for GPU communication specific to GPU <-
> > >
> > > DPDK communication needs and explicit for GPU.
> > >
> > > I think generic DPDK applications like testpmd should not
> > > pollute with device-specific functions. Like, call device-specific
> > > messages from the application
> > > which makes the application runs only one device. I don't have a
> > > strong opinion(expect
> > > standardizing "communication flag" and "communication list" as
> > > generic computing device
> > > communication mechanism) of others think it is OK to do that way in DPDK.
>
> I'd like to introduce (with a dedicated option) the memory API in testpmd to
> provide an example of how to TX/RX packets using device memory.
Not sure without embedding sideband communication mechanism how it can notify to
GPU and back to CPU. If you could share the example API sequence that helps to
us understand the level of coupling with testpmd.
>
> I agree to not embed communication flag/list features.
>
> > >
> > > >
> > > > > If an application can run only on a specific device, it is similar to
> > > > > a raw device,
> > > > > where the device definition is not defined. (i.e JOB metadata is not defined
> > and
> > > > > it is specific to the device).
> > > > >
> > > > > > > Just my _personal_ preference is to have specific subsystems to
> > > > > > > improve the DPDK instead of raw device kind of
> > > > > > > path. If we decide another path as a community it is _fine_ too(as a
> > > > > > > _project manager_ point of view it will be an easy path to dump SDK
> > > > > > > stuff to DPDK without introducing the pain of the subsystem nor
> > > > > > > improving the DPDK).
> > > > > >
> > > > > > Adding a new class API is also improving DPDK.
> > > > >
> > > > > But the class is similar as raw dev class. The reason I say,
> > > > > Job submission and response is can be abstracted as queue/dequeue APIs.
> > > > > Taks/Job metadata is specific to compute devices (and it can not be
> > > > > generalized).
> > > > > If we generalize it makes sense to have a new class that does
> > > > > "specific function".
> > > >
> > > > Computing device programming is already generalized with languages like
> > OpenCL.
> > > > We should not try to reinvent the same.
> > > > We are just trying to properly integrate the concept in DPDK
> > > > and allow building on top of it.
>
> Agree.
>
> > >
> > > See above.
> > >
> > > >
> > > >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
2021-08-29 5:32 0% ` Wang, Haiyue
@ 2021-09-01 15:35 0% ` Elena Agostini
2021-09-02 13:12 0% ` Jerin Jacob
0 siblings, 1 reply; 53+ results
From: Elena Agostini @ 2021-09-01 15:35 UTC (permalink / raw)
To: Wang, Haiyue, Jerin Jacob, NBU-Contact-Thomas Monjalon
Cc: Jerin Jacob, dpdk-dev, Stephen Hemminger, David Marchand,
Andrew Rybchenko, Honnappa Nagarahalli, Yigit, Ferruh, techboard
> -----Original Message-----
> From: Wang, Haiyue <haiyue.wang@intel.com>
> Sent: Sunday, August 29, 2021 7:33 AM
> To: Jerin Jacob <jerinjacobk@gmail.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>
> Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>; Stephen
> Hemminger <stephen@networkplumber.org>; David Marchand
> <david.marchand@redhat.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Honnappa Nagarahalli
> <honnappa.nagarahalli@arm.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> techboard@dpdk.org; Elena Agostini <eagostini@nvidia.com>
> Subject: RE: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Friday, August 27, 2021 20:19
> > To: Thomas Monjalon <thomas@monjalon.net>
> > Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>; Stephen
> Hemminger
> > <stephen@networkplumber.org>; David Marchand
> <david.marchand@redhat.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; Wang, Haiyue <haiyue.wang@intel.com>;
> Honnappa Nagarahalli
> > <honnappa.nagarahalli@arm.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> techboard@dpdk.org; Elena
> > Agostini <eagostini@nvidia.com>
> > Subject: Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
> >
> > On Fri, Aug 27, 2021 at 3:14 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> > >
> > > 31/07/2021 15:42, Jerin Jacob:
> > > > On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> > > > > 31/07/2021 09:06, Jerin Jacob:
> > > > > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> > > > > > > From: Elena Agostini <eagostini@nvidia.com>
> > > > > > >
> > > > > > > In heterogeneous computing system, processing is not only in the
> CPU.
> > > > > > > Some tasks can be delegated to devices working in parallel.
> > > > > > >
> > > > > > > The goal of this new library is to enhance the collaboration between
> > > > > > > DPDK, that's primarily a CPU framework, and other type of devices
> like GPUs.
> > > > > > >
> > > > > > > When mixing network activity with task processing on a non-CPU
> device,
> > > > > > > there may be the need to put in communication the CPU with the
> device
> > > > > > > in order to manage the memory, synchronize operations, exchange
> info, etc..
> > > > > > >
> > > > > > > This library provides a number of new features:
> > > > > > > - Interoperability with device specific library with generic handlers
> > > > > > > - Possibility to allocate and free memory on the device
> > > > > > > - Possibility to allocate and free memory on the CPU but visible from
> the device
> > > > > > > - Communication functions to enhance the dialog between the CPU
> and the device
> > > > > > >
> > > > > > > The infrastructure is prepared to welcome drivers in drivers/hc/
> > > > > > > as the upcoming NVIDIA one, implementing the hcdev API.
> > > > > > >
> > > > > > > Some parts are not complete:
> > > > > > > - locks
> > > > > > > - memory allocation table
> > > > > > > - memory freeing
> > > > > > > - guide documentation
> > > > > > > - integration in devtools/check-doc-vs-code.sh
> > > > > > > - unit tests
> > > > > > > - integration in testpmd to enable Rx/Tx to/from GPU memory.
> > > > > >
> > > > > > Since the above line is the crux of the following text, I will start
> > > > > > from this point.
> > > > > >
> > > > > > + Techboard
> > > > > >
> > > > > > I can give my honest feedback on this.
> > > > > >
> > > > > > I can map similar stuff in Marvell HW, where we do machine learning
> > > > > > as compute offload
> > > > > > on a different class of CPU.
> > > > > >
> > > > > > In terms of RFC patch features
> > > > > >
> > > > > > 1) memory API - Use cases are aligned
> > > > > > 2) communication flag and communication list
> > > > > > Our structure is completely different and we are using HW ring kind of
> > > > > > interface to post the job to compute interface and
> > > > > > the job completion result happens through the event device.
> > > > > > Kind of similar to the DMA API that has been discussed on the mailing
> list.
> > > > >
> > > > > Interesting.
> > > >
> > > > It is hard to generalize the communication mechanism.
> > > > Is other GPU vendors have a similar communication mechanism? AMD,
> Intel ??
> > >
> > > I don't know who to ask in AMD & Intel. Any ideas?
> >
> > Good question.
> >
> > At least in Marvell HW, the communication flag and communication list is
> > our structure is completely different and we are using HW ring kind of
> > interface to post the job to compute interface and
> > the job completion result happens through the event device.
> > kind of similar to the DMA API that has been discussed on the mailing list.
Please correct me if I'm wrong but what you are describing is a specific way
to submit work on the device. Communication flag/list here is a direct data
communication between the CPU and some kind of workload (e.g. GPU kernel)
that's already running on the device.
The rationale here is that:
- some work has been already submitted on the device and it's running
- CPU needs a real-time direct interaction through memory with the device
- the workload on the device needs some info from the CPU it can't get at submission time
This is good enough for NVIDIA and AMD GPU.
Need to double check for Intel GPU.
> >
> > >
> > > > > > Now the bigger question is why need to Tx and then Rx something to
> > > > > > compute the device
> > > > > > Isn't ot offload something? If so, why not add the those offload in
> > > > > > respective subsystem
> > > > > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt
> > > > > > new features or
> > > > > > introduce new subsystem (like ML, Inline Baseband processing) so that
> > > > > > it will be an opportunity to
> > > > > > implement the same in HW or compute device. For example, if we take
> > > > > > this path, ML offloading will
> > > > > > be application code like testpmd, which deals with "specific" device
> > > > > > commands(aka glorified rawdev)
> > > > > > to deal with specific computing device offload "COMMANDS"
> > > > > > (The commands will be specific to offload device, the same code wont
> > > > > > run on other compute device)
> > > > >
> > > > > Having specific features API is convenient for compatibility
> > > > > between devices, yes, for the set of defined features.
> > > > > Our approach is to start with a flexible API that the application
> > > > > can use to implement any processing because with GPU programming,
> > > > > there is no restriction on what can be achieved.
> > > > > This approach does not contradict what you propose,
> > > > > it does not prevent extending existing classes.
> > > >
> > > > It does prevent extending the existing classes as no one is going to
> > > > extent it there is the path of not doing do.
> > >
> > > I disagree. Specific API is more convenient for some tasks,
> > > so there is an incentive to define or extend specific device class APIs.
> > > But it should not forbid doing custom processing.
> >
> > This is the same as the raw device is in DPDK where the device
> > personality is not defined.
> >
> > Even if define another API and if the personality is not defined,
> > it comes similar to the raw device as similar
> > to rawdev enqueue and dequeue.
> >
> > To summarize,
> >
> > 1) My _personal_ preference is to have specific subsystems
> > to improve the DPDK instead of the raw device kind of path.
>
> Something like rte_memdev to focus on device (GPU) memory management ?
>
> The new DPDK auxiliary bus maybe make life easier to solve the complex
> heterogeneous computing library. ;-)
To get a concrete idea about what's the best and most comprehensive
approach we should start with something that's flexible and simple enough.
A dedicated library it's a good starting point: easy to implement and embed in DPDK applications,
isolated from other components and users can play with it learning from the code.
As a second step we can think to embed the functionality in some other way
within DPDK (e.g. split memory management and communication features).
>
> > 2) If the device personality is not defined, use rawdev
> > 3) All computing devices do not use "communication flag" and
> > "communication list"
> > kind of structure. If are targeting a generic computing device then
> > that is not a portable scheme.
> > For GPU abstraction if "communication flag" and "communication list"
> > is the right kind of mechanism
> > then we can have a separate library for GPU communication specific to GPU <-
> >
> > DPDK communication needs and explicit for GPU.
> >
> > I think generic DPDK applications like testpmd should not
> > pollute with device-specific functions. Like, call device-specific
> > messages from the application
> > which makes the application runs only one device. I don't have a
> > strong opinion(expect
> > standardizing "communication flag" and "communication list" as
> > generic computing device
> > communication mechanism) of others think it is OK to do that way in DPDK.
I'd like to introduce (with a dedicated option) the memory API in testpmd to
provide an example of how to TX/RX packets using device memory.
I agree to not embed communication flag/list features.
> >
> > >
> > > > If an application can run only on a specific device, it is similar to
> > > > a raw device,
> > > > where the device definition is not defined. (i.e JOB metadata is not defined
> and
> > > > it is specific to the device).
> > > >
> > > > > > Just my _personal_ preference is to have specific subsystems to
> > > > > > improve the DPDK instead of raw device kind of
> > > > > > path. If we decide another path as a community it is _fine_ too(as a
> > > > > > _project manager_ point of view it will be an easy path to dump SDK
> > > > > > stuff to DPDK without introducing the pain of the subsystem nor
> > > > > > improving the DPDK).
> > > > >
> > > > > Adding a new class API is also improving DPDK.
> > > >
> > > > But the class is similar as raw dev class. The reason I say,
> > > > Job submission and response is can be abstracted as queue/dequeue APIs.
> > > > Taks/Job metadata is specific to compute devices (and it can not be
> > > > generalized).
> > > > If we generalize it makes sense to have a new class that does
> > > > "specific function".
> > >
> > > Computing device programming is already generalized with languages like
> OpenCL.
> > > We should not try to reinvent the same.
> > > We are just trying to properly integrate the concept in DPDK
> > > and allow building on top of it.
Agree.
> >
> > See above.
> >
> > >
> > >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
2021-08-27 12:19 3% ` Jerin Jacob
@ 2021-08-29 5:32 0% ` Wang, Haiyue
2021-09-01 15:35 0% ` Elena Agostini
0 siblings, 1 reply; 53+ results
From: Wang, Haiyue @ 2021-08-29 5:32 UTC (permalink / raw)
To: Jerin Jacob, Thomas Monjalon
Cc: Jerin Jacob, dpdk-dev, Stephen Hemminger, David Marchand,
Andrew Rybchenko, Honnappa Nagarahalli, Yigit, Ferruh, techboard,
Elena Agostini
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Friday, August 27, 2021 20:19
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob <jerinj@marvell.com>; dpdk-dev <dev@dpdk.org>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Wang, Haiyue <haiyue.wang@intel.com>; Honnappa Nagarahalli
> <honnappa.nagarahalli@arm.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; techboard@dpdk.org; Elena
> Agostini <eagostini@nvidia.com>
> Subject: Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
>
> On Fri, Aug 27, 2021 at 3:14 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 31/07/2021 15:42, Jerin Jacob:
> > > On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > 31/07/2021 09:06, Jerin Jacob:
> > > > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > From: Elena Agostini <eagostini@nvidia.com>
> > > > > >
> > > > > > In heterogeneous computing system, processing is not only in the CPU.
> > > > > > Some tasks can be delegated to devices working in parallel.
> > > > > >
> > > > > > The goal of this new library is to enhance the collaboration between
> > > > > > DPDK, that's primarily a CPU framework, and other type of devices like GPUs.
> > > > > >
> > > > > > When mixing network activity with task processing on a non-CPU device,
> > > > > > there may be the need to put in communication the CPU with the device
> > > > > > in order to manage the memory, synchronize operations, exchange info, etc..
> > > > > >
> > > > > > This library provides a number of new features:
> > > > > > - Interoperability with device specific library with generic handlers
> > > > > > - Possibility to allocate and free memory on the device
> > > > > > - Possibility to allocate and free memory on the CPU but visible from the device
> > > > > > - Communication functions to enhance the dialog between the CPU and the device
> > > > > >
> > > > > > The infrastructure is prepared to welcome drivers in drivers/hc/
> > > > > > as the upcoming NVIDIA one, implementing the hcdev API.
> > > > > >
> > > > > > Some parts are not complete:
> > > > > > - locks
> > > > > > - memory allocation table
> > > > > > - memory freeing
> > > > > > - guide documentation
> > > > > > - integration in devtools/check-doc-vs-code.sh
> > > > > > - unit tests
> > > > > > - integration in testpmd to enable Rx/Tx to/from GPU memory.
> > > > >
> > > > > Since the above line is the crux of the following text, I will start
> > > > > from this point.
> > > > >
> > > > > + Techboard
> > > > >
> > > > > I can give my honest feedback on this.
> > > > >
> > > > > I can map similar stuff in Marvell HW, where we do machine learning
> > > > > as compute offload
> > > > > on a different class of CPU.
> > > > >
> > > > > In terms of RFC patch features
> > > > >
> > > > > 1) memory API - Use cases are aligned
> > > > > 2) communication flag and communication list
> > > > > Our structure is completely different and we are using HW ring kind of
> > > > > interface to post the job to compute interface and
> > > > > the job completion result happens through the event device.
> > > > > Kind of similar to the DMA API that has been discussed on the mailing list.
> > > >
> > > > Interesting.
> > >
> > > It is hard to generalize the communication mechanism.
> > > Is other GPU vendors have a similar communication mechanism? AMD, Intel ??
> >
> > I don't know who to ask in AMD & Intel. Any ideas?
>
> Good question.
>
> At least in Marvell HW, the communication flag and communication list is
> our structure is completely different and we are using HW ring kind of
> interface to post the job to compute interface and
> the job completion result happens through the event device.
> kind of similar to the DMA API that has been discussed on the mailing list.
>
> >
> > > > > Now the bigger question is why need to Tx and then Rx something to
> > > > > compute the device
> > > > > Isn't ot offload something? If so, why not add the those offload in
> > > > > respective subsystem
> > > > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt
> > > > > new features or
> > > > > introduce new subsystem (like ML, Inline Baseband processing) so that
> > > > > it will be an opportunity to
> > > > > implement the same in HW or compute device. For example, if we take
> > > > > this path, ML offloading will
> > > > > be application code like testpmd, which deals with "specific" device
> > > > > commands(aka glorified rawdev)
> > > > > to deal with specific computing device offload "COMMANDS"
> > > > > (The commands will be specific to offload device, the same code wont
> > > > > run on other compute device)
> > > >
> > > > Having specific features API is convenient for compatibility
> > > > between devices, yes, for the set of defined features.
> > > > Our approach is to start with a flexible API that the application
> > > > can use to implement any processing because with GPU programming,
> > > > there is no restriction on what can be achieved.
> > > > This approach does not contradict what you propose,
> > > > it does not prevent extending existing classes.
> > >
> > > It does prevent extending the existing classes as no one is going to
> > > extent it there is the path of not doing do.
> >
> > I disagree. Specific API is more convenient for some tasks,
> > so there is an incentive to define or extend specific device class APIs.
> > But it should not forbid doing custom processing.
>
> This is the same as the raw device is in DPDK where the device
> personality is not defined.
>
> Even if define another API and if the personality is not defined,
> it comes similar to the raw device as similar
> to rawdev enqueue and dequeue.
>
> To summarize,
>
> 1) My _personal_ preference is to have specific subsystems
> to improve the DPDK instead of the raw device kind of path.
Something like rte_memdev to focus on device (GPU) memory management ?
The new DPDK auxiliary bus maybe make life easier to solve the complex
heterogeneous computing library. ;-)
> 2) If the device personality is not defined, use rawdev
> 3) All computing devices do not use "communication flag" and
> "communication list"
> kind of structure. If are targeting a generic computing device then
> that is not a portable scheme.
> For GPU abstraction if "communication flag" and "communication list"
> is the right kind of mechanism
> then we can have a separate library for GPU communication specific to GPU <->
> DPDK communication needs and explicit for GPU.
>
> I think generic DPDK applications like testpmd should not
> pollute with device-specific functions. Like, call device-specific
> messages from the application
> which makes the application runs only one device. I don't have a
> strong opinion(expect
> standardizing "communication flag" and "communication list" as
> generic computing device
> communication mechanism) of others think it is OK to do that way in DPDK.
>
> >
> > > If an application can run only on a specific device, it is similar to
> > > a raw device,
> > > where the device definition is not defined. (i.e JOB metadata is not defined and
> > > it is specific to the device).
> > >
> > > > > Just my _personal_ preference is to have specific subsystems to
> > > > > improve the DPDK instead of raw device kind of
> > > > > path. If we decide another path as a community it is _fine_ too(as a
> > > > > _project manager_ point of view it will be an easy path to dump SDK
> > > > > stuff to DPDK without introducing the pain of the subsystem nor
> > > > > improving the DPDK).
> > > >
> > > > Adding a new class API is also improving DPDK.
> > >
> > > But the class is similar as raw dev class. The reason I say,
> > > Job submission and response is can be abstracted as queue/dequeue APIs.
> > > Taks/Job metadata is specific to compute devices (and it can not be
> > > generalized).
> > > If we generalize it makes sense to have a new class that does
> > > "specific function".
> >
> > Computing device programming is already generalized with languages like OpenCL.
> > We should not try to reinvent the same.
> > We are just trying to properly integrate the concept in DPDK
> > and allow building on top of it.
>
> See above.
>
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
2021-08-27 9:44 2% ` Thomas Monjalon
@ 2021-08-27 12:19 3% ` Jerin Jacob
2021-08-29 5:32 0% ` Wang, Haiyue
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2021-08-27 12:19 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Jerin Jacob, dpdk-dev, Stephen Hemminger, David Marchand,
Andrew Rybchenko, Haiyue Wang, Honnappa Nagarahalli,
Ferruh Yigit, techboard, Elena Agostini
On Fri, Aug 27, 2021 at 3:14 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 31/07/2021 15:42, Jerin Jacob:
> > On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > 31/07/2021 09:06, Jerin Jacob:
> > > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > From: Elena Agostini <eagostini@nvidia.com>
> > > > >
> > > > > In heterogeneous computing system, processing is not only in the CPU.
> > > > > Some tasks can be delegated to devices working in parallel.
> > > > >
> > > > > The goal of this new library is to enhance the collaboration between
> > > > > DPDK, that's primarily a CPU framework, and other type of devices like GPUs.
> > > > >
> > > > > When mixing network activity with task processing on a non-CPU device,
> > > > > there may be the need to put in communication the CPU with the device
> > > > > in order to manage the memory, synchronize operations, exchange info, etc..
> > > > >
> > > > > This library provides a number of new features:
> > > > > - Interoperability with device specific library with generic handlers
> > > > > - Possibility to allocate and free memory on the device
> > > > > - Possibility to allocate and free memory on the CPU but visible from the device
> > > > > - Communication functions to enhance the dialog between the CPU and the device
> > > > >
> > > > > The infrastructure is prepared to welcome drivers in drivers/hc/
> > > > > as the upcoming NVIDIA one, implementing the hcdev API.
> > > > >
> > > > > Some parts are not complete:
> > > > > - locks
> > > > > - memory allocation table
> > > > > - memory freeing
> > > > > - guide documentation
> > > > > - integration in devtools/check-doc-vs-code.sh
> > > > > - unit tests
> > > > > - integration in testpmd to enable Rx/Tx to/from GPU memory.
> > > >
> > > > Since the above line is the crux of the following text, I will start
> > > > from this point.
> > > >
> > > > + Techboard
> > > >
> > > > I can give my honest feedback on this.
> > > >
> > > > I can map similar stuff in Marvell HW, where we do machine learning
> > > > as compute offload
> > > > on a different class of CPU.
> > > >
> > > > In terms of RFC patch features
> > > >
> > > > 1) memory API - Use cases are aligned
> > > > 2) communication flag and communication list
> > > > Our structure is completely different and we are using HW ring kind of
> > > > interface to post the job to compute interface and
> > > > the job completion result happens through the event device.
> > > > Kind of similar to the DMA API that has been discussed on the mailing list.
> > >
> > > Interesting.
> >
> > It is hard to generalize the communication mechanism.
> > Is other GPU vendors have a similar communication mechanism? AMD, Intel ??
>
> I don't know who to ask in AMD & Intel. Any ideas?
Good question.
At least in Marvell HW, the communication flag and communication list is
our structure is completely different and we are using HW ring kind of
interface to post the job to compute interface and
the job completion result happens through the event device.
kind of similar to the DMA API that has been discussed on the mailing list.
>
> > > > Now the bigger question is why need to Tx and then Rx something to
> > > > compute the device
> > > > Isn't ot offload something? If so, why not add the those offload in
> > > > respective subsystem
> > > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt
> > > > new features or
> > > > introduce new subsystem (like ML, Inline Baseband processing) so that
> > > > it will be an opportunity to
> > > > implement the same in HW or compute device. For example, if we take
> > > > this path, ML offloading will
> > > > be application code like testpmd, which deals with "specific" device
> > > > commands(aka glorified rawdev)
> > > > to deal with specific computing device offload "COMMANDS"
> > > > (The commands will be specific to offload device, the same code wont
> > > > run on other compute device)
> > >
> > > Having specific features API is convenient for compatibility
> > > between devices, yes, for the set of defined features.
> > > Our approach is to start with a flexible API that the application
> > > can use to implement any processing because with GPU programming,
> > > there is no restriction on what can be achieved.
> > > This approach does not contradict what you propose,
> > > it does not prevent extending existing classes.
> >
> > It does prevent extending the existing classes as no one is going to
> > extent it there is the path of not doing do.
>
> I disagree. Specific API is more convenient for some tasks,
> so there is an incentive to define or extend specific device class APIs.
> But it should not forbid doing custom processing.
This is the same as the raw device is in DPDK where the device
personality is not defined.
Even if define another API and if the personality is not defined,
it comes similar to the raw device as similar
to rawdev enqueue and dequeue.
To summarize,
1) My _personal_ preference is to have specific subsystems
to improve the DPDK instead of the raw device kind of path.
2) If the device personality is not defined, use rawdev
3) All computing devices do not use "communication flag" and
"communication list"
kind of structure. If are targeting a generic computing device then
that is not a portable scheme.
For GPU abstraction if "communication flag" and "communication list"
is the right kind of mechanism
then we can have a separate library for GPU communication specific to GPU <->
DPDK communication needs and explicit for GPU.
I think generic DPDK applications like testpmd should not
pollute with device-specific functions. Like, call device-specific
messages from the application
which makes the application runs only one device. I don't have a
strong opinion(expect
standardizing "communication flag" and "communication list" as
generic computing device
communication mechanism) of others think it is OK to do that way in DPDK.
>
> > If an application can run only on a specific device, it is similar to
> > a raw device,
> > where the device definition is not defined. (i.e JOB metadata is not defined and
> > it is specific to the device).
> >
> > > > Just my _personal_ preference is to have specific subsystems to
> > > > improve the DPDK instead of raw device kind of
> > > > path. If we decide another path as a community it is _fine_ too(as a
> > > > _project manager_ point of view it will be an easy path to dump SDK
> > > > stuff to DPDK without introducing the pain of the subsystem nor
> > > > improving the DPDK).
> > >
> > > Adding a new class API is also improving DPDK.
> >
> > But the class is similar as raw dev class. The reason I say,
> > Job submission and response is can be abstracted as queue/dequeue APIs.
> > Taks/Job metadata is specific to compute devices (and it can not be
> > generalized).
> > If we generalize it makes sense to have a new class that does
> > "specific function".
>
> Computing device programming is already generalized with languages like OpenCL.
> We should not try to reinvent the same.
> We are just trying to properly integrate the concept in DPDK
> and allow building on top of it.
See above.
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
2021-07-31 13:42 2% ` Jerin Jacob
@ 2021-08-27 9:44 2% ` Thomas Monjalon
2021-08-27 12:19 3% ` Jerin Jacob
0 siblings, 1 reply; 53+ results
From: Thomas Monjalon @ 2021-08-27 9:44 UTC (permalink / raw)
To: Jerin Jacob, Jerin Jacob
Cc: dev, Stephen Hemminger, David Marchand, Andrew Rybchenko,
Haiyue Wang, Honnappa Nagarahalli, Ferruh Yigit, techboard,
Elena Agostini
31/07/2021 15:42, Jerin Jacob:
> On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 31/07/2021 09:06, Jerin Jacob:
> > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > From: Elena Agostini <eagostini@nvidia.com>
> > > >
> > > > In heterogeneous computing system, processing is not only in the CPU.
> > > > Some tasks can be delegated to devices working in parallel.
> > > >
> > > > The goal of this new library is to enhance the collaboration between
> > > > DPDK, that's primarily a CPU framework, and other type of devices like GPUs.
> > > >
> > > > When mixing network activity with task processing on a non-CPU device,
> > > > there may be the need to put in communication the CPU with the device
> > > > in order to manage the memory, synchronize operations, exchange info, etc..
> > > >
> > > > This library provides a number of new features:
> > > > - Interoperability with device specific library with generic handlers
> > > > - Possibility to allocate and free memory on the device
> > > > - Possibility to allocate and free memory on the CPU but visible from the device
> > > > - Communication functions to enhance the dialog between the CPU and the device
> > > >
> > > > The infrastructure is prepared to welcome drivers in drivers/hc/
> > > > as the upcoming NVIDIA one, implementing the hcdev API.
> > > >
> > > > Some parts are not complete:
> > > > - locks
> > > > - memory allocation table
> > > > - memory freeing
> > > > - guide documentation
> > > > - integration in devtools/check-doc-vs-code.sh
> > > > - unit tests
> > > > - integration in testpmd to enable Rx/Tx to/from GPU memory.
> > >
> > > Since the above line is the crux of the following text, I will start
> > > from this point.
> > >
> > > + Techboard
> > >
> > > I can give my honest feedback on this.
> > >
> > > I can map similar stuff in Marvell HW, where we do machine learning
> > > as compute offload
> > > on a different class of CPU.
> > >
> > > In terms of RFC patch features
> > >
> > > 1) memory API - Use cases are aligned
> > > 2) communication flag and communication list
> > > Our structure is completely different and we are using HW ring kind of
> > > interface to post the job to compute interface and
> > > the job completion result happens through the event device.
> > > Kind of similar to the DMA API that has been discussed on the mailing list.
> >
> > Interesting.
>
> It is hard to generalize the communication mechanism.
> Is other GPU vendors have a similar communication mechanism? AMD, Intel ??
I don't know who to ask in AMD & Intel. Any ideas?
> > > Now the bigger question is why need to Tx and then Rx something to
> > > compute the device
> > > Isn't ot offload something? If so, why not add the those offload in
> > > respective subsystem
> > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt
> > > new features or
> > > introduce new subsystem (like ML, Inline Baseband processing) so that
> > > it will be an opportunity to
> > > implement the same in HW or compute device. For example, if we take
> > > this path, ML offloading will
> > > be application code like testpmd, which deals with "specific" device
> > > commands(aka glorified rawdev)
> > > to deal with specific computing device offload "COMMANDS"
> > > (The commands will be specific to offload device, the same code wont
> > > run on other compute device)
> >
> > Having specific features API is convenient for compatibility
> > between devices, yes, for the set of defined features.
> > Our approach is to start with a flexible API that the application
> > can use to implement any processing because with GPU programming,
> > there is no restriction on what can be achieved.
> > This approach does not contradict what you propose,
> > it does not prevent extending existing classes.
>
> It does prevent extending the existing classes as no one is going to
> extent it there is the path of not doing do.
I disagree. Specific API is more convenient for some tasks,
so there is an incentive to define or extend specific device class APIs.
But it should not forbid doing custom processing.
> If an application can run only on a specific device, it is similar to
> a raw device,
> where the device definition is not defined. (i.e JOB metadata is not defined and
> it is specific to the device).
>
> > > Just my _personal_ preference is to have specific subsystems to
> > > improve the DPDK instead of raw device kind of
> > > path. If we decide another path as a community it is _fine_ too(as a
> > > _project manager_ point of view it will be an easy path to dump SDK
> > > stuff to DPDK without introducing the pain of the subsystem nor
> > > improving the DPDK).
> >
> > Adding a new class API is also improving DPDK.
>
> But the class is similar as raw dev class. The reason I say,
> Job submission and response is can be abstracted as queue/dequeue APIs.
> Taks/Job metadata is specific to compute devices (and it can not be
> generalized).
> If we generalize it makes sense to have a new class that does
> "specific function".
Computing device programming is already generalized with languages like OpenCL.
We should not try to reinvent the same.
We are just trying to properly integrate the concept in DPDK
and allow building on top of it.
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
@ 2021-07-31 13:42 2% ` Jerin Jacob
2021-08-27 9:44 2% ` Thomas Monjalon
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2021-07-31 13:42 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dpdk-dev, Stephen Hemminger, David Marchand, Andrew Rybchenko,
Haiyue Wang, Honnappa Nagarahalli, Jerin Jacob, Ferruh Yigit,
techboard
On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 31/07/2021 09:06, Jerin Jacob:
> > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > From: Elena Agostini <eagostini@nvidia.com>
> > >
> > > In heterogeneous computing system, processing is not only in the CPU.
> > > Some tasks can be delegated to devices working in parallel.
> > >
> > > The goal of this new library is to enhance the collaboration between
> > > DPDK, that's primarily a CPU framework, and other type of devices like GPUs.
> > >
> > > When mixing network activity with task processing on a non-CPU device,
> > > there may be the need to put in communication the CPU with the device
> > > in order to manage the memory, synchronize operations, exchange info, etc..
> > >
> > > This library provides a number of new features:
> > > - Interoperability with device specific library with generic handlers
> > > - Possibility to allocate and free memory on the device
> > > - Possibility to allocate and free memory on the CPU but visible from the device
> > > - Communication functions to enhance the dialog between the CPU and the device
> > >
> > > The infrastructure is prepared to welcome drivers in drivers/hc/
> > > as the upcoming NVIDIA one, implementing the hcdev API.
> > >
> > > Some parts are not complete:
> > > - locks
> > > - memory allocation table
> > > - memory freeing
> > > - guide documentation
> > > - integration in devtools/check-doc-vs-code.sh
> > > - unit tests
> > > - integration in testpmd to enable Rx/Tx to/from GPU memory.
> >
> > Since the above line is the crux of the following text, I will start
> > from this point.
> >
> > + Techboard
> >
> > I can give my honest feedback on this.
> >
> > I can map similar stuff in Marvell HW, where we do machine learning
> > as compute offload
> > on a different class of CPU.
> >
> > In terms of RFC patch features
> >
> > 1) memory API - Use cases are aligned
> > 2) communication flag and communication list
> > Our structure is completely different and we are using HW ring kind of
> > interface to post the job to compute interface and
> > the job completion result happens through the event device.
> > Kind of similar to the DMA API that has been discussed on the mailing list.
>
> Interesting.
It is hard to generalize the communication mechanism.
Is other GPU vendors have a similar communication mechanism? AMD, Intel ??
>
> > Now the bigger question is why need to Tx and then Rx something to
> > compute the device
> > Isn't ot offload something? If so, why not add the those offload in
> > respective subsystem
> > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt
> > new features or
> > introduce new subsystem (like ML, Inline Baseband processing) so that
> > it will be an opportunity to
> > implement the same in HW or compute device. For example, if we take
> > this path, ML offloading will
> > be application code like testpmd, which deals with "specific" device
> > commands(aka glorified rawdev)
> > to deal with specific computing device offload "COMMANDS"
> > (The commands will be specific to offload device, the same code wont
> > run on other compute device)
>
> Having specific features API is convenient for compatibility
> between devices, yes, for the set of defined features.
> Our approach is to start with a flexible API that the application
> can use to implement any processing because with GPU programming,
> there is no restriction on what can be achieved.
> This approach does not contradict what you propose,
> it does not prevent extending existing classes.
It does prevent extending the existing classes as no one is going to
extent it there is the path of not doing do.
If an application can run only on a specific device, it is similar to
a raw device,
where the device definition is not defined. (i.e JOB metadata is not defined and
it is specific to the device).
>
> > Just my _personal_ preference is to have specific subsystems to
> > improve the DPDK instead of raw device kind of
> > path. If we decide another path as a community it is _fine_ too(as a
> > _project manager_ point of view it will be an easy path to dump SDK
> > stuff to DPDK without introducing the pain of the subsystem nor
> > improving the DPDK).
>
> Adding a new class API is also improving DPDK.
But the class is similar as raw dev class. The reason I say,
Job submission and response is can be abstracted as queue/dequeue APIs.
Taks/Job metadata is specific to compute devices (and it can not be
generalized).
If we generalize it makes sense to have a new class that does
"specific function".
>
>
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] gpudev: introduce memory API
2021-06-07 13:54 3% ` Jerin Jacob
@ 2021-06-07 23:31 2% ` Honnappa Nagarahalli
0 siblings, 0 replies; 53+ results
From: Honnappa Nagarahalli @ 2021-06-07 23:31 UTC (permalink / raw)
To: Jerin Jacob, thomas
Cc: Andrew Rybchenko, Yigit, Ferruh, dpdk-dev, Elena Agostini,
David Marchand, nd, Wang, Haiyue, Honnappa Nagarahalli, nd
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> On Mon, Jun 7, 2021 at 4:13 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> >
> > 07/06/2021 09:20, Wang, Haiyue:
> > > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > If we keep CXL in mind, I would imagine that in the future the
> > > > devices on PCIe could have their own local memory. May be some of
> > > > the APIs could use generic names. For ex: instead of calling it as
> > > > "rte_gpu_malloc" may be we could call it as "rte_dev_malloc". This way
> any future device which hosts its own memory that need to be managed by
> the application, can use these APIs.
> > > >
> > >
> > > "rte_dev_malloc" sounds a good name,
> >
> > Yes I like the idea.
> > 2 concerns:
> >
> > 1/ Device memory allocation requires a device handle.
> > So far we avoided exposing rte_device to the application.
> > How should we get a device handle from a DPDK application?
>
> Each device behaves differently at this level. In the view of the generic
> application, the architecture should like
>
> < Use DPDK subsystem as rte_ethdev, rte_bbdev etc for SPECIFIC function > ^
> |
> < DPDK driver>
> ^
> |
> <rte_device with this new callbacks >
>
> An implementation may decide to have "in tree" or "out of tree"
> drivers or rte_device implementaion.
> But generic DPDK applications should not use devices directly. i.e rte_device
> need to have this callback and mlx ethdev/crypto driver use this driver to
> implement public API.
> Otherwise, it is the same as rawdev in DPDK.
> So not sure what it brings other than raw dev here if we are not taking the
> above architecture.
Agree, I think it is important to hide the device under the APIs for the application to benefit.
>
> >
> > 2/ Implementation must be done in a driver.
> > Should it be a callback defined at rte_device level?
>
> IMO, Yes and DPDK subsystem drivers to use it.
>
> >
> > > then looks like we need to enhance the 'struct rte_device' with some
> > > new ops as:
> > >
> > > eal: move DMA mapping from bus-specific to generic driver
> > >
> > >
> https://patchwork.dpdk.org/project/dpdk/patch/20210331224547.2217759
> > > -1-thomas@monjalon.net/
> >
> > Not sure the above patch is a good idea.
> > Let's discuss this DMA detail later :)
> >
> >
> >
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] gpudev: introduce memory API
@ 2021-06-07 13:54 3% ` Jerin Jacob
2021-06-07 23:31 2% ` Honnappa Nagarahalli
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2021-06-07 13:54 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Honnappa Nagarahalli, Andrew Rybchenko, Yigit, Ferruh, dpdk-dev,
Elena Agostini, David Marchand, nd, Wang, Haiyue
On Mon, Jun 7, 2021 at 4:13 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 07/06/2021 09:20, Wang, Haiyue:
> > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > If we keep CXL in mind, I would imagine that in the future the devices on PCIe could have their own
> > > local memory. May be some of the APIs could use generic names. For ex: instead of calling it as
> > > "rte_gpu_malloc" may be we could call it as "rte_dev_malloc". This way any future device which hosts
> > > its own memory that need to be managed by the application, can use these APIs.
> > >
> >
> > "rte_dev_malloc" sounds a good name,
>
> Yes I like the idea.
> 2 concerns:
>
> 1/ Device memory allocation requires a device handle.
> So far we avoided exposing rte_device to the application.
> How should we get a device handle from a DPDK application?
Each device behaves differently at this level. In the view of the
generic application, the architecture should like
< Use DPDK subsystem as rte_ethdev, rte_bbdev etc for SPECIFIC function >
^
|
< DPDK driver>
^
|
<rte_device with this new callbacks >
An implementation may decide to have "in tree" or "out of tree"
drivers or rte_device implementaion.
But generic DPDK applications should not use devices directly. i.e
rte_device need to have this callback and
mlx ethdev/crypto driver use this driver to implement public API.
Otherwise, it is the same as rawdev in DPDK.
So not sure what it brings other than raw dev here if we are not
taking the above architecture.
>
> 2/ Implementation must be done in a driver.
> Should it be a callback defined at rte_device level?
IMO, Yes and DPDK subsystem drivers to use it.
>
> > then looks like we need to enhance the
> > 'struct rte_device' with some new ops as:
> >
> > eal: move DMA mapping from bus-specific to generic driver
> >
> > https://patchwork.dpdk.org/project/dpdk/patch/20210331224547.2217759-1-thomas@monjalon.net/
>
> Not sure the above patch is a good idea.
> Let's discuss this DMA detail later :)
>
>
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 20.11
@ 2020-11-24 20:40 19% John McNamara
0 siblings, 0 replies; 53+ results
From: John McNamara @ 2020-11-24 20:40 UTC (permalink / raw)
To: dev; +Cc: thomas, John McNamara
Fix grammar, spelling and formatting of DPDK 20.11 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_20_11.rst | 178 +++++++++++++------------
1 file changed, 94 insertions(+), 84 deletions(-)
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index ea70289af..2ce47614c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -59,7 +59,7 @@ New Features
Added ``rte_write32_wc`` and ``rte_write32_wc_relaxed`` APIs
that enable write combining stores (depending on architecture).
- The functions are provided as a generic stubs and
+ The functions are provided as a generic stub and
x86 specific implementation.
* **Added prefetch with intention to write APIs.**
@@ -108,45 +108,50 @@ New Features
* **Added the FEC API, for a generic FEC query and config.**
Added the FEC API which provides functions for query FEC capabilities and
- current FEC mode from device. Also, API for configuring FEC mode is also provided.
+ current FEC mode from device. An API for configuring FEC mode is also provided.
* **Added thread safety to rte_flow functions.**
- Added ``RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE`` device flag to indicate
- whether PMD supports thread safe operations. If PMD doesn't set the flag,
- rte_flow API level functions will protect the flow operations with mutex.
+ Added the ``RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE`` device flag to indicate
+ whether a PMD supports thread safe operations. If the PMD doesn't set the flag,
+ the rte_flow API level functions will protect the flow operations with a mutex.
* **Added flow-based traffic sampling support.**
- Added new action: ``RTE_FLOW_ACTION_TYPE_SAMPLE`` to duplicate the matching
- packets with specified ratio, and apply with own set of actions with a fate
- action. When the ratio is set to 1 then the packets will be 100% mirrored.
+ Added a new action ``RTE_FLOW_ACTION_TYPE_SAMPLE`` that will sample the
+ incoming traffic and send a duplicated traffic with the specified ratio to
+ the application, while the original packet will continue to the target
+ destination.
+
+ The packets sampling is '1/ratio'. A ratio value set to 1 means that the
+ packets will be completely mirrored. The sample packet can be assigned with
+ a different set of actions than the original packet.
* **Added support of shared action in flow API.**
- Added shared action support to utilize single flow action in multiple flow
- rules. An update of shared action configuration alters the behavior of all
+ Added shared action support to use single flow actions in multiple flow
+ rules. An update to the shared action configuration alters the behavior of all
flow rules using it.
- * Added new action: ``RTE_FLOW_ACTION_TYPE_SHARED`` to use shared action
- as flow action.
- * Added new flow APIs to create/update/destroy/query shared action.
+ * Added a new action: ``RTE_FLOW_ACTION_TYPE_SHARED`` to use shared action
+ as a flow action.
+ * Added new flow APIs to create/update/destroy/query shared actions.
-* **Flow rules allowed to use private PMD items / actions.**
+* **Added support to flow rules to allow private PMD items/actions.**
- * Flow rule verification was updated to accept private PMD
+ * Flow rule verification has been updated to accept private PMD
items and actions.
-* **Added generic API to offload tunneled traffic and restore missed packet.**
+* **Added a generic API to offload tunneled traffic and restore missed packets.**
- * Added a new hardware independent helper to flow API that
+ * Added a new hardware independent helper to the flow API that
offloads tunneled traffic and restores missed packets.
* **Updated the ethdev library to support hairpin between two ports.**
- New APIs are introduced to support binding / unbinding 2 ports hairpin.
- Hairpin Tx part flow rules can be inserted explicitly.
- New API is added to get the hairpin peer ports list.
+ New APIs have been introduced to support binding / unbinding of 2 ports in a
+ hairpin configuration. The hairpin Tx part flow rules can be inserted
+ explicitly. A new API has been added to get the hairpin peer ports list.
* **Updated the Amazon ena driver.**
@@ -175,12 +180,12 @@ New Features
* **Added hns3 FEC PMD, for supporting query and config FEC mode.**
- Added the FEC PMD which provides functions for query FEC capabilities and
- current FEC mode from device. Also, PMD for configuring FEC mode is also provided.
+ Added the FEC PMD which provides functions for querying FEC capabilities and
+ current FEC mode from a device. A PMD for configuring FEC mode is also provided.
-* **Updated Intel iavf driver.**
+* **Updated the Intel iavf driver.**
- Updated iavf PMD with new features and improvements, including:
+ Updated the iavf PMD with new features and improvements, including:
* Added support for flexible descriptor metadata extraction.
* Added support for outer IP hash of GTPC and GTPU.
@@ -189,12 +194,12 @@ New Features
* **Updated Intel ice driver.**
- * Used write combining stores.
- * Added ACL filter support for Intel DCF.
+ * Added support for write combining stores.
+ * Added ACL filter support for the Intel DCF.
-* **Updated Mellanox mlx5 driver.**
+* **Updated the Mellanox mlx5 driver.**
- Updated Mellanox mlx5 driver with new features and improvements, including:
+ Updated the Mellanox mlx5 driver with new features and improvements, including:
* Added vectorized Multi-Packet Rx Queue burst.
* Added support for 2 new miniCQE formats: Flow Tag and L3/L4 header.
@@ -204,9 +209,9 @@ New Features
* Added support for the new VLAN fields ``has_vlan`` in the Ethernet item
and ``has_more_vlan`` in the VLAN item.
* Updated the supported timeout for Age action to the maximal value supported
- by rte_flow API.
- * Added support of Age action query.
- * Added support of multi-ports hairpin.
+ by the rte_flow API.
+ * Added support for Age action query.
+ * Added support for multi-ports hairpin.
* Allow unknown link speed.
Updated Mellanox mlx5 vDPA driver:
@@ -221,7 +226,7 @@ New Features
* Added Alveo SN1000 SmartNICs (EF100 architecture) support including
flow API transfer rules for switch HW offload
* Added ARMv8 support
- * Claimed flow API native thread safety
+ * Added flow API native thread safety
* **Added Wangxun txgbe PMD.**
@@ -231,9 +236,9 @@ New Features
* **Updated Virtio driver.**
- * Added support for Vhost-vDPA backend to Virtio-user PMD.
+ * Added support for Vhost-vDPA backend to the Virtio-user PMD.
* Changed default link speed to unknown.
- * Added support for 200G link speed.
+ * Added support for the 200G link speed.
* **Updated Intel i40e driver.**
@@ -249,40 +254,40 @@ New Features
* **Updated Memif PMD.**
- * Added support for abstract socket address.
+ * Added support for abstract socket addresses.
* Changed default socket address type to abstract.
* **Added Ice Lake (Gen4) support for Intel NTB.**
- Added NTB device support (4th generation) for Intel Ice Lake platform.
+ Added NTB device support (4th generation) for the Intel Ice Lake platform.
* **Added UDP/IPv4 GRO support for VxLAN and non-VxLAN packets.**
For VxLAN packets, added inner UDP/IPv4 support.
For non-VxLAN packets, added UDP/IPv4 support.
-* **Extended flow-perf application.**
+* **Extended the flow-perf application.**
- * Started supporting user order instead of bit mask:
+ * Added support for user order instead of bit mask.
Now the user can create any structure of rte_flow
- using flow performance application with any order,
- moreover the app also now starts to support inner
+ using the flow performance application with any order.
+ Moreover the app also now starts to support inner
items matching as well.
* Added header modify actions.
* Added flag action.
* Added raw encap/decap actions.
* Added VXLAN encap/decap actions.
- * Added ICMP(code/type/identifier/sequence number) and ICMP6(code/type) matching items.
+ * Added ICMP (code/type/identifier/sequence number) and ICMP6 (code/type) matching items.
* Added option to set port mask for insertion/deletion:
``--portmask=N``
- where N represents the hexadecimal bitmask of ports used.
+ where N represents the hexadecimal bitmask of the ports used.
* **Added raw data-path APIs for cryptodev library.**
- Cryptodev is added with raw data-path APIs to accelerate external
- libraries or applications which need to avail fast cryptodev
- enqueue/dequeue operations but does not necessarily depends on
- mbufs and cryptodev operation mempools.
+ Added raw data-path APIs to Cryptodev to help accelerate external libraries
+ or applications which need to avail of fast cryptodev enqueue/dequeue
+ operations but which do not necessarily need to depend on mbufs and
+ cryptodev operation mempools.
* **Updated the aesni_mb crypto PMD.**
@@ -319,7 +324,7 @@ New Features
* Updated the OCTEON TX2 crypto PMD lookaside protocol offload for IPsec with
IPv6 support.
-* **Updated QAT crypto PMD.**
+* **Updated the QAT crypto PMD.**
* Added Raw Data-path APIs support.
@@ -332,18 +337,18 @@ New Features
* **Updated rte_security library to support SDAP.**
``rte_security_pdcp_xform`` in ``rte_security`` lib is updated to enable
- 5G NR processing of SDAP header in PMDs.
+ 5G NR processing of SDAP headers in PMDs.
* **Added Marvell OCTEON TX2 regex PMD.**
- Added a new PMD driver for hardware regex offload block for OCTEON TX2 SoC.
+ Added a new PMD driver for the hardware regex offload block for OCTEON TX2 SoC.
See the :doc:`../regexdevs/octeontx2` for more details.
* **Updated Software Eventdev driver.**
Added performance tuning arguments to allow tuning the scheduler for
- better throughtput in high core count use cases.
+ better throughput in high core count use cases.
* **Added a new driver for the Intel Dynamic Load Balancer v1.0 device.**
@@ -355,12 +360,14 @@ New Features
Added the new ``dlb2`` eventdev driver for the Intel DLB V2.0 device. See the
:doc:`../eventdevs/dlb2` eventdev guide for more details on this new driver.
-* **Updated ioat rawdev driver**
+* **Updated ioat rawdev driver.**
The ioat rawdev driver has been updated and enhanced. Changes include:
- * Added support for Intel\ |reg| Data Streaming Accelerator hardware.
- For more information, see https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator
+ * Added support for Intel\ |reg| Data Streaming Accelerator hardware. For
+ more information, see `Introducing the Intel Data Streaming Accelerator
+ (Intel DSA)
+ <https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator>`_.
* Added support for the fill operation via the API ``rte_ioat_enqueue_fill()``,
where the hardware fills an area of memory with a repeating pattern.
* Added a per-device configuration flag to disable management
@@ -369,7 +376,7 @@ New Features
and renamed the ``rte_ioat_completed_copies()`` API to ``rte_ioat_completed_ops()``
to better reflect the APIs' purposes, and remove the implication that
they are limited to copy operations only.
- [Note: The old API is still provided but marked as deprecated in the code]
+ Note: The old API is still provided but marked as deprecated in the code.
* Added a new API ``rte_ioat_fence()`` to add a fence between operations.
This API replaces the ``fence`` flag parameter in the ``rte_ioat_enqueue_copies()`` function,
and is clearer as there is no ambiguity as to whether the flag should be
@@ -377,11 +384,12 @@ New Features
* **Updated the pipeline library for alignment with the P4 language.**
- Added new Software Switch (SWX) pipeline type that provides more
- flexibility through API and feature alignment with the P4 language.
+ Added a new Software Switch (SWX) pipeline type that provides more
+ flexibility through APIs and feature alignment with the P4 language.
+ Some enhancements are:
* The packet headers, meta-data, actions, tables and pipelines are
- dynamically defined instead of selected from pre-defined set.
+ dynamically defined instead of selected from a pre-defined set.
* The actions and the pipeline are defined with instructions.
* Extern objects and functions can be plugged into the pipeline.
* Transaction-oriented table updates.
@@ -401,9 +409,9 @@ New Features
* **Added support to update subport bandwidth dynamically.**
* Added new API ``rte_sched_port_subport_profile_add`` to add new
- subport bandwidth profile to subport porfile table at runtime.
+ subport bandwidth profiles to the subport profile table at runtime.
- * Added support to update subport rate dynamically.
+ * Added support to update the subport rate dynamically.
* **Updated FIPS validation sample application.**
@@ -420,8 +428,8 @@ New Features
* **Updated vhost sample application.**
- Added vhost asynchronous APIs support, which demonstrated how the application
- leverage IOAT DMA channel with vhost asynchronous APIs.
+ Added vhost asynchronous APIs support, which demonstrates how the application
+ can leverage IOAT DMA channels with vhost asynchronous APIs.
See the :doc:`../sample_app_ug/vhost` for more details.
@@ -437,16 +445,18 @@ Removed Items
Also, make sure to start the actual text at the margin.
=======================================================
-* build: Support for the Make build system was removed for compiling DPDK,
+* build: Support for the Make build system has been removed from DPDK.
Meson is now the primary build system.
Sample applications can still be built with Make standalone, using pkg-config.
* vhost: Dequeue zero-copy support has been removed.
* kernel: The module ``igb_uio`` has been moved to the git repository
- ``dpdk-kmods`` in a new directory ``linux/igb_uio``.
+ `dpdk-kmods <https://git.dpdk.org/dpdk-kmods/>`_ in a new directory
+ ``linux/igb_uio``.
-* Removed Python 2 support since it was EOL'd in January 2020.
+* Removed Python 2 support since it was sunsetted in January 2020. See
+ `Sunsetting Python 2 <https://www.python.org/doc/sunset-python-2/>`_
* Removed TEP termination sample application.
@@ -466,11 +476,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* build macros: The macros defining ``RTE_MACHINE_CPUFLAG_*`` are removed.
- The information provided by these macros is available through standard
+* build macros: The macros defining ``RTE_MACHINE_CPUFLAG_*`` have been removed.
+ The information provided by these macros is now available through standard
compiler macros.
-* eal: Replaced the function ``rte_get_master_lcore()`` to
+* eal: Replaced the function ``rte_get_master_lcore()`` with
``rte_get_main_lcore()``. The old function is deprecated.
The iterator for worker lcores is also changed:
@@ -478,7 +488,7 @@ API Changes
``RTE_LCORE_FOREACH_WORKER``.
* eal: The definitions related to including and excluding devices
- has been changed from blacklist/whitelist to block/allow list.
+ have been changed from blacklist/whitelist to block/allow list.
There are compatibility macros and command line mapping to accept
the old values but applications and scripts are strongly encouraged
to migrate to the new names.
@@ -494,11 +504,11 @@ API Changes
* mem: Removed the unioned field ``phys_addr`` from
the structures ``rte_memseg`` and ``rte_memzone``.
- The field ``iova`` is remaining from the old unions.
+ The field ``iova`` remains from the old unions.
* mempool: Removed the unioned fields ``phys_addr`` and ``physaddr`` from
the structures ``rte_mempool_memhdr`` and ``rte_mempool_objhdr``.
- The field ``iova`` is remaining from the old unions.
+ The field ``iova`` remains from the old unions.
The flag name ``MEMPOOL_F_NO_PHYS_CONTIG`` is removed,
while the aliased flag ``MEMPOOL_F_NO_IOVA_CONTIG`` is kept.
@@ -508,11 +518,11 @@ API Changes
having ``iova`` in their names instead of ``dma_addr`` or ``mtophys``.
* mbuf: Removed the unioned field ``buf_physaddr`` from ``rte_mbuf``.
- The field ``buf_iova`` is remaining from the old union.
+ The field ``buf_iova`` remains from the old union.
* mbuf: Removed the unioned field ``refcnt_atomic`` from
the structures ``rte_mbuf`` and ``rte_mbuf_ext_shared_info``.
- The field ``refcnt`` is remaining from the old unions.
+ The field ``refcnt`` remains from the old unions.
* mbuf: Removed the unioned fields ``userdata`` and ``udata64``
from the structure ``rte_mbuf``. It is replaced with dynamic fields.
@@ -558,7 +568,7 @@ API Changes
* ethdev: Modified field type of ``base`` and ``nb_queue`` in struct
``rte_eth_dcb_tc_queue_mapping`` from ``uint8_t`` to ``uint16_t``.
- As the data of ``uint8_t`` will be truncated when queue number under
+ As the data of ``uint8_t`` will be truncated when queue number in
a TC is greater than 256.
* ethdev: Removed the legacy filter API, including
@@ -574,7 +584,7 @@ API Changes
instead of ``rte_vhost_driver_start`` by crypto applications.
* cryptodev: The structure ``rte_crypto_sym_vec`` is updated to support both
- cpu_crypto synchrounous operation and asynchronous raw data-path APIs.
+ cpu_crypto synchronous operations and asynchronous raw data-path APIs.
* cryptodev: ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum rte_crypto_aead_algorithm``,
``RTE_CRYPTO_CIPHER_LIST_END`` from ``enum rte_crypto_cipher_algorithm`` and
@@ -592,12 +602,12 @@ API Changes
``RTE_CRYPTODEV_SCHEDULER_MAX_NB_SLAVES`` to
``RTE_CRYPTODEV_SCHEDULER_MAX_NB_WORKERS``.
-* security: ``hfn_ovrd`` field in ``rte_security_pdcp_xform`` is changed from
+* security: The ``hfn_ovrd`` field in ``rte_security_pdcp_xform`` is changed from
``uint32_t`` to ``uint8_t`` so that a new field ``sdap_enabled`` can be added
to support SDAP.
* security: The API ``rte_security_session_create`` is updated to take two
- mempool objects one for session and other for session private data.
+ mempool objects: one for session and other for session private data.
So the application need to create two mempools and get the size of session
private data using API ``rte_security_session_get_size`` for private session
mempool.
@@ -645,10 +655,10 @@ API Changes
* ``pkt`` is not freed, no matter whether it is GSOed, leaving to the caller.
* acl: ``RTE_ACL_CLASSIFY_NUM`` enum value has been removed.
- This enum value was not used inside DPDK, while it prevented to add new
+ This enum value was not used inside DPDK, while it prevented the addition of new
classify algorithms without causing an ABI breakage.
-* sched: Added ``subport_profile_id`` as argument
+* sched: Added ``subport_profile_id`` as an argument
to function ``rte_sched_subport_config``.
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
@@ -670,11 +680,11 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* eal: Removed the not implemented function ``rte_dump_registers()``.
+* eal: Removed the unimplemented function ``rte_dump_registers()``.
* ``ethdev`` changes
- * Following device operation function pointers moved
+ * The following device operation function pointers moved
from ``struct eth_dev_ops`` to ``struct rte_eth_dev``:
* ``eth_rx_queue_count_t rx_queue_count;``
@@ -682,8 +692,8 @@ ABI Changes
* ``eth_rx_descriptor_status_t rx_descriptor_status;``
* ``eth_tx_descriptor_status_t tx_descriptor_status;``
- * ``struct eth_dev_ops`` is no more accessible by applications,
- which was already internal data structure.
+ * ``struct eth_dev_ops`` is no longer accessible by applications,
+ which was already an internal data structure.
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
@@ -704,11 +714,11 @@ ABI Changes
* Added new field ``has_vlan`` to structure ``rte_flow_item_eth``,
indicating that packet header contains at least one VLAN.
- * Added new field ``has_more_vlan`` to structure
+ * Added new field ``has_more_vlan`` to the structure
``rte_flow_item_vlan``, indicating that packet header contains
at least one more VLAN, after this VLAN.
-* eventdev: Following structures are modified to support DLB/DLB2 PMDs
+* eventdev: The following structures are modified to support DLB/DLB2 PMDs
and future extensions:
* ``rte_event_dev_info``
--
2.25.1
^ permalink raw reply [relevance 19%]
* [dpdk-dev] [PATCH v2 0/7] raw/dpaa2_qdma: driver enhancement
2020-09-07 9:25 9% [dpdk-dev] [PATCH 0/7] raw/dpaa2_qdma: driver enhancement Gagandeep Singh
2020-09-25 10:54 2% ` Hemant Agrawal
@ 2020-10-15 9:47 9% ` Gagandeep Singh
1 sibling, 0 replies; 53+ results
From: Gagandeep Singh @ 2020-10-15 9:47 UTC (permalink / raw)
To: dev, nipun.gupta, hemant.agrawal; +Cc: thomas, Gagandeep Singh
In this patchset, we have done some changes in dpaa2_qdma driver
related to rawdev APIs, optimizations, scatter-gather support on TX,
enqueue without wait.
v2-change-log:
* Rebase and compilation fixes
Gagandeep Singh (2):
raw/dpaa2_qdma: change DPAA2 QDMA APIs to rawdev ops
raw/dpaa2_qdma: memset to only required memory
Jun Yang (5):
raw/dpaa2_qdma: refactor the code
raw/dpaa2_qdma: optimize IOVA conversion
raw/dpaa2_qdma: support scatter gather in enqueue
raw/dpaa2_qdma: support FLE pool per queue
raw/dpaa2_qdma: support enqueue without response wait
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 18 +-
drivers/raw/dpaa2_qdma/dpaa2_qdma.c | 1833 +++++++++++--------
drivers/raw/dpaa2_qdma/dpaa2_qdma.h | 128 +-
drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h | 231 +--
4 files changed, 1267 insertions(+), 943 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v6 07/25] raw/ioat: rename functions to be operation-agnostic
@ 2020-10-08 9:51 11% ` Bruce Richardson
0 siblings, 0 replies; 53+ results
From: Bruce Richardson @ 2020-10-08 9:51 UTC (permalink / raw)
To: dev; +Cc: patrick.fu, thomas, Bruce Richardson, Kevin Laatz, Radu Nicolau
Since the hardware supported by the ioat driver is capable of operations
other than just copies, we can rename the doorbell and completion-return
functions to not have "copies" in their names. These functions are not
copy-specific, and so would apply for other operations which may be added
later to the driver.
Also add a suitable warning using deprecation attribute for any code using
the old functions names.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Radu Nicolau <radu.nicolau@intel.com>
---
doc/guides/rawdevs/ioat.rst | 16 ++++++++--------
doc/guides/rel_notes/release_20_11.rst | 9 +++++++++
doc/guides/sample_app_ug/ioat.rst | 8 ++++----
drivers/raw/ioat/ioat_rawdev_test.c | 12 ++++++------
drivers/raw/ioat/rte_ioat_rawdev.h | 17 ++++++++++-------
drivers/raw/ioat/rte_ioat_rawdev_fns.h | 20 ++++++++++++++++----
examples/ioat/ioatfwd.c | 4 ++--
lib/librte_eal/include/rte_common.h | 1 +
8 files changed, 56 insertions(+), 31 deletions(-)
diff --git a/doc/guides/rawdevs/ioat.rst b/doc/guides/rawdevs/ioat.rst
index af00d77fb..3db5f5d09 100644
--- a/doc/guides/rawdevs/ioat.rst
+++ b/doc/guides/rawdevs/ioat.rst
@@ -157,9 +157,9 @@ Performing Data Copies
~~~~~~~~~~~~~~~~~~~~~~~
To perform data copies using IOAT rawdev devices, the functions
-``rte_ioat_enqueue_copy()`` and ``rte_ioat_do_copies()`` should be used.
+``rte_ioat_enqueue_copy()`` and ``rte_ioat_perform_ops()`` should be used.
Once copies have been completed, the completion will be reported back when
-the application calls ``rte_ioat_completed_copies()``.
+the application calls ``rte_ioat_completed_ops()``.
The ``rte_ioat_enqueue_copy()`` function enqueues a single copy to the
device ring for copying at a later point. The parameters to that function
@@ -172,11 +172,11 @@ pointers if packet data is being copied.
While the ``rte_ioat_enqueue_copy()`` function enqueues a copy operation on
the device ring, the copy will not actually be performed until after the
-application calls the ``rte_ioat_do_copies()`` function. This function
+application calls the ``rte_ioat_perform_ops()`` function. This function
informs the device hardware of the elements enqueued on the ring, and the
device will begin to process them. It is expected that, for efficiency
reasons, a burst of operations will be enqueued to the device via multiple
-enqueue calls between calls to the ``rte_ioat_do_copies()`` function.
+enqueue calls between calls to the ``rte_ioat_perform_ops()`` function.
The following code from ``test_ioat_rawdev.c`` demonstrates how to enqueue
a burst of copies to the device and start the hardware processing of them:
@@ -210,10 +210,10 @@ a burst of copies to the device and start the hardware processing of them:
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
To retrieve information about completed copies, the API
-``rte_ioat_completed_copies()`` should be used. This API will return to the
+``rte_ioat_completed_ops()`` should be used. This API will return to the
application a set of completion handles passed in when the relevant copies
were enqueued.
@@ -223,9 +223,9 @@ is correct before freeing the data buffers using the returned handles:
.. code-block:: C
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- printf("Error with rte_ioat_completed_copies\n");
+ printf("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 1e73c26d4..e7d038f31 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -121,6 +121,11 @@ New Features
The ioat rawdev driver has been updated and enhanced. Changes include:
* Added a per-device configuration flag to disable management of user-provided completion handles
+ * Renamed the ``rte_ioat_do_copies()`` API to ``rte_ioat_perform_ops()``,
+ and renamed the ``rte_ioat_completed_copies()`` API to ``rte_ioat_completed_ops()``
+ to better reflect the APIs' purposes, and remove the implication that
+ they are limited to copy operations only.
+ [Note: The old API is still provided but marked as deprecated in the code]
Removed Items
@@ -234,6 +239,10 @@ API Changes
* bpf: ``RTE_BPF_XTYPE_NUM`` has been dropped from ``rte_bpf_xtype``.
+* raw/ioat: As noted above, the ``rte_ioat_do_copies()`` and
+ ``rte_ioat_completed_copies()`` functions have been renamed to
+ ``rte_ioat_perform_ops()`` and ``rte_ioat_completed_ops()`` respectively.
+
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/ioat.rst b/doc/guides/sample_app_ug/ioat.rst
index 3f7d5c34a..964160dff 100644
--- a/doc/guides/sample_app_ug/ioat.rst
+++ b/doc/guides/sample_app_ug/ioat.rst
@@ -394,7 +394,7 @@ packet using ``pktmbuf_sw_copy()`` function and enqueue them to an rte_ring:
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -433,7 +433,7 @@ The packets are received in burst mode using ``rte_eth_rx_burst()``
function. When using hardware copy mode the packets are enqueued in
copying device's buffer using ``ioat_enqueue_packets()`` which calls
``rte_ioat_enqueue_copy()``. When all received packets are in the
-buffer the copy operations are started by calling ``rte_ioat_do_copies()``.
+buffer the copy operations are started by calling ``rte_ioat_perform_ops()``.
Function ``rte_ioat_enqueue_copy()`` operates on physical address of
the packet. Structure ``rte_mbuf`` contains only physical address to
start of the data buffer (``buf_iova``). Thus the address is adjusted
@@ -490,7 +490,7 @@ or indirect mbufs, then multiple copy operations must be used.
All completed copies are processed by ``ioat_tx_port()`` function. When using
-hardware copy mode the function invokes ``rte_ioat_completed_copies()``
+hardware copy mode the function invokes ``rte_ioat_completed_ops()``
on each assigned IOAT channel to gather copied packets. If software copy
mode is used the function dequeues copied packets from the rte_ring. Then each
packet MAC address is changed if it was enabled. After that copies are sent
@@ -510,7 +510,7 @@ in burst mode using `` rte_eth_tx_burst()``.
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/drivers/raw/ioat/ioat_rawdev_test.c b/drivers/raw/ioat/ioat_rawdev_test.c
index 77f96bba3..439b46c03 100644
--- a/drivers/raw/ioat/ioat_rawdev_test.c
+++ b/drivers/raw/ioat/ioat_rawdev_test.c
@@ -65,12 +65,12 @@ test_enqueue_copies(int dev_id)
PRINT_ERR("Error with rte_ioat_enqueue_copy\n");
return -1;
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(10);
- if (rte_ioat_completed_copies(dev_id, 1, (void *)&completed[0],
+ if (rte_ioat_completed_ops(dev_id, 1, (void *)&completed[0],
(void *)&completed[1]) != 1) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
if (completed[0] != src || completed[1] != dst) {
@@ -119,12 +119,12 @@ test_enqueue_copies(int dev_id)
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(100);
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/drivers/raw/ioat/rte_ioat_rawdev.h b/drivers/raw/ioat/rte_ioat_rawdev.h
index 7067b352f..ae6393951 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev.h
@@ -69,24 +69,26 @@ struct rte_ioat_rawdev_config {
* Number of operations enqueued, either 0 or 1
*/
static inline int
+__rte_experimental
rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
unsigned int length, uintptr_t src_hdl, uintptr_t dst_hdl,
int fence);
/**
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*
* This API is used to write the "doorbell" to the hardware to trigger it
- * to begin the copy operations previously enqueued by rte_ioat_enqueue_copy()
+ * to begin the operations previously enqueued by rte_ioat_enqueue_copy()
*
* @param dev_id
* The rawdev device id of the ioat instance
*/
static inline void
-rte_ioat_do_copies(int dev_id);
+__rte_experimental
+rte_ioat_perform_ops(int dev_id);
/**
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*
* If the hdls_disable option was not set when the device was configured,
* the function will return to the caller the user-provided "handles" for
@@ -104,11 +106,11 @@ rte_ioat_do_copies(int dev_id);
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param src_hdls
- * Array to hold the source handle parameters of the completed copies.
+ * Array to hold the source handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param dst_hdls
- * Array to hold the destination handle parameters of the completed copies.
+ * Array to hold the destination handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @return
@@ -117,7 +119,8 @@ rte_ioat_do_copies(int dev_id);
* to the src_hdls and dst_hdls array parameters.
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+__rte_experimental
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls);
/* include the implementation details from a separate file */
diff --git a/drivers/raw/ioat/rte_ioat_rawdev_fns.h b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
index 4b7bdb8e2..b155d79c4 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev_fns.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
@@ -83,10 +83,10 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
}
/*
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*/
static inline void
-rte_ioat_do_copies(int dev_id)
+rte_ioat_perform_ops(int dev_id)
{
struct rte_ioat_rawdev *ioat =
(struct rte_ioat_rawdev *)rte_rawdevs[dev_id].dev_private;
@@ -114,10 +114,10 @@ rte_ioat_get_last_completed(struct rte_ioat_rawdev *ioat, int *error)
}
/*
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls)
{
struct rte_ioat_rawdev *ioat =
@@ -165,4 +165,16 @@ rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
return count;
}
+static inline void
+__rte_deprecated_msg("use rte_ioat_perform_ops() instead")
+rte_ioat_do_copies(int dev_id) { rte_ioat_perform_ops(dev_id); }
+
+static inline int
+__rte_deprecated_msg("use rte_ioat_completed_ops() instead")
+rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+ uintptr_t *src_hdls, uintptr_t *dst_hdls)
+{
+ return rte_ioat_completed_ops(dev_id, max_copies, src_hdls, dst_hdls);
+}
+
#endif /* _RTE_IOAT_RAWDEV_FNS_H_ */
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index 288a75c7b..67f75737b 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -406,7 +406,7 @@ ioat_rx_port(struct rxtx_port_config *rx_config)
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -452,7 +452,7 @@ ioat_tx_port(struct rxtx_port_config *tx_config)
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h
index 8f487a563..2920255fc 100644
--- a/lib/librte_eal/include/rte_common.h
+++ b/lib/librte_eal/include/rte_common.h
@@ -85,6 +85,7 @@ typedef uint16_t unaligned_uint16_t;
/******* Macro to mark functions and fields scheduled for removal *****/
#define __rte_deprecated __attribute__((__deprecated__))
+#define __rte_deprecated_msg(msg) __attribute__((__deprecated__(msg)))
/**
* Mark a function or variable to a weak reference.
--
2.25.1
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH v5 07/25] raw/ioat: rename functions to be operation-agnostic
@ 2020-10-07 16:30 11% ` Bruce Richardson
0 siblings, 0 replies; 53+ results
From: Bruce Richardson @ 2020-10-07 16:30 UTC (permalink / raw)
To: dev; +Cc: patrick.fu, thomas, Bruce Richardson, Kevin Laatz, Radu Nicolau
Since the hardware supported by the ioat driver is capable of operations
other than just copies, we can rename the doorbell and completion-return
functions to not have "copies" in their names. These functions are not
copy-specific, and so would apply for other operations which may be added
later to the driver.
Also add a suitable warning using deprecation attribute for any code using
the old functions names.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Radu Nicolau <radu.nicolau@intel.com>
---
doc/guides/rawdevs/ioat.rst | 16 ++++++++--------
doc/guides/rel_notes/release_20_11.rst | 9 +++++++++
doc/guides/sample_app_ug/ioat.rst | 8 ++++----
drivers/raw/ioat/ioat_rawdev_test.c | 12 ++++++------
drivers/raw/ioat/rte_ioat_rawdev.h | 14 +++++++-------
drivers/raw/ioat/rte_ioat_rawdev_fns.h | 20 ++++++++++++++++----
examples/ioat/ioatfwd.c | 4 ++--
lib/librte_eal/include/rte_common.h | 1 +
8 files changed, 53 insertions(+), 31 deletions(-)
diff --git a/doc/guides/rawdevs/ioat.rst b/doc/guides/rawdevs/ioat.rst
index af00d77fb..3db5f5d09 100644
--- a/doc/guides/rawdevs/ioat.rst
+++ b/doc/guides/rawdevs/ioat.rst
@@ -157,9 +157,9 @@ Performing Data Copies
~~~~~~~~~~~~~~~~~~~~~~~
To perform data copies using IOAT rawdev devices, the functions
-``rte_ioat_enqueue_copy()`` and ``rte_ioat_do_copies()`` should be used.
+``rte_ioat_enqueue_copy()`` and ``rte_ioat_perform_ops()`` should be used.
Once copies have been completed, the completion will be reported back when
-the application calls ``rte_ioat_completed_copies()``.
+the application calls ``rte_ioat_completed_ops()``.
The ``rte_ioat_enqueue_copy()`` function enqueues a single copy to the
device ring for copying at a later point. The parameters to that function
@@ -172,11 +172,11 @@ pointers if packet data is being copied.
While the ``rte_ioat_enqueue_copy()`` function enqueues a copy operation on
the device ring, the copy will not actually be performed until after the
-application calls the ``rte_ioat_do_copies()`` function. This function
+application calls the ``rte_ioat_perform_ops()`` function. This function
informs the device hardware of the elements enqueued on the ring, and the
device will begin to process them. It is expected that, for efficiency
reasons, a burst of operations will be enqueued to the device via multiple
-enqueue calls between calls to the ``rte_ioat_do_copies()`` function.
+enqueue calls between calls to the ``rte_ioat_perform_ops()`` function.
The following code from ``test_ioat_rawdev.c`` demonstrates how to enqueue
a burst of copies to the device and start the hardware processing of them:
@@ -210,10 +210,10 @@ a burst of copies to the device and start the hardware processing of them:
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
To retrieve information about completed copies, the API
-``rte_ioat_completed_copies()`` should be used. This API will return to the
+``rte_ioat_completed_ops()`` should be used. This API will return to the
application a set of completion handles passed in when the relevant copies
were enqueued.
@@ -223,9 +223,9 @@ is correct before freeing the data buffers using the returned handles:
.. code-block:: C
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- printf("Error with rte_ioat_completed_copies\n");
+ printf("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 1e73c26d4..e7d038f31 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -121,6 +121,11 @@ New Features
The ioat rawdev driver has been updated and enhanced. Changes include:
* Added a per-device configuration flag to disable management of user-provided completion handles
+ * Renamed the ``rte_ioat_do_copies()`` API to ``rte_ioat_perform_ops()``,
+ and renamed the ``rte_ioat_completed_copies()`` API to ``rte_ioat_completed_ops()``
+ to better reflect the APIs' purposes, and remove the implication that
+ they are limited to copy operations only.
+ [Note: The old API is still provided but marked as deprecated in the code]
Removed Items
@@ -234,6 +239,10 @@ API Changes
* bpf: ``RTE_BPF_XTYPE_NUM`` has been dropped from ``rte_bpf_xtype``.
+* raw/ioat: As noted above, the ``rte_ioat_do_copies()`` and
+ ``rte_ioat_completed_copies()`` functions have been renamed to
+ ``rte_ioat_perform_ops()`` and ``rte_ioat_completed_ops()`` respectively.
+
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/ioat.rst b/doc/guides/sample_app_ug/ioat.rst
index 3f7d5c34a..964160dff 100644
--- a/doc/guides/sample_app_ug/ioat.rst
+++ b/doc/guides/sample_app_ug/ioat.rst
@@ -394,7 +394,7 @@ packet using ``pktmbuf_sw_copy()`` function and enqueue them to an rte_ring:
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -433,7 +433,7 @@ The packets are received in burst mode using ``rte_eth_rx_burst()``
function. When using hardware copy mode the packets are enqueued in
copying device's buffer using ``ioat_enqueue_packets()`` which calls
``rte_ioat_enqueue_copy()``. When all received packets are in the
-buffer the copy operations are started by calling ``rte_ioat_do_copies()``.
+buffer the copy operations are started by calling ``rte_ioat_perform_ops()``.
Function ``rte_ioat_enqueue_copy()`` operates on physical address of
the packet. Structure ``rte_mbuf`` contains only physical address to
start of the data buffer (``buf_iova``). Thus the address is adjusted
@@ -490,7 +490,7 @@ or indirect mbufs, then multiple copy operations must be used.
All completed copies are processed by ``ioat_tx_port()`` function. When using
-hardware copy mode the function invokes ``rte_ioat_completed_copies()``
+hardware copy mode the function invokes ``rte_ioat_completed_ops()``
on each assigned IOAT channel to gather copied packets. If software copy
mode is used the function dequeues copied packets from the rte_ring. Then each
packet MAC address is changed if it was enabled. After that copies are sent
@@ -510,7 +510,7 @@ in burst mode using `` rte_eth_tx_burst()``.
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/drivers/raw/ioat/ioat_rawdev_test.c b/drivers/raw/ioat/ioat_rawdev_test.c
index 77f96bba3..439b46c03 100644
--- a/drivers/raw/ioat/ioat_rawdev_test.c
+++ b/drivers/raw/ioat/ioat_rawdev_test.c
@@ -65,12 +65,12 @@ test_enqueue_copies(int dev_id)
PRINT_ERR("Error with rte_ioat_enqueue_copy\n");
return -1;
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(10);
- if (rte_ioat_completed_copies(dev_id, 1, (void *)&completed[0],
+ if (rte_ioat_completed_ops(dev_id, 1, (void *)&completed[0],
(void *)&completed[1]) != 1) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
if (completed[0] != src || completed[1] != dst) {
@@ -119,12 +119,12 @@ test_enqueue_copies(int dev_id)
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(100);
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/drivers/raw/ioat/rte_ioat_rawdev.h b/drivers/raw/ioat/rte_ioat_rawdev.h
index 7067b352f..5b2c47e8c 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev.h
@@ -74,19 +74,19 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
int fence);
/**
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*
* This API is used to write the "doorbell" to the hardware to trigger it
- * to begin the copy operations previously enqueued by rte_ioat_enqueue_copy()
+ * to begin the operations previously enqueued by rte_ioat_enqueue_copy()
*
* @param dev_id
* The rawdev device id of the ioat instance
*/
static inline void
-rte_ioat_do_copies(int dev_id);
+rte_ioat_perform_ops(int dev_id);
/**
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*
* If the hdls_disable option was not set when the device was configured,
* the function will return to the caller the user-provided "handles" for
@@ -104,11 +104,11 @@ rte_ioat_do_copies(int dev_id);
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param src_hdls
- * Array to hold the source handle parameters of the completed copies.
+ * Array to hold the source handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param dst_hdls
- * Array to hold the destination handle parameters of the completed copies.
+ * Array to hold the destination handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @return
@@ -117,7 +117,7 @@ rte_ioat_do_copies(int dev_id);
* to the src_hdls and dst_hdls array parameters.
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls);
/* include the implementation details from a separate file */
diff --git a/drivers/raw/ioat/rte_ioat_rawdev_fns.h b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
index 4b7bdb8e2..b155d79c4 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev_fns.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
@@ -83,10 +83,10 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
}
/*
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*/
static inline void
-rte_ioat_do_copies(int dev_id)
+rte_ioat_perform_ops(int dev_id)
{
struct rte_ioat_rawdev *ioat =
(struct rte_ioat_rawdev *)rte_rawdevs[dev_id].dev_private;
@@ -114,10 +114,10 @@ rte_ioat_get_last_completed(struct rte_ioat_rawdev *ioat, int *error)
}
/*
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls)
{
struct rte_ioat_rawdev *ioat =
@@ -165,4 +165,16 @@ rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
return count;
}
+static inline void
+__rte_deprecated_msg("use rte_ioat_perform_ops() instead")
+rte_ioat_do_copies(int dev_id) { rte_ioat_perform_ops(dev_id); }
+
+static inline int
+__rte_deprecated_msg("use rte_ioat_completed_ops() instead")
+rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+ uintptr_t *src_hdls, uintptr_t *dst_hdls)
+{
+ return rte_ioat_completed_ops(dev_id, max_copies, src_hdls, dst_hdls);
+}
+
#endif /* _RTE_IOAT_RAWDEV_FNS_H_ */
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index 288a75c7b..67f75737b 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -406,7 +406,7 @@ ioat_rx_port(struct rxtx_port_config *rx_config)
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -452,7 +452,7 @@ ioat_tx_port(struct rxtx_port_config *tx_config)
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h
index 8f487a563..2920255fc 100644
--- a/lib/librte_eal/include/rte_common.h
+++ b/lib/librte_eal/include/rte_common.h
@@ -85,6 +85,7 @@ typedef uint16_t unaligned_uint16_t;
/******* Macro to mark functions and fields scheduled for removal *****/
#define __rte_deprecated __attribute__((__deprecated__))
+#define __rte_deprecated_msg(msg) __attribute__((__deprecated__(msg)))
/**
* Mark a function or variable to a weak reference.
--
2.25.1
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH v4 07/25] raw/ioat: rename functions to be operation-agnostic
@ 2020-09-28 16:42 11% ` Bruce Richardson
0 siblings, 0 replies; 53+ results
From: Bruce Richardson @ 2020-09-28 16:42 UTC (permalink / raw)
To: dev; +Cc: patrick.fu, Bruce Richardson, Kevin Laatz
Since the hardware supported by the ioat driver is capable of operations
other than just copies, we can rename the doorbell and completion-return
functions to not have "copies" in their names. These functions are not
copy-specific, and so would apply for other operations which may be added
later to the driver.
Also add a suitable warning using deprecation attribute for any code using
the old functions names.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Kevin Laatz <kevin.laatz@intel.com>
---
Note: The checkpatches warning on this patch is a false positive due to
the addition of the new __rte_deprecated_msg macro in rte_common.h
---
doc/guides/rawdevs/ioat.rst | 16 ++++++++--------
doc/guides/rel_notes/release_20_11.rst | 9 +++++++++
doc/guides/sample_app_ug/ioat.rst | 8 ++++----
drivers/raw/ioat/ioat_rawdev_test.c | 12 ++++++------
drivers/raw/ioat/rte_ioat_rawdev.h | 14 +++++++-------
drivers/raw/ioat/rte_ioat_rawdev_fns.h | 20 ++++++++++++++++----
examples/ioat/ioatfwd.c | 4 ++--
lib/librte_eal/include/rte_common.h | 1 +
8 files changed, 53 insertions(+), 31 deletions(-)
diff --git a/doc/guides/rawdevs/ioat.rst b/doc/guides/rawdevs/ioat.rst
index af00d77fbf..3db5f5d097 100644
--- a/doc/guides/rawdevs/ioat.rst
+++ b/doc/guides/rawdevs/ioat.rst
@@ -157,9 +157,9 @@ Performing Data Copies
~~~~~~~~~~~~~~~~~~~~~~~
To perform data copies using IOAT rawdev devices, the functions
-``rte_ioat_enqueue_copy()`` and ``rte_ioat_do_copies()`` should be used.
+``rte_ioat_enqueue_copy()`` and ``rte_ioat_perform_ops()`` should be used.
Once copies have been completed, the completion will be reported back when
-the application calls ``rte_ioat_completed_copies()``.
+the application calls ``rte_ioat_completed_ops()``.
The ``rte_ioat_enqueue_copy()`` function enqueues a single copy to the
device ring for copying at a later point. The parameters to that function
@@ -172,11 +172,11 @@ pointers if packet data is being copied.
While the ``rte_ioat_enqueue_copy()`` function enqueues a copy operation on
the device ring, the copy will not actually be performed until after the
-application calls the ``rte_ioat_do_copies()`` function. This function
+application calls the ``rte_ioat_perform_ops()`` function. This function
informs the device hardware of the elements enqueued on the ring, and the
device will begin to process them. It is expected that, for efficiency
reasons, a burst of operations will be enqueued to the device via multiple
-enqueue calls between calls to the ``rte_ioat_do_copies()`` function.
+enqueue calls between calls to the ``rte_ioat_perform_ops()`` function.
The following code from ``test_ioat_rawdev.c`` demonstrates how to enqueue
a burst of copies to the device and start the hardware processing of them:
@@ -210,10 +210,10 @@ a burst of copies to the device and start the hardware processing of them:
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
To retrieve information about completed copies, the API
-``rte_ioat_completed_copies()`` should be used. This API will return to the
+``rte_ioat_completed_ops()`` should be used. This API will return to the
application a set of completion handles passed in when the relevant copies
were enqueued.
@@ -223,9 +223,9 @@ is correct before freeing the data buffers using the returned handles:
.. code-block:: C
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- printf("Error with rte_ioat_completed_copies\n");
+ printf("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 196209f63d..c99c0b33f5 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -83,6 +83,11 @@ New Features
The ioat rawdev driver has been updated and enhanced. Changes include:
* Added a per-device configuration flag to disable management of user-provided completion handles
+ * Renamed the ``rte_ioat_do_copies()`` API to ``rte_ioat_perform_ops()``,
+ and renamed the ``rte_ioat_completed_copies()`` API to ``rte_ioat_completed_ops()``
+ to better reflect the APIs' purposes, and remove the implication that
+ they are limited to copy operations only.
+ [Note: The old API is still provided but marked as deprecated in the code]
Removed Items
@@ -178,6 +183,10 @@ API Changes
* bpf: ``RTE_BPF_XTYPE_NUM`` has been dropped from ``rte_bpf_xtype``.
+* raw/ioat: As noted above, the ``rte_ioat_do_copies()`` and
+ ``rte_ioat_completed_copies()`` functions have been renamed to
+ ``rte_ioat_perform_ops()`` and ``rte_ioat_completed_ops()`` respectively.
+
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/ioat.rst b/doc/guides/sample_app_ug/ioat.rst
index 3f7d5c34a6..964160dff8 100644
--- a/doc/guides/sample_app_ug/ioat.rst
+++ b/doc/guides/sample_app_ug/ioat.rst
@@ -394,7 +394,7 @@ packet using ``pktmbuf_sw_copy()`` function and enqueue them to an rte_ring:
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -433,7 +433,7 @@ The packets are received in burst mode using ``rte_eth_rx_burst()``
function. When using hardware copy mode the packets are enqueued in
copying device's buffer using ``ioat_enqueue_packets()`` which calls
``rte_ioat_enqueue_copy()``. When all received packets are in the
-buffer the copy operations are started by calling ``rte_ioat_do_copies()``.
+buffer the copy operations are started by calling ``rte_ioat_perform_ops()``.
Function ``rte_ioat_enqueue_copy()`` operates on physical address of
the packet. Structure ``rte_mbuf`` contains only physical address to
start of the data buffer (``buf_iova``). Thus the address is adjusted
@@ -490,7 +490,7 @@ or indirect mbufs, then multiple copy operations must be used.
All completed copies are processed by ``ioat_tx_port()`` function. When using
-hardware copy mode the function invokes ``rte_ioat_completed_copies()``
+hardware copy mode the function invokes ``rte_ioat_completed_ops()``
on each assigned IOAT channel to gather copied packets. If software copy
mode is used the function dequeues copied packets from the rte_ring. Then each
packet MAC address is changed if it was enabled. After that copies are sent
@@ -510,7 +510,7 @@ in burst mode using `` rte_eth_tx_burst()``.
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/drivers/raw/ioat/ioat_rawdev_test.c b/drivers/raw/ioat/ioat_rawdev_test.c
index 8e7fd96afc..bb40eab6b7 100644
--- a/drivers/raw/ioat/ioat_rawdev_test.c
+++ b/drivers/raw/ioat/ioat_rawdev_test.c
@@ -62,12 +62,12 @@ test_enqueue_copies(int dev_id)
PRINT_ERR("Error with rte_ioat_enqueue_copy\n");
return -1;
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(10);
- if (rte_ioat_completed_copies(dev_id, 1, (void *)&completed[0],
+ if (rte_ioat_completed_ops(dev_id, 1, (void *)&completed[0],
(void *)&completed[1]) != 1) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
if (completed[0] != src || completed[1] != dst) {
@@ -116,12 +116,12 @@ test_enqueue_copies(int dev_id)
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(100);
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/drivers/raw/ioat/rte_ioat_rawdev.h b/drivers/raw/ioat/rte_ioat_rawdev.h
index 7067b352fc..5b2c47e8c8 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev.h
@@ -74,19 +74,19 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
int fence);
/**
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*
* This API is used to write the "doorbell" to the hardware to trigger it
- * to begin the copy operations previously enqueued by rte_ioat_enqueue_copy()
+ * to begin the operations previously enqueued by rte_ioat_enqueue_copy()
*
* @param dev_id
* The rawdev device id of the ioat instance
*/
static inline void
-rte_ioat_do_copies(int dev_id);
+rte_ioat_perform_ops(int dev_id);
/**
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*
* If the hdls_disable option was not set when the device was configured,
* the function will return to the caller the user-provided "handles" for
@@ -104,11 +104,11 @@ rte_ioat_do_copies(int dev_id);
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param src_hdls
- * Array to hold the source handle parameters of the completed copies.
+ * Array to hold the source handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param dst_hdls
- * Array to hold the destination handle parameters of the completed copies.
+ * Array to hold the destination handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @return
@@ -117,7 +117,7 @@ rte_ioat_do_copies(int dev_id);
* to the src_hdls and dst_hdls array parameters.
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls);
/* include the implementation details from a separate file */
diff --git a/drivers/raw/ioat/rte_ioat_rawdev_fns.h b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
index 4b7bdb8e23..b155d79c45 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev_fns.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
@@ -83,10 +83,10 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
}
/*
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*/
static inline void
-rte_ioat_do_copies(int dev_id)
+rte_ioat_perform_ops(int dev_id)
{
struct rte_ioat_rawdev *ioat =
(struct rte_ioat_rawdev *)rte_rawdevs[dev_id].dev_private;
@@ -114,10 +114,10 @@ rte_ioat_get_last_completed(struct rte_ioat_rawdev *ioat, int *error)
}
/*
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls)
{
struct rte_ioat_rawdev *ioat =
@@ -165,4 +165,16 @@ rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
return count;
}
+static inline void
+__rte_deprecated_msg("use rte_ioat_perform_ops() instead")
+rte_ioat_do_copies(int dev_id) { rte_ioat_perform_ops(dev_id); }
+
+static inline int
+__rte_deprecated_msg("use rte_ioat_completed_ops() instead")
+rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+ uintptr_t *src_hdls, uintptr_t *dst_hdls)
+{
+ return rte_ioat_completed_ops(dev_id, max_copies, src_hdls, dst_hdls);
+}
+
#endif /* _RTE_IOAT_RAWDEV_FNS_H_ */
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index 288a75c7b0..67f75737b6 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -406,7 +406,7 @@ ioat_rx_port(struct rxtx_port_config *rx_config)
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -452,7 +452,7 @@ ioat_tx_port(struct rxtx_port_config *tx_config)
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h
index 8f487a563d..2920255fc1 100644
--- a/lib/librte_eal/include/rte_common.h
+++ b/lib/librte_eal/include/rte_common.h
@@ -85,6 +85,7 @@ typedef uint16_t unaligned_uint16_t;
/******* Macro to mark functions and fields scheduled for removal *****/
#define __rte_deprecated __attribute__((__deprecated__))
+#define __rte_deprecated_msg(msg) __attribute__((__deprecated__(msg)))
/**
* Mark a function or variable to a weak reference.
--
2.25.1
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH v3 07/25] raw/ioat: rename functions to be operation-agnostic
@ 2020-09-25 11:08 11% ` Bruce Richardson
0 siblings, 0 replies; 53+ results
From: Bruce Richardson @ 2020-09-25 11:08 UTC (permalink / raw)
To: dev; +Cc: patrick.fu, Bruce Richardson, Kevin Laatz
Since the hardware supported by the ioat driver is capable of operations
other than just copies, we can rename the doorbell and completion-return
functions to not have "copies" in their names. These functions are not
copy-specific, and so would apply for other operations which may be added
later to the driver.
Also add a suitable warning using deprecation attribute for any code using
the old functions names.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Kevin Laatz <kevin.laatz@intel.com>
---
Note: The checkpatches warning on this patch is a false positive due to
the addition of the new __rte_deprecated_msg macro in rte_common.h
---
doc/guides/rawdevs/ioat.rst | 16 ++++++++--------
doc/guides/rel_notes/release_20_11.rst | 9 +++++++++
doc/guides/sample_app_ug/ioat.rst | 8 ++++----
drivers/raw/ioat/ioat_rawdev_test.c | 12 ++++++------
drivers/raw/ioat/rte_ioat_rawdev.h | 14 +++++++-------
drivers/raw/ioat/rte_ioat_rawdev_fns.h | 20 ++++++++++++++++----
examples/ioat/ioatfwd.c | 4 ++--
lib/librte_eal/include/rte_common.h | 1 +
8 files changed, 53 insertions(+), 31 deletions(-)
diff --git a/doc/guides/rawdevs/ioat.rst b/doc/guides/rawdevs/ioat.rst
index af00d77fb..3db5f5d09 100644
--- a/doc/guides/rawdevs/ioat.rst
+++ b/doc/guides/rawdevs/ioat.rst
@@ -157,9 +157,9 @@ Performing Data Copies
~~~~~~~~~~~~~~~~~~~~~~~
To perform data copies using IOAT rawdev devices, the functions
-``rte_ioat_enqueue_copy()`` and ``rte_ioat_do_copies()`` should be used.
+``rte_ioat_enqueue_copy()`` and ``rte_ioat_perform_ops()`` should be used.
Once copies have been completed, the completion will be reported back when
-the application calls ``rte_ioat_completed_copies()``.
+the application calls ``rte_ioat_completed_ops()``.
The ``rte_ioat_enqueue_copy()`` function enqueues a single copy to the
device ring for copying at a later point. The parameters to that function
@@ -172,11 +172,11 @@ pointers if packet data is being copied.
While the ``rte_ioat_enqueue_copy()`` function enqueues a copy operation on
the device ring, the copy will not actually be performed until after the
-application calls the ``rte_ioat_do_copies()`` function. This function
+application calls the ``rte_ioat_perform_ops()`` function. This function
informs the device hardware of the elements enqueued on the ring, and the
device will begin to process them. It is expected that, for efficiency
reasons, a burst of operations will be enqueued to the device via multiple
-enqueue calls between calls to the ``rte_ioat_do_copies()`` function.
+enqueue calls between calls to the ``rte_ioat_perform_ops()`` function.
The following code from ``test_ioat_rawdev.c`` demonstrates how to enqueue
a burst of copies to the device and start the hardware processing of them:
@@ -210,10 +210,10 @@ a burst of copies to the device and start the hardware processing of them:
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
To retrieve information about completed copies, the API
-``rte_ioat_completed_copies()`` should be used. This API will return to the
+``rte_ioat_completed_ops()`` should be used. This API will return to the
application a set of completion handles passed in when the relevant copies
were enqueued.
@@ -223,9 +223,9 @@ is correct before freeing the data buffers using the returned handles:
.. code-block:: C
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- printf("Error with rte_ioat_completed_copies\n");
+ printf("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 196209f63..c99c0b33f 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -83,6 +83,11 @@ New Features
The ioat rawdev driver has been updated and enhanced. Changes include:
* Added a per-device configuration flag to disable management of user-provided completion handles
+ * Renamed the ``rte_ioat_do_copies()`` API to ``rte_ioat_perform_ops()``,
+ and renamed the ``rte_ioat_completed_copies()`` API to ``rte_ioat_completed_ops()``
+ to better reflect the APIs' purposes, and remove the implication that
+ they are limited to copy operations only.
+ [Note: The old API is still provided but marked as deprecated in the code]
Removed Items
@@ -178,6 +183,10 @@ API Changes
* bpf: ``RTE_BPF_XTYPE_NUM`` has been dropped from ``rte_bpf_xtype``.
+* raw/ioat: As noted above, the ``rte_ioat_do_copies()`` and
+ ``rte_ioat_completed_copies()`` functions have been renamed to
+ ``rte_ioat_perform_ops()`` and ``rte_ioat_completed_ops()`` respectively.
+
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/ioat.rst b/doc/guides/sample_app_ug/ioat.rst
index 3f7d5c34a..964160dff 100644
--- a/doc/guides/sample_app_ug/ioat.rst
+++ b/doc/guides/sample_app_ug/ioat.rst
@@ -394,7 +394,7 @@ packet using ``pktmbuf_sw_copy()`` function and enqueue them to an rte_ring:
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -433,7 +433,7 @@ The packets are received in burst mode using ``rte_eth_rx_burst()``
function. When using hardware copy mode the packets are enqueued in
copying device's buffer using ``ioat_enqueue_packets()`` which calls
``rte_ioat_enqueue_copy()``. When all received packets are in the
-buffer the copy operations are started by calling ``rte_ioat_do_copies()``.
+buffer the copy operations are started by calling ``rte_ioat_perform_ops()``.
Function ``rte_ioat_enqueue_copy()`` operates on physical address of
the packet. Structure ``rte_mbuf`` contains only physical address to
start of the data buffer (``buf_iova``). Thus the address is adjusted
@@ -490,7 +490,7 @@ or indirect mbufs, then multiple copy operations must be used.
All completed copies are processed by ``ioat_tx_port()`` function. When using
-hardware copy mode the function invokes ``rte_ioat_completed_copies()``
+hardware copy mode the function invokes ``rte_ioat_completed_ops()``
on each assigned IOAT channel to gather copied packets. If software copy
mode is used the function dequeues copied packets from the rte_ring. Then each
packet MAC address is changed if it was enabled. After that copies are sent
@@ -510,7 +510,7 @@ in burst mode using `` rte_eth_tx_burst()``.
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/drivers/raw/ioat/ioat_rawdev_test.c b/drivers/raw/ioat/ioat_rawdev_test.c
index 8e7fd96af..bb40eab6b 100644
--- a/drivers/raw/ioat/ioat_rawdev_test.c
+++ b/drivers/raw/ioat/ioat_rawdev_test.c
@@ -62,12 +62,12 @@ test_enqueue_copies(int dev_id)
PRINT_ERR("Error with rte_ioat_enqueue_copy\n");
return -1;
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(10);
- if (rte_ioat_completed_copies(dev_id, 1, (void *)&completed[0],
+ if (rte_ioat_completed_ops(dev_id, 1, (void *)&completed[0],
(void *)&completed[1]) != 1) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
if (completed[0] != src || completed[1] != dst) {
@@ -116,12 +116,12 @@ test_enqueue_copies(int dev_id)
return -1;
}
}
- rte_ioat_do_copies(dev_id);
+ rte_ioat_perform_ops(dev_id);
usleep(100);
- if (rte_ioat_completed_copies(dev_id, 64, (void *)completed_src,
+ if (rte_ioat_completed_ops(dev_id, 64, (void *)completed_src,
(void *)completed_dst) != RTE_DIM(srcs)) {
- PRINT_ERR("Error with rte_ioat_completed_copies\n");
+ PRINT_ERR("Error with rte_ioat_completed_ops\n");
return -1;
}
for (i = 0; i < RTE_DIM(srcs); i++) {
diff --git a/drivers/raw/ioat/rte_ioat_rawdev.h b/drivers/raw/ioat/rte_ioat_rawdev.h
index 7067b352f..5b2c47e8c 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev.h
@@ -74,19 +74,19 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
int fence);
/**
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*
* This API is used to write the "doorbell" to the hardware to trigger it
- * to begin the copy operations previously enqueued by rte_ioat_enqueue_copy()
+ * to begin the operations previously enqueued by rte_ioat_enqueue_copy()
*
* @param dev_id
* The rawdev device id of the ioat instance
*/
static inline void
-rte_ioat_do_copies(int dev_id);
+rte_ioat_perform_ops(int dev_id);
/**
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*
* If the hdls_disable option was not set when the device was configured,
* the function will return to the caller the user-provided "handles" for
@@ -104,11 +104,11 @@ rte_ioat_do_copies(int dev_id);
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param src_hdls
- * Array to hold the source handle parameters of the completed copies.
+ * Array to hold the source handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @param dst_hdls
- * Array to hold the destination handle parameters of the completed copies.
+ * Array to hold the destination handle parameters of the completed ops.
* NOTE: If hdls_disable configuration option for the device is set, this
* parameter is ignored.
* @return
@@ -117,7 +117,7 @@ rte_ioat_do_copies(int dev_id);
* to the src_hdls and dst_hdls array parameters.
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls);
/* include the implementation details from a separate file */
diff --git a/drivers/raw/ioat/rte_ioat_rawdev_fns.h b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
index 4b7bdb8e2..b155d79c4 100644
--- a/drivers/raw/ioat/rte_ioat_rawdev_fns.h
+++ b/drivers/raw/ioat/rte_ioat_rawdev_fns.h
@@ -83,10 +83,10 @@ rte_ioat_enqueue_copy(int dev_id, phys_addr_t src, phys_addr_t dst,
}
/*
- * Trigger hardware to begin performing enqueued copy operations
+ * Trigger hardware to begin performing enqueued operations
*/
static inline void
-rte_ioat_do_copies(int dev_id)
+rte_ioat_perform_ops(int dev_id)
{
struct rte_ioat_rawdev *ioat =
(struct rte_ioat_rawdev *)rte_rawdevs[dev_id].dev_private;
@@ -114,10 +114,10 @@ rte_ioat_get_last_completed(struct rte_ioat_rawdev *ioat, int *error)
}
/*
- * Returns details of copy operations that have been completed
+ * Returns details of operations that have been completed
*/
static inline int
-rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+rte_ioat_completed_ops(int dev_id, uint8_t max_copies,
uintptr_t *src_hdls, uintptr_t *dst_hdls)
{
struct rte_ioat_rawdev *ioat =
@@ -165,4 +165,16 @@ rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
return count;
}
+static inline void
+__rte_deprecated_msg("use rte_ioat_perform_ops() instead")
+rte_ioat_do_copies(int dev_id) { rte_ioat_perform_ops(dev_id); }
+
+static inline int
+__rte_deprecated_msg("use rte_ioat_completed_ops() instead")
+rte_ioat_completed_copies(int dev_id, uint8_t max_copies,
+ uintptr_t *src_hdls, uintptr_t *dst_hdls)
+{
+ return rte_ioat_completed_ops(dev_id, max_copies, src_hdls, dst_hdls);
+}
+
#endif /* _RTE_IOAT_RAWDEV_FNS_H_ */
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index 288a75c7b..67f75737b 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -406,7 +406,7 @@ ioat_rx_port(struct rxtx_port_config *rx_config)
nb_enq = ioat_enqueue_packets(pkts_burst,
nb_rx, rx_config->ioat_ids[i]);
if (nb_enq > 0)
- rte_ioat_do_copies(rx_config->ioat_ids[i]);
+ rte_ioat_perform_ops(rx_config->ioat_ids[i]);
} else {
/* Perform packet software copy, free source packets */
int ret;
@@ -452,7 +452,7 @@ ioat_tx_port(struct rxtx_port_config *tx_config)
for (i = 0; i < tx_config->nb_queues; i++) {
if (copy_mode == COPY_MODE_IOAT_NUM) {
/* Deque the mbufs from IOAT device. */
- nb_dq = rte_ioat_completed_copies(
+ nb_dq = rte_ioat_completed_ops(
tx_config->ioat_ids[i], MAX_PKT_BURST,
(void *)mbufs_src, (void *)mbufs_dst);
} else {
diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h
index 8f487a563..2920255fc 100644
--- a/lib/librte_eal/include/rte_common.h
+++ b/lib/librte_eal/include/rte_common.h
@@ -85,6 +85,7 @@ typedef uint16_t unaligned_uint16_t;
/******* Macro to mark functions and fields scheduled for removal *****/
#define __rte_deprecated __attribute__((__deprecated__))
+#define __rte_deprecated_msg(msg) __attribute__((__deprecated__(msg)))
/**
* Mark a function or variable to a weak reference.
--
2.25.1
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH 0/7] raw/dpaa2_qdma: driver enhancement
2020-09-07 9:25 9% [dpdk-dev] [PATCH 0/7] raw/dpaa2_qdma: driver enhancement Gagandeep Singh
@ 2020-09-25 10:54 2% ` Hemant Agrawal
2020-10-15 9:47 9% ` [dpdk-dev] [PATCH v2 " Gagandeep Singh
1 sibling, 0 replies; 53+ results
From: Hemant Agrawal @ 2020-09-25 10:54 UTC (permalink / raw)
To: Gagandeep Singh, dev, nipun.gupta, hemant.agrawal
Series-
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
On 9/7/2020 2:55 PM, Gagandeep Singh wrote:
> In this patchset, we have done some changes in dpaa2_qdma driver
> related to rawdev APIs, optimizations, scatter-gather support on TX,
> enqueue without wait.
>
> Gagandeep Singh (2):
> raw/dpaa2_qdma: change DPAA2 QDMA APIs to rawdev ops
> raw/dpaa2_qdma: memset to only required memory
>
> Jun Yang (5):
> raw/dpaa2_qdma: refactor the code
> raw/dpaa2_qdma: optimize IOVA conversion
> raw/dpaa2_qdma: support scatter gather in enqueue
> raw/dpaa2_qdma: support FLE pool per queue
> raw/dpaa2_qdma: support enqueue without response wait
>
> drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 18 +-
> drivers/raw/dpaa2_qdma/dpaa2_qdma.c | 1824 ++++++++++++++++-----------
> drivers/raw/dpaa2_qdma/dpaa2_qdma.h | 128 +-
> drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h | 231 +---
> 4 files changed, 1257 insertions(+), 944 deletions(-)
>
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v3 0/7] Enhance rawdev APIs
2020-09-10 14:36 16% ` [dpdk-dev] [PATCH v3 " Bruce Richardson
@ 2020-09-11 9:56 8% ` Thomas Monjalon
0 siblings, 0 replies; 53+ results
From: Thomas Monjalon @ 2020-09-11 9:56 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
Bruce Richardson <bruce.richardson@intel.com> wrote:
> This patchset proposes some internal and externally-visible changes to the
> rawdev API, the ABI change of which were previously announced.
>
> The changes are in two main areas:
> * For any APIs which take a void * parameter for driver-specific structs,
>
> add an additional parameter to provide the struct length. This allows
> some runtime type-checking, as well as possible ABI-compatibility support
> in the future as structure change generally involve a change in the size
> of the structure.
>
> * Ensure all APIs which can return error values have int type, rather than
>
> void. Since functions like info_get and queue_default_get can now do some
> typechecking, they need to be modified to allow them to return error
> codes on failure.
>
> V3:
> - fix doxygen error
> - add release note update for changes to public APIs
>
> V2:
> - add additional patch to make start/stop functions optional
> - remove deprecation notice once changes applied
Applied, thanks
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v2 0/3] simplify unit-testing of rawdevs
@ 2020-09-10 16:47 13% ` Bruce Richardson
0 siblings, 0 replies; 53+ results
From: Bruce Richardson @ 2020-09-10 16:47 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
At present the "rawdev_autotest" command creates a skeleton rawdev and runs
a series of tests on the rawdev API and on that rawdev. While the rawdev
API set includes a "selftest" function, it is not hooked up to this test so
to test an individual rawdev driver, e.g. ioat, requires that a new test
command be added.
This patchset improves the situation by changing the UT to first run the
existing API tests, but then call selftest on all rawdevs on the system.
This removes the need for any new test commands for new drivers. If there
are multiple rawdevs on a system, the sub-set to be tested can be limited
via existing means such as using the device block/allow EAL parameters or
similarly via vdev args, etc.
As part of this change, the ioat rawdev autotest is fixed to allow calling
on multiple instances inside the one test run, and thereafter the custom
test command for it is removed as it is no longer necessary.
Depends-on: series-12105 ("Enhance rawdev APIs")
V2:
- dropped patch 2, which had ioat-only changes to debug prints, and wasn't
relevant to the rest of the set
- improved the naming of the test functions in test_rawdev.c
- added release note entry for these changes
Bruce Richardson (3):
raw/ioat: support multiple devices being tested
app/test: change rawdev autotest to run selftest on all devs
app/test: remove ioat-specific autotest
app/test/test_rawdev.c | 34 +++++++++++++++++---------
doc/guides/rel_notes/release_20_11.rst | 7 ++++++
drivers/raw/ioat/ioat_rawdev_test.c | 17 ++++++++++---
3 files changed, 42 insertions(+), 16 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH v3 0/7] Enhance rawdev APIs
2020-07-09 15:20 15% [dpdk-dev] [PATCH 20.11 0/5] Enhance rawdev APIs Bruce Richardson
2020-08-13 11:27 16% ` [dpdk-dev] [PATCH v2 0/7] " Bruce Richardson
@ 2020-09-10 14:36 16% ` Bruce Richardson
2020-09-11 9:56 8% ` Thomas Monjalon
1 sibling, 1 reply; 53+ results
From: Bruce Richardson @ 2020-09-10 14:36 UTC (permalink / raw)
To: dev; +Cc: thomas, Bruce Richardson
This patchset proposes some internal and externally-visible changes to the
rawdev API, the ABI change of which were previously announced.
The changes are in two main areas:
* For any APIs which take a void * parameter for driver-specific structs,
add an additional parameter to provide the struct length. This allows
some runtime type-checking, as well as possible ABI-compatibility support
in the future as structure change generally involve a change in the size
of the structure.
* Ensure all APIs which can return error values have int type, rather than
void. Since functions like info_get and queue_default_get can now do some
typechecking, they need to be modified to allow them to return error
codes on failure.
V3:
- fix doxygen error
- add release note update for changes to public APIs
V2:
- add additional patch to make start/stop functions optional
- remove deprecation notice once changes applied
Bruce Richardson (7):
rawdev: add private data length parameter to info fn
rawdev: allow drivers to return error from info function
rawdev: add private data length parameter to config fn
rawdev: add private data length parameter to queue fns
rawdev: allow queue config query to return error
rawdev: mark start and stop functions optional
doc: remove rawdev deprecation notice
app/test/test_rawdev.c | 2 +-
doc/guides/rawdevs/ioat.rst | 4 +-
doc/guides/rawdevs/octeontx2_dma.rst | 2 +-
doc/guides/rawdevs/octeontx2_ep.rst | 3 +-
doc/guides/rel_notes/deprecation.rst | 7 ---
doc/guides/rel_notes/release_20_11.rst | 9 ++++
doc/guides/sample_app_ug/ioat.rst | 4 +-
drivers/bus/ifpga/ifpga_bus.c | 2 +-
drivers/raw/ifpga/ifpga_rawdev.c | 23 +++++-----
drivers/raw/ioat/ioat_rawdev.c | 17 ++++---
drivers/raw/ioat/ioat_rawdev_test.c | 6 +--
drivers/raw/ntb/ntb.c | 49 ++++++++++++++++-----
drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c | 7 +--
drivers/raw/octeontx2_dma/otx2_dpi_test.c | 3 +-
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 7 +--
drivers/raw/octeontx2_ep/otx2_ep_test.c | 2 +-
drivers/raw/skeleton/skeleton_rawdev.c | 36 +++++++++------
drivers/raw/skeleton/skeleton_rawdev_test.c | 32 ++++++++------
examples/ioat/ioatfwd.c | 4 +-
examples/ntb/ntb_fwd.c | 7 +--
lib/librte_rawdev/rte_rawdev.c | 47 +++++++++++++-------
lib/librte_rawdev/rte_rawdev.h | 27 ++++++++++--
lib/librte_rawdev/rte_rawdev_pmd.h | 22 ++++++---
23 files changed, 210 insertions(+), 112 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 16%]
* Re: [dpdk-dev] [PATCH v2 0/7] Enhance rawdev APIs
2020-08-13 11:27 16% ` [dpdk-dev] [PATCH v2 0/7] " Bruce Richardson
2020-09-02 11:21 8% ` Nipun Gupta
@ 2020-09-09 9:47 8% ` Thomas Monjalon
1 sibling, 0 replies; 53+ results
From: Thomas Monjalon @ 2020-09-09 9:47 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Nipun Gupta, Hemant Agrawal, dev
> app/test/test_rawdev.c | 2 +-
> doc/guides/rawdevs/ioat.rst | 4 +-
> doc/guides/rawdevs/octeontx2_dma.rst | 2 +-
> doc/guides/rawdevs/octeontx2_ep.rst | 3 +-
> doc/guides/rel_notes/deprecation.rst | 7 ---
> doc/guides/sample_app_ug/ioat.rst | 4 +-
> drivers/bus/ifpga/ifpga_bus.c | 2 +-
> drivers/raw/ifpga/ifpga_rawdev.c | 23 +++++-----
> drivers/raw/ioat/ioat_rawdev.c | 17 ++++---
> drivers/raw/ioat/ioat_rawdev_test.c | 6 +--
> drivers/raw/ntb/ntb.c | 49 ++++++++++++++++-----
> drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c | 7 +--
> drivers/raw/octeontx2_dma/otx2_dpi_test.c | 3 +-
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 7 +--
> drivers/raw/octeontx2_ep/otx2_ep_test.c | 2 +-
> drivers/raw/skeleton/skeleton_rawdev.c | 36 +++++++++------
> drivers/raw/skeleton/skeleton_rawdev_test.c | 32 ++++++++------
> examples/ioat/ioatfwd.c | 4 +-
> examples/ntb/ntb_fwd.c | 7 +--
> lib/librte_rawdev/rte_rawdev.c | 47 +++++++++++++-------
> lib/librte_rawdev/rte_rawdev.h | 27 ++++++++++--
> lib/librte_rawdev/rte_rawdev_pmd.h | 22 ++++++---
> 22 files changed, 201 insertions(+), 112 deletions(-)
It is missing updates of the release notes in each patch changing the API.
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH 0/7] raw/dpaa2_qdma: driver enhancement
@ 2020-09-07 9:25 9% Gagandeep Singh
2020-09-25 10:54 2% ` Hemant Agrawal
2020-10-15 9:47 9% ` [dpdk-dev] [PATCH v2 " Gagandeep Singh
0 siblings, 2 replies; 53+ results
From: Gagandeep Singh @ 2020-09-07 9:25 UTC (permalink / raw)
To: dev, nipun.gupta, hemant.agrawal; +Cc: thomas.monjalon, Gagandeep Singh
In this patchset, we have done some changes in dpaa2_qdma driver
related to rawdev APIs, optimizations, scatter-gather support on TX,
enqueue without wait.
Gagandeep Singh (2):
raw/dpaa2_qdma: change DPAA2 QDMA APIs to rawdev ops
raw/dpaa2_qdma: memset to only required memory
Jun Yang (5):
raw/dpaa2_qdma: refactor the code
raw/dpaa2_qdma: optimize IOVA conversion
raw/dpaa2_qdma: support scatter gather in enqueue
raw/dpaa2_qdma: support FLE pool per queue
raw/dpaa2_qdma: support enqueue without response wait
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 18 +-
drivers/raw/dpaa2_qdma/dpaa2_qdma.c | 1824 ++++++++++++++++-----------
drivers/raw/dpaa2_qdma/dpaa2_qdma.h | 128 +-
drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h | 231 +---
4 files changed, 1257 insertions(+), 944 deletions(-)
--
2.7.4
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v2 0/7] Enhance rawdev APIs
2020-08-13 11:27 16% ` [dpdk-dev] [PATCH v2 0/7] " Bruce Richardson
@ 2020-09-02 11:21 8% ` Nipun Gupta
2020-09-09 9:47 8% ` Thomas Monjalon
1 sibling, 0 replies; 53+ results
From: Nipun Gupta @ 2020-09-02 11:21 UTC (permalink / raw)
To: Bruce Richardson, Hemant Agrawal; +Cc: dev
Series
Acked-by: Nipun Gupta <nipun.gupta@nxp.com>
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Thursday, August 13, 2020 4:58 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>
> Cc: dev@dpdk.org; Bruce Richardson <bruce.richardson@intel.com>
> Subject: [PATCH v2 0/7] Enhance rawdev APIs
>
> This patchset proposes some internal and externally-visible changes to the
> rawdev API, the ABI change of which were previously announced.
>
> The changes are in two main areas:
> * For any APIs which take a void * parameter for driver-specific structs,
> add an additional parameter to provide the struct length. This allows
> some runtime type-checking, as well as possible ABI-compatibility support
> in the future as structure change generally involve a change in the size
> of the structure.
> * Ensure all APIs which can return error values have int type, rather than
> void. Since functions like info_get and queue_default_get can now do some
> typechecking, they need to be modified to allow them to return error
> codes on failure.
>
> V2:
> - add additional patch to make start/stop functions optional
> - remove deprecation notice once changes applied
>
> Bruce Richardson (7):
> rawdev: add private data length parameter to info fn
> rawdev: allow drivers to return error from info function
> rawdev: add private data length parameter to config fn
> rawdev: add private data length parameter to queue fns
> rawdev: allow queue default config query to return error
> rawdev: mark start and stop functions optional
> doc: remove rawdev deprecation notice
>
> app/test/test_rawdev.c | 2 +-
> doc/guides/rawdevs/ioat.rst | 4 +-
> doc/guides/rawdevs/octeontx2_dma.rst | 2 +-
> doc/guides/rawdevs/octeontx2_ep.rst | 3 +-
> doc/guides/rel_notes/deprecation.rst | 7 ---
> doc/guides/sample_app_ug/ioat.rst | 4 +-
> drivers/bus/ifpga/ifpga_bus.c | 2 +-
> drivers/raw/ifpga/ifpga_rawdev.c | 23 +++++-----
> drivers/raw/ioat/ioat_rawdev.c | 17 ++++---
> drivers/raw/ioat/ioat_rawdev_test.c | 6 +--
> drivers/raw/ntb/ntb.c | 49 ++++++++++++++++-----
> drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c | 7 +--
> drivers/raw/octeontx2_dma/otx2_dpi_test.c | 3 +-
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 7 +--
> drivers/raw/octeontx2_ep/otx2_ep_test.c | 2 +-
> drivers/raw/skeleton/skeleton_rawdev.c | 36 +++++++++------
> drivers/raw/skeleton/skeleton_rawdev_test.c | 32 ++++++++------
> examples/ioat/ioatfwd.c | 4 +-
> examples/ntb/ntb_fwd.c | 7 +--
> lib/librte_rawdev/rte_rawdev.c | 47 +++++++++++++-------
> lib/librte_rawdev/rte_rawdev.h | 27 ++++++++++--
> lib/librte_rawdev/rte_rawdev_pmd.h | 22 ++++++---
> 22 files changed, 201 insertions(+), 112 deletions(-)
>
> --
> 2.25.1
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v2 0/7] Enhance rawdev APIs
2020-07-09 15:20 15% [dpdk-dev] [PATCH 20.11 0/5] Enhance rawdev APIs Bruce Richardson
@ 2020-08-13 11:27 16% ` Bruce Richardson
2020-09-02 11:21 8% ` Nipun Gupta
2020-09-09 9:47 8% ` Thomas Monjalon
2020-09-10 14:36 16% ` [dpdk-dev] [PATCH v3 " Bruce Richardson
1 sibling, 2 replies; 53+ results
From: Bruce Richardson @ 2020-08-13 11:27 UTC (permalink / raw)
To: Nipun Gupta, Hemant Agrawal; +Cc: dev, Bruce Richardson
This patchset proposes some internal and externally-visible changes to the
rawdev API, the ABI change of which were previously announced.
The changes are in two main areas:
* For any APIs which take a void * parameter for driver-specific structs,
add an additional parameter to provide the struct length. This allows
some runtime type-checking, as well as possible ABI-compatibility support
in the future as structure change generally involve a change in the size
of the structure.
* Ensure all APIs which can return error values have int type, rather than
void. Since functions like info_get and queue_default_get can now do some
typechecking, they need to be modified to allow them to return error
codes on failure.
V2:
- add additional patch to make start/stop functions optional
- remove deprecation notice once changes applied
Bruce Richardson (7):
rawdev: add private data length parameter to info fn
rawdev: allow drivers to return error from info function
rawdev: add private data length parameter to config fn
rawdev: add private data length parameter to queue fns
rawdev: allow queue default config query to return error
rawdev: mark start and stop functions optional
doc: remove rawdev deprecation notice
app/test/test_rawdev.c | 2 +-
doc/guides/rawdevs/ioat.rst | 4 +-
doc/guides/rawdevs/octeontx2_dma.rst | 2 +-
doc/guides/rawdevs/octeontx2_ep.rst | 3 +-
doc/guides/rel_notes/deprecation.rst | 7 ---
doc/guides/sample_app_ug/ioat.rst | 4 +-
drivers/bus/ifpga/ifpga_bus.c | 2 +-
drivers/raw/ifpga/ifpga_rawdev.c | 23 +++++-----
drivers/raw/ioat/ioat_rawdev.c | 17 ++++---
drivers/raw/ioat/ioat_rawdev_test.c | 6 +--
drivers/raw/ntb/ntb.c | 49 ++++++++++++++++-----
drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c | 7 +--
drivers/raw/octeontx2_dma/otx2_dpi_test.c | 3 +-
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 7 +--
drivers/raw/octeontx2_ep/otx2_ep_test.c | 2 +-
drivers/raw/skeleton/skeleton_rawdev.c | 36 +++++++++------
drivers/raw/skeleton/skeleton_rawdev_test.c | 32 ++++++++------
examples/ioat/ioatfwd.c | 4 +-
examples/ntb/ntb_fwd.c | 7 +--
lib/librte_rawdev/rte_rawdev.c | 47 +++++++++++++-------
lib/librte_rawdev/rte_rawdev.h | 27 ++++++++++--
lib/librte_rawdev/rte_rawdev_pmd.h | 22 ++++++---
22 files changed, 201 insertions(+), 112 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 16%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
2020-08-06 0:59 2% ` Stephen Hemminger
@ 2020-08-06 16:57 0% ` Jerin Jacob
0 siblings, 0 replies; 53+ results
From: Jerin Jacob @ 2020-08-06 16:57 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Kinsella, Ray, Bruce Richardson, Pavan Nikhilesh, Jerin Jacob,
Neil Horman, John McNamara, Marko Kovacevic, dpdk-dev,
Thomas Monjalon, David Marchand
On Thu, Aug 6, 2020 at 6:29 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 5 Aug 2020 14:40:01 +0530
> Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> > On Wed, Aug 5, 2020 at 2:16 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
> > >
> > >
> > >
> > > On 04/08/2020 17:20, Stephen Hemminger wrote:
> > > > On Tue, 4 Aug 2020 11:41:53 +0100
> > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > >
> > > >> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
> > > >>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > > >>>
> > > >>> Add 64 byte padding at the end of event device public structure to allow
> > > >>> future extensions.
> > > >>>
> > > >>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > > >>> Acked-by: Jerin Jacob <jerinj@marvell.com>
> > > >>> ---
> > > >>> v2 Changes:
> > > >>> - Modify commit title.
> > > >>> - Add patch reference to doc.
> > > >>>
> > > >>> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > > >>> 1 file changed, 11 insertions(+)
> > > >>>
> > > >>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > > >>> index ea4cfa7a4..ec5db68e9 100644
> > > >>> --- a/doc/guides/rel_notes/deprecation.rst
> > > >>> +++ b/doc/guides/rel_notes/deprecation.rst
> > > >>> @@ -151,3 +151,14 @@ Deprecation Notices
> > > >>> Python 2 support will be completely removed in 20.11.
> > > >>> In 20.08, explicit deprecation warnings will be displayed when running
> > > >>> scripts with Python 2.
> > > >>> +
> > > >>> +* eventdev: A 64 byte padding is added at the end of the following structures
> > > >>> + in event device library to support future extensions:
> > > >>> + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > > >>> + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
> > > >>> + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > > >>> + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
> > > >>> + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > > >>> + ``rte_event_timer_adapter_data``.
> > > >>> + Reference:
> > > >>> + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > > >>> --
> > > >>
> > > >> I don't like this idea of adding lots of padding to the ends of these
> > > >> structures. For some structures, such as the public arrays for devices it
> > > >> may be necessary, but for all the conf structures passed as parameters to
> > > >> functions I think we can do better. Since these structures are passed by
> > > >> the user to various functions, function versioning can be used to ensure
> > > >> that the correct function in eventdev is always called. From there to the
> > > >> individual PMDs, we can implement ABI compatibility by either:
> > > >> 1. including the length of the struct as a parameter to the driver. (This is
> > > >> a bit similar to my proposal for rawdev [1])
> > > >> 2. including the ABI version as a parameter to the driver.
> > > >>
> > > >> Regards
> > > >> /Bruce
> > > >>
> > > >> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
> > > >
> > > > This is a bad idea.
> > > >
> > > > Reserved fields won't work because nothing requires that the application
> > > > zero them. You can't start using them later because the application
> > > > may put uninitialized or junk data there.
> > > >
> > >
> > > +1, to Stephens comments.
> >
> > Since the problem is not specific to one substem, if we need to add a
> > field in config structures,
> > What will the expected way of handling across the DPDK?
>
> If you need fields go through the normal enhancement process, and get it
> reviewed and put them in a major release milestone.
> Sorry, there is no free lunch by adding reserved fields.
>
> Look up YAGNI
YAGNI is useful. But If we need to wait for one year to change the API
then it is the problem.
That's time frame silicon companies are making the next generation of
silicon nowadays.
We just tried to follow the existing scheme of things in the codebase[1].
But I am also not a great fan of the Reserved filed scheme either.
Probably it is better to add the new feature as a new API or config
structure with
out breaking anything(as experimental) and upcoming next release, rework to
adapt to subsystem API philosophy.
[1]
lib/librte_ethdev/rte_ethdev.h: uint64_t reserved_64s[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: void *reserved_ptrs[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: uint64_t reserved_64s[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: void *reserved_ptrs[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: uint64_t reserved_64s[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: void *reserved_ptrs[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: uint64_t reserved_64s[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: void *reserved_ptrs[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: uint64_t reserved_64s[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev.h: void *reserved_ptrs[2]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev_core.h: uint64_t reserved_64s[4]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev_core.h: void *reserved_ptrs[4]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev_core.h: uint64_t reserved_64s[4]; /**<
Reserved for future fields */
lib/librte_ethdev/rte_ethdev_core.h: void *reserved_ptrs[4]; /**<
Reserved for future fields */
lib/librte_eal/linux/eal_timer.c: uint64_t reserved0;
/**< Reserved for future use. */
lib/librte_eal/linux/eal_timer.c: uint64_t reserved1;
/**< Reserved for future use. */
lib/librte_eal/linux/eal_timer.c: uint64_t reserved2[25];
/**< Reserved for future use. */
lib/librte_eal/linux/eal_timer.c: uint64_t reserved3;
/**< Reserved for future use. */
lib/librte_eal/linux/eal_timer.c: uint64_t reserved4;
/**< Reserved for future use. */
lib/librte_eventdev/rte_eventdev.h: /**< Reserved
for future use */
lib/librte_eventdev/rte_eventdev.h: uint64_t reserved_64s[4]; /**<
Reserved for future fields */
lib/librte_eventdev/rte_eventdev.h: void *reserved_ptrs[4]; /**<
Reserved for future fields */
lib/librte_eventdev/rte_eventdev.h: uint64_t reserved_64s[4]; /**<
Reserved for future fields */
lib/librte_eventdev/rte_eventdev.h: void *reserved_ptrs[4]; /**<
Reserved for future fields */
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
2020-08-05 9:10 0% ` Jerin Jacob
@ 2020-08-06 0:59 2% ` Stephen Hemminger
2020-08-06 16:57 0% ` Jerin Jacob
0 siblings, 1 reply; 53+ results
From: Stephen Hemminger @ 2020-08-06 0:59 UTC (permalink / raw)
To: Jerin Jacob
Cc: Kinsella, Ray, Bruce Richardson, Pavan Nikhilesh, Jerin Jacob,
Neil Horman, John McNamara, Marko Kovacevic, dpdk-dev,
Thomas Monjalon, David Marchand
On Wed, 5 Aug 2020 14:40:01 +0530
Jerin Jacob <jerinjacobk@gmail.com> wrote:
> On Wed, Aug 5, 2020 at 2:16 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
> >
> >
> >
> > On 04/08/2020 17:20, Stephen Hemminger wrote:
> > > On Tue, 4 Aug 2020 11:41:53 +0100
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > >
> > >> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
> > >>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > >>>
> > >>> Add 64 byte padding at the end of event device public structure to allow
> > >>> future extensions.
> > >>>
> > >>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > >>> Acked-by: Jerin Jacob <jerinj@marvell.com>
> > >>> ---
> > >>> v2 Changes:
> > >>> - Modify commit title.
> > >>> - Add patch reference to doc.
> > >>>
> > >>> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > >>> 1 file changed, 11 insertions(+)
> > >>>
> > >>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > >>> index ea4cfa7a4..ec5db68e9 100644
> > >>> --- a/doc/guides/rel_notes/deprecation.rst
> > >>> +++ b/doc/guides/rel_notes/deprecation.rst
> > >>> @@ -151,3 +151,14 @@ Deprecation Notices
> > >>> Python 2 support will be completely removed in 20.11.
> > >>> In 20.08, explicit deprecation warnings will be displayed when running
> > >>> scripts with Python 2.
> > >>> +
> > >>> +* eventdev: A 64 byte padding is added at the end of the following structures
> > >>> + in event device library to support future extensions:
> > >>> + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > >>> + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
> > >>> + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > >>> + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
> > >>> + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > >>> + ``rte_event_timer_adapter_data``.
> > >>> + Reference:
> > >>> + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > >>> --
> > >>
> > >> I don't like this idea of adding lots of padding to the ends of these
> > >> structures. For some structures, such as the public arrays for devices it
> > >> may be necessary, but for all the conf structures passed as parameters to
> > >> functions I think we can do better. Since these structures are passed by
> > >> the user to various functions, function versioning can be used to ensure
> > >> that the correct function in eventdev is always called. From there to the
> > >> individual PMDs, we can implement ABI compatibility by either:
> > >> 1. including the length of the struct as a parameter to the driver. (This is
> > >> a bit similar to my proposal for rawdev [1])
> > >> 2. including the ABI version as a parameter to the driver.
> > >>
> > >> Regards
> > >> /Bruce
> > >>
> > >> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
> > >
> > > This is a bad idea.
> > >
> > > Reserved fields won't work because nothing requires that the application
> > > zero them. You can't start using them later because the application
> > > may put uninitialized or junk data there.
> > >
> >
> > +1, to Stephens comments.
>
> Since the problem is not specific to one substem, if we need to add a
> field in config structures,
> What will the expected way of handling across the DPDK?
If you need fields go through the normal enhancement process, and get it
reviewed and put them in a major release milestone.
Sorry, there is no free lunch by adding reserved fields.
Look up YAGNI
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
2020-08-05 8:46 0% ` Kinsella, Ray
@ 2020-08-05 9:10 0% ` Jerin Jacob
2020-08-06 0:59 2% ` Stephen Hemminger
0 siblings, 1 reply; 53+ results
From: Jerin Jacob @ 2020-08-05 9:10 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Stephen Hemminger, Bruce Richardson, Pavan Nikhilesh,
Jerin Jacob, Neil Horman, John McNamara, Marko Kovacevic,
dpdk-dev, Thomas Monjalon, David Marchand
On Wed, Aug 5, 2020 at 2:16 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
>
>
>
> On 04/08/2020 17:20, Stephen Hemminger wrote:
> > On Tue, 4 Aug 2020 11:41:53 +0100
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> >> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
> >>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>>
> >>> Add 64 byte padding at the end of event device public structure to allow
> >>> future extensions.
> >>>
> >>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>> Acked-by: Jerin Jacob <jerinj@marvell.com>
> >>> ---
> >>> v2 Changes:
> >>> - Modify commit title.
> >>> - Add patch reference to doc.
> >>>
> >>> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> >>> 1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> >>> index ea4cfa7a4..ec5db68e9 100644
> >>> --- a/doc/guides/rel_notes/deprecation.rst
> >>> +++ b/doc/guides/rel_notes/deprecation.rst
> >>> @@ -151,3 +151,14 @@ Deprecation Notices
> >>> Python 2 support will be completely removed in 20.11.
> >>> In 20.08, explicit deprecation warnings will be displayed when running
> >>> scripts with Python 2.
> >>> +
> >>> +* eventdev: A 64 byte padding is added at the end of the following structures
> >>> + in event device library to support future extensions:
> >>> + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> >>> + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
> >>> + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> >>> + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
> >>> + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> >>> + ``rte_event_timer_adapter_data``.
> >>> + Reference:
> >>> + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> >>> --
> >>
> >> I don't like this idea of adding lots of padding to the ends of these
> >> structures. For some structures, such as the public arrays for devices it
> >> may be necessary, but for all the conf structures passed as parameters to
> >> functions I think we can do better. Since these structures are passed by
> >> the user to various functions, function versioning can be used to ensure
> >> that the correct function in eventdev is always called. From there to the
> >> individual PMDs, we can implement ABI compatibility by either:
> >> 1. including the length of the struct as a parameter to the driver. (This is
> >> a bit similar to my proposal for rawdev [1])
> >> 2. including the ABI version as a parameter to the driver.
> >>
> >> Regards
> >> /Bruce
> >>
> >> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
> >
> > This is a bad idea.
> >
> > Reserved fields won't work because nothing requires that the application
> > zero them. You can't start using them later because the application
> > may put uninitialized or junk data there.
> >
>
> +1, to Stephens comments.
Since the problem is not specific to one substem, if we need to add a
field in config structures,
What will the expected way of handling across the DPDK?
How about
1) Public init functions to clear the params?
2) Different struct version for specific functions like
http://mails.dpdk.org/archives/dev/2020-August/177357.html
Or any other scheme in mind?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
2020-08-04 16:20 0% ` Stephen Hemminger
@ 2020-08-05 8:46 0% ` Kinsella, Ray
2020-08-05 9:10 0% ` Jerin Jacob
0 siblings, 1 reply; 53+ results
From: Kinsella, Ray @ 2020-08-05 8:46 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: pbhagavatula, jerinj, Neil Horman, John McNamara,
Marko Kovacevic, dev, thomas, david.marchand
On 04/08/2020 17:20, Stephen Hemminger wrote:
> On Tue, 4 Aug 2020 11:41:53 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
>>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>>
>>> Add 64 byte padding at the end of event device public structure to allow
>>> future extensions.
>>>
>>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>> Acked-by: Jerin Jacob <jerinj@marvell.com>
>>> ---
>>> v2 Changes:
>>> - Modify commit title.
>>> - Add patch reference to doc.
>>>
>>> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>>> index ea4cfa7a4..ec5db68e9 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -151,3 +151,14 @@ Deprecation Notices
>>> Python 2 support will be completely removed in 20.11.
>>> In 20.08, explicit deprecation warnings will be displayed when running
>>> scripts with Python 2.
>>> +
>>> +* eventdev: A 64 byte padding is added at the end of the following structures
>>> + in event device library to support future extensions:
>>> + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
>>> + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
>>> + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
>>> + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
>>> + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
>>> + ``rte_event_timer_adapter_data``.
>>> + Reference:
>>> + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
>>> --
>>
>> I don't like this idea of adding lots of padding to the ends of these
>> structures. For some structures, such as the public arrays for devices it
>> may be necessary, but for all the conf structures passed as parameters to
>> functions I think we can do better. Since these structures are passed by
>> the user to various functions, function versioning can be used to ensure
>> that the correct function in eventdev is always called. From there to the
>> individual PMDs, we can implement ABI compatibility by either:
>> 1. including the length of the struct as a parameter to the driver. (This is
>> a bit similar to my proposal for rawdev [1])
>> 2. including the ABI version as a parameter to the driver.
>>
>> Regards
>> /Bruce
>>
>> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
>
> This is a bad idea.
>
> Reserved fields won't work because nothing requires that the application
> zero them. You can't start using them later because the application
> may put uninitialized or junk data there.
>
+1, to Stephens comments.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
2020-08-04 10:41 8% ` Bruce Richardson
2020-08-04 11:37 0% ` Jerin Jacob
@ 2020-08-04 16:20 0% ` Stephen Hemminger
2020-08-05 8:46 0% ` Kinsella, Ray
1 sibling, 1 reply; 53+ results
From: Stephen Hemminger @ 2020-08-04 16:20 UTC (permalink / raw)
To: Bruce Richardson
Cc: pbhagavatula, jerinj, Ray Kinsella, Neil Horman, John McNamara,
Marko Kovacevic, dev, thomas, david.marchand
On Tue, 4 Aug 2020 11:41:53 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
> > From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >
> > Add 64 byte padding at the end of event device public structure to allow
> > future extensions.
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > Acked-by: Jerin Jacob <jerinj@marvell.com>
> > ---
> > v2 Changes:
> > - Modify commit title.
> > - Add patch reference to doc.
> >
> > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index ea4cfa7a4..ec5db68e9 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -151,3 +151,14 @@ Deprecation Notices
> > Python 2 support will be completely removed in 20.11.
> > In 20.08, explicit deprecation warnings will be displayed when running
> > scripts with Python 2.
> > +
> > +* eventdev: A 64 byte padding is added at the end of the following structures
> > + in event device library to support future extensions:
> > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
> > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
> > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > + ``rte_event_timer_adapter_data``.
> > + Reference:
> > + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > --
>
> I don't like this idea of adding lots of padding to the ends of these
> structures. For some structures, such as the public arrays for devices it
> may be necessary, but for all the conf structures passed as parameters to
> functions I think we can do better. Since these structures are passed by
> the user to various functions, function versioning can be used to ensure
> that the correct function in eventdev is always called. From there to the
> individual PMDs, we can implement ABI compatibility by either:
> 1. including the length of the struct as a parameter to the driver. (This is
> a bit similar to my proposal for rawdev [1])
> 2. including the ABI version as a parameter to the driver.
>
> Regards
> /Bruce
>
> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
This is a bad idea.
Reserved fields won't work because nothing requires that the application
zero them. You can't start using them later because the application
may put uninitialized or junk data there.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
2020-08-04 10:41 8% ` Bruce Richardson
@ 2020-08-04 11:37 0% ` Jerin Jacob
2020-08-04 16:20 0% ` Stephen Hemminger
1 sibling, 0 replies; 53+ results
From: Jerin Jacob @ 2020-08-04 11:37 UTC (permalink / raw)
To: Bruce Richardson
Cc: Pavan Nikhilesh, Jerin Jacob, Ray Kinsella, Neil Horman,
John McNamara, Marko Kovacevic, dpdk-dev, Thomas Monjalon,
David Marchand
On Tue, Aug 4, 2020 at 4:12 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
> > From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >
> > Add 64 byte padding at the end of event device public structure to allow
> > future extensions.
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > Acked-by: Jerin Jacob <jerinj@marvell.com>
> > ---
> > v2 Changes:
> > - Modify commit title.
> > - Add patch reference to doc.
> >
> > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index ea4cfa7a4..ec5db68e9 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -151,3 +151,14 @@ Deprecation Notices
> > Python 2 support will be completely removed in 20.11.
> > In 20.08, explicit deprecation warnings will be displayed when running
> > scripts with Python 2.
> > +
> > +* eventdev: A 64 byte padding is added at the end of the following structures
> > + in event device library to support future extensions:
> > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
> > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
> > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > + ``rte_event_timer_adapter_data``.
> > + Reference:
> > + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > --
>
> I don't like this idea of adding lots of padding to the ends of these
> structures. For some structures, such as the public arrays for devices it
> may be necessary, but for all the conf structures passed as parameters to
> functions I think we can do better. Since these structures are passed by
> the user to various functions, function versioning can be used to ensure
> that the correct function in eventdev is always called. From there to the
> individual PMDs, we can implement ABI compatibility by either:
> 1. including the length of the struct as a parameter to the driver. (This is
> a bit similar to my proposal for rawdev [1])
> 2. including the ABI version as a parameter to the driver.
But, Will the above solution work if the application is dependent on
struct size?
i.e change of s1 size will change offset of s3 i.e
app_sepecific_struct_s3. Right?
i.e DPDK version should not change the offset of s3. Right?
example,
struct app_struct {
struct dpdk_public_struct_s1 s1;
struct dpdk_public_struct_s2 s2;
struct app_sepecific_struct_s3 s3;
}
>
> Regards
> /Bruce
>
> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
@ 2020-08-04 10:41 8% ` Bruce Richardson
2020-08-04 11:37 0% ` Jerin Jacob
2020-08-04 16:20 0% ` Stephen Hemminger
0 siblings, 2 replies; 53+ results
From: Bruce Richardson @ 2020-08-04 10:41 UTC (permalink / raw)
To: pbhagavatula
Cc: jerinj, Ray Kinsella, Neil Horman, John McNamara,
Marko Kovacevic, dev, thomas, david.marchand
On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Add 64 byte padding at the end of event device public structure to allow
> future extensions.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> Acked-by: Jerin Jacob <jerinj@marvell.com>
> ---
> v2 Changes:
> - Modify commit title.
> - Add patch reference to doc.
>
> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7a4..ec5db68e9 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -151,3 +151,14 @@ Deprecation Notices
> Python 2 support will be completely removed in 20.11.
> In 20.08, explicit deprecation warnings will be displayed when running
> scripts with Python 2.
> +
> +* eventdev: A 64 byte padding is added at the end of the following structures
> + in event device library to support future extensions:
> + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``,
> + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``,
> + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> + ``rte_event_timer_adapter_data``.
> + Reference:
> + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> --
I don't like this idea of adding lots of padding to the ends of these
structures. For some structures, such as the public arrays for devices it
may be necessary, but for all the conf structures passed as parameters to
functions I think we can do better. Since these structures are passed by
the user to various functions, function versioning can be used to ensure
that the correct function in eventdev is always called. From there to the
individual PMDs, we can implement ABI compatibility by either:
1. including the length of the struct as a parameter to the driver. (This is
a bit similar to my proposal for rawdev [1])
2. including the ABI version as a parameter to the driver.
Regards
/Bruce
[1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH 20.11 0/5] Enhance rawdev APIs
@ 2020-07-09 15:20 15% Bruce Richardson
2020-08-13 11:27 16% ` [dpdk-dev] [PATCH v2 0/7] " Bruce Richardson
2020-09-10 14:36 16% ` [dpdk-dev] [PATCH v3 " Bruce Richardson
0 siblings, 2 replies; 53+ results
From: Bruce Richardson @ 2020-07-09 15:20 UTC (permalink / raw)
To: Nipun Gupta, Hemant Agrawal
Cc: dev, Rosen Xu, Tianfei zhang, Xiaoyun Li, Jingjing Wu, Satha Rao,
Mahipal Challa, Jerin Jacob, Bruce Richardson
This patchset proposes some internal and externally-visible changes to the
rawdev API. If consensus is in favour, I will submit a deprecation notice
for the changes for the 20.08 release, so that these ABI/API-breaking
changes can be merged in 20.11
The changes are in two areas:
* For any APIs which take a void * parameter for driver-specific structs,
add an additional parameter to provide the struct length. This allows
some runtime type-checking, as well as possible ABI-compatibility support
in the future as structure change generally involve a change in the size
of the structure.
* Ensure all APIs which can return error values have int type, rather than
void. Since functions like info_get and queue_default_get can now do some
typechecking, they need to be modified to allow them to return error
codes on failure.
Bruce Richardson (5):
rawdev: add private data length parameter to info fn
rawdev: allow drivers to return error from info function
rawdev: add private data length parameter to config fn
rawdev: add private data length parameter to queue fns
rawdev: allow queue default config query to return error
drivers/bus/ifpga/ifpga_bus.c | 2 +-
drivers/raw/ifpga/ifpga_rawdev.c | 23 +++++-----
drivers/raw/ioat/ioat_rawdev.c | 17 ++++---
drivers/raw/ioat/ioat_rawdev_test.c | 6 +--
drivers/raw/ntb/ntb.c | 49 ++++++++++++++++-----
drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c | 7 +--
drivers/raw/octeontx2_dma/otx2_dpi_test.c | 3 +-
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 7 +--
drivers/raw/octeontx2_ep/otx2_ep_test.c | 2 +-
drivers/raw/skeleton/skeleton_rawdev.c | 34 ++++++++------
drivers/raw/skeleton/skeleton_rawdev_test.c | 32 ++++++++------
examples/ioat/ioatfwd.c | 4 +-
examples/ntb/ntb_fwd.c | 7 +--
lib/librte_rawdev/rte_rawdev.c | 27 +++++++-----
lib/librte_rawdev/rte_rawdev.h | 27 ++++++++++--
lib/librte_rawdev/rte_rawdev_pmd.h | 22 ++++++---
16 files changed, 178 insertions(+), 91 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v2 4/4] drivers/octeontx2: enhancing mbox APIs to get response
@ 2019-11-27 10:22 7% ` Sunil Kumar Kori
0 siblings, 0 replies; 53+ results
From: Sunil Kumar Kori @ 2019-11-27 10:22 UTC (permalink / raw)
To: Jerin Jacob, Nithin Dabilpuram, Vamsi Attunuru, Kiran Kumar K, Satha Rao
Cc: dev, Sunil Kumar Kori
Based on thread context, mbox API will get response for submitted
request. If thread runs in interrupt context then it uses polling
based get response API otherwise interrupt based.
Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
---
v2:
- Included Makefile and meson build changes.
- Rebased patch on 19.11-rc4
drivers/common/octeontx2/otx2_dev.c | 27 ++++++++++++---------------
drivers/common/octeontx2/otx2_mbox.h | 21 +++++++++++++++++----
drivers/net/octeontx2/Makefile | 2 ++
drivers/net/octeontx2/meson.build | 2 ++
drivers/raw/octeontx2_dma/Makefile | 2 ++
drivers/raw/octeontx2_dma/meson.build | 2 ++
6 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/common/octeontx2/otx2_dev.c b/drivers/common/octeontx2/otx2_dev.c
index 6f29d6108..d61c712fa 100644
--- a/drivers/common/octeontx2/otx2_dev.c
+++ b/drivers/common/octeontx2/otx2_dev.c
@@ -577,17 +577,16 @@ otx2_pf_vf_mbox_irq(void *param)
intr = otx2_read64(dev->bar2 + RVU_VF_INT);
if (intr == 0)
- return;
+ otx2_base_dbg("Proceeding to check mbox UP messages if any");
otx2_write64(intr, dev->bar2 + RVU_VF_INT);
otx2_base_dbg("Irq 0x%" PRIx64 "(pf:%d,vf:%d)", intr, dev->pf, dev->vf);
- if (intr) {
- /* First process all configuration messages */
- otx2_process_msgs(dev, dev->mbox);
- /* Process Uplink messages */
- otx2_process_msgs_up(dev, &dev->mbox_up);
- }
+ /* First process all configuration messages */
+ otx2_process_msgs(dev, dev->mbox);
+
+ /* Process Uplink messages */
+ otx2_process_msgs_up(dev, &dev->mbox_up);
}
static void
@@ -598,18 +597,16 @@ otx2_af_pf_mbox_irq(void *param)
intr = otx2_read64(dev->bar2 + RVU_PF_INT);
if (intr == 0)
- return;
+ otx2_base_dbg("Proceeding to check mbox UP messages if any");
otx2_write64(intr, dev->bar2 + RVU_PF_INT);
-
otx2_base_dbg("Irq 0x%" PRIx64 "(pf:%d,vf:%d)", intr, dev->pf, dev->vf);
- if (intr) {
- /* First process all configuration messages */
- otx2_process_msgs(dev, dev->mbox);
- /* Process Uplink messages */
- otx2_process_msgs_up(dev, &dev->mbox_up);
- }
+ /* First process all configuration messages */
+ otx2_process_msgs(dev, dev->mbox);
+
+ /* Process Uplink messages */
+ otx2_process_msgs_up(dev, &dev->mbox_up);
}
static int
diff --git a/drivers/common/octeontx2/otx2_mbox.h b/drivers/common/octeontx2/otx2_mbox.h
index 237d4cf45..e82dfe530 100644
--- a/drivers/common/octeontx2/otx2_mbox.h
+++ b/drivers/common/octeontx2/otx2_mbox.h
@@ -9,6 +9,7 @@
#include <stdbool.h>
#include <rte_ether.h>
+#include <rte_interrupts.h>
#include <rte_spinlock.h>
#include <otx2_common.h>
@@ -1627,28 +1628,40 @@ static inline int
otx2_mbox_process(struct otx2_mbox *mbox)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp(mbox, 0, NULL);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll(mbox, 0, NULL);
+ else
+ return otx2_mbox_get_rsp(mbox, 0, NULL);
}
static inline int
otx2_mbox_process_msg(struct otx2_mbox *mbox, void **msg)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp(mbox, 0, msg);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll(mbox, 0, msg);
+ else
+ return otx2_mbox_get_rsp(mbox, 0, msg);
}
static inline int
otx2_mbox_process_tmo(struct otx2_mbox *mbox, uint32_t tmo)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp_tmo(mbox, 0, NULL, tmo);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll_tmo(mbox, 0, NULL, tmo);
+ else
+ return otx2_mbox_get_rsp_tmo(mbox, 0, NULL, tmo);
}
static inline int
otx2_mbox_process_msg_tmo(struct otx2_mbox *mbox, void **msg, uint32_t tmo)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp_tmo(mbox, 0, msg, tmo);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll_tmo(mbox, 0, msg, tmo);
+ else
+ return otx2_mbox_get_rsp_tmo(mbox, 0, msg, tmo);
}
int otx2_send_ready_msg(struct otx2_mbox *mbox, uint16_t *pf_func /* out */);
diff --git a/drivers/net/octeontx2/Makefile b/drivers/net/octeontx2/Makefile
index 68f5765db..3da4d8cc1 100644
--- a/drivers/net/octeontx2/Makefile
+++ b/drivers/net/octeontx2/Makefile
@@ -26,6 +26,8 @@ CFLAGS += -diag-disable 2259
endif
endif
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+
EXPORT_MAP := rte_pmd_octeontx2_version.map
#
diff --git a/drivers/net/octeontx2/meson.build b/drivers/net/octeontx2/meson.build
index fad3076a3..a976a2c19 100644
--- a/drivers/net/octeontx2/meson.build
+++ b/drivers/net/octeontx2/meson.build
@@ -24,6 +24,8 @@ sources = files('otx2_rx.c',
'otx2_ethdev_devargs.c'
)
+allow_experimental_apis = true
+
deps += ['bus_pci', 'common_octeontx2', 'mempool_octeontx2']
cflags += ['-flax-vector-conversions']
diff --git a/drivers/raw/octeontx2_dma/Makefile b/drivers/raw/octeontx2_dma/Makefile
index c64ca3497..0d0c530fe 100644
--- a/drivers/raw/octeontx2_dma/Makefile
+++ b/drivers/raw/octeontx2_dma/Makefile
@@ -22,6 +22,8 @@ CFLAGS += -diag-disable 2259
endif
endif
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+
EXPORT_MAP := rte_rawdev_octeontx2_dma_version.map
#
diff --git a/drivers/raw/octeontx2_dma/meson.build b/drivers/raw/octeontx2_dma/meson.build
index 11f74680a..f8f88aa7e 100644
--- a/drivers/raw/octeontx2_dma/meson.build
+++ b/drivers/raw/octeontx2_dma/meson.build
@@ -5,6 +5,8 @@
deps += ['bus_pci', 'common_octeontx2', 'rawdev']
sources = files('otx2_dpi_rawdev.c', 'otx2_dpi_msg.c', 'otx2_dpi_test.c')
+allow_experimental_apis = true
+
extra_flags = []
# This integrated controller runs only on a arm64 machine, remove 32bit warnings
if not dpdk_conf.get('RTE_ARCH_64')
--
2.17.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 4% [dpdk-dev] [PATCH v2 1/2] " John McNamara
@ 2019-04-26 15:14 4% ` John McNamara
0 siblings, 0 replies; 53+ results
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/compressdevs/overview.rst | 2 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/cryptodevs/aesni_mb.rst | 2 +-
doc/guides/cryptodevs/overview.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 2 +-
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/howto/lm_bond_virtio_sriov.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 ++--
doc/guides/howto/rte_flow.rst | 6 ++---
doc/guides/howto/telemetry.rst | 2 +-
.../howto/virtio_user_as_exceptional_path.rst | 8 +++----
doc/guides/nics/af_packet.rst | 4 ++--
doc/guides/nics/atlantic.rst | 2 +-
doc/guides/nics/cxgbe.rst | 4 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/dpaa2.rst | 2 +-
doc/guides/nics/ena.rst | 2 +-
doc/guides/nics/enetc.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 2 +-
doc/guides/nics/ixgbe.rst | 4 ++--
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/mlx5.rst | 4 ++--
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.rst | 2 +-
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/nfp.rst | 4 ++--
doc/guides/nics/sfc_efx.rst | 14 +++++------
doc/guides/nics/szedata2.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/platform/dpaa.rst | 4 ++--
doc/guides/platform/dpaa2.rst | 4 ++--
doc/guides/prog_guide/bbdev.rst | 4 ++--
doc/guides/prog_guide/compressdev.rst | 6 ++---
doc/guides/prog_guide/cryptodev_lib.rst | 12 +++++-----
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/efd_lib.rst | 2 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
.../prog_guide/event_ethernet_rx_adapter.rst | 6 ++---
doc/guides/prog_guide/eventdev.rst | 6 ++---
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++-------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 2 +-
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 ++--
doc/guides/prog_guide/rte_flow.rst | 8 +++----
doc/guides/prog_guide/rte_security.rst | 20 ++++++++--------
doc/guides/prog_guide/traffic_management.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 2 +-
doc/guides/rawdevs/ifpga_rawdev.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 8 +++----
doc/guides/rel_notes/release_17_11.rst | 10 ++++----
doc/guides/sample_app_ug/bbdev_app.rst | 4 ++--
doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 2 +-
doc/guides/sample_app_ug/ip_pipeline.rst | 4 ++--
doc/guides/sample_app_ug/ipsec_secgw.rst | 8 +++----
doc/guides/sample_app_ug/performance_thread.rst | 4 ++--
doc/guides/sample_app_ug/qos_metering.rst | 2 +-
doc/guides/sample_app_ug/test_pipeline.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 4 ++--
doc/guides/sample_app_ug/vhost_scsi.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 10 ++++----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++---------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
71 files changed, 170 insertions(+), 170 deletions(-)
diff --git a/doc/guides/compressdevs/overview.rst b/doc/guides/compressdevs/overview.rst
index 70bbe82..809e4e6 100644
--- a/doc/guides/compressdevs/overview.rst
+++ b/doc/guides/compressdevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
without making any modifications to it (no compression done).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means PMD supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e6..3b2b174 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -8,7 +8,7 @@ Contributing Code to DPDK
This document outlines the guidelines for submitting code to DPDK.
-The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
`How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 8915201..1eff2b0 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -129,7 +129,7 @@ Extra notes
For AES Counter mode (AES-CTR), the library supports two different sizes for Initialization
Vector (IV):
-* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, which internally
+* 12 bytes: used mainly for IPsec, as it requires 12 bytes from the user, which internally
are appended the counter block (4 bytes), which is set to 1 for the first block
(no padding required from the user)
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index 12f342b..a972c79 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
being the operation in-place (input address = output address).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means pmd supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index a754a27..7004ca4 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -165,7 +165,7 @@ operation:
For pure small packet size (64 bytes) traffic however the multi-core mode is not
an optimal solution, as it doesn't give significant per-core performance improvement.
For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
- For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+ For large packets (1.5 kbytes) scheduler shows linear scaling in performance
up to eight cores.
Each worker uses its own slave cryptodev. Only software cryptodevs
are supported. Only the same type of cryptodevs should be used concurrently.
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
index 0262a33..979f6cd 100644
--- a/doc/guides/eventdevs/opdl.rst
+++ b/doc/guides/eventdevs/opdl.rst
@@ -8,7 +8,7 @@ The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
implementation of the eventdev API. It is particularly suited to packet\
processing workloads that have high throughput and low latency requirements.\
All packets follow the same path through the device. The order in which\
-packets follow is determinted by the order in which queues are set up.\
+packets follow is determined by the order in which queues are set up.\
Events are left on the ring until they are transmitted. As a result packets\
do not go out of order
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index afdcad7..04c8b03 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -70,7 +70,7 @@ Credit Quanta
The credit quanta is the number of credits that a port will fetch at a time from
the instance's credit pool. Higher numbers will cause less overhead in the
atomic credit fetch code, however it also reduces the overall number of credits
-in the system faster. A balanced number (eg 32) ensures that only small numbers
+in the system faster. A balanced number (e.g. 32) ensures that only small numbers
of credits are pre-allocated at a time, while also mitigating performance impact
of the atomics.
@@ -100,7 +100,7 @@ feature would be significant.
~~~~~~~~~~~~~~~~~~
The software eventdev does not support creating queues that handle all types of
-traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
+traffic. An eventdev with this capability allows enqueuing Atomic, Ordered and
Parallel traffic to the same queue, but scheduling each of them appropriately.
The reason to not allow Atomic, Ordered and Parallel event types in the
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index ee8ccda..07563b3 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -328,7 +328,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
testpmd> show bonding config 2
testpmd> port attach 0000:00:04.0
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 6ebc10f..ecb7832 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -243,7 +243,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
Virtio traffic is seen at P0 and P1.
@@ -338,7 +338,7 @@ reset_vf_on_212_131.sh
#!/bin/sh
# This script is run on the host 10.237.212.131 to reset SRIOV
- # BDF for Ninatic NIC is 0000:06:00.0
+ # BDF for Niantic NIC is 0000:06:00.0
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
echo 0 > /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 3dcda6c..e197376 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -23,7 +23,7 @@ In this example we will create a simple rule that drops packets whose IPv4
destination equals 192.168.3.2. This code is equivalent to the following
testpmd command (wrapped for clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst is 192.168.3.2 / end actions drop / end
Code
@@ -118,7 +118,7 @@ a mask.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 /
end actions drop / end
@@ -219,7 +219,7 @@ In this example we will create a rule that routes all vlan id 123 to queue 3.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
+ testpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
end actions queue index 3 / end
Code
diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst
index 00f8f7a..e10804d 100644
--- a/doc/guides/howto/telemetry.rst
+++ b/doc/guides/howto/telemetry.rst
@@ -18,7 +18,7 @@ which acts as the client.
In DPDK, applications are used to initialize the ``telemetry``. To view incoming
traffic on featured ports, the application should be run first (ie. after ports
are configured). Once the application is running, the service assurance agent
-(for example the collectd plugin) should be run to begin querying the API.
+(for example the CollectD plugin) should be run to begin querying the API.
A client connects their Service Assurance application to the DPDK application
via a UNIX socket. Once a connection is established, a client can send JSON
diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst
index 4910c12..ec021af 100644
--- a/doc/guides/howto/virtio_user_as_exceptional_path.rst
+++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2016 Intel Corporation.
-.. _virtio_user_as_excpetional_path:
+.. _virtio_user_as_exceptional_path:
Virtio_user as Exceptional Path
===============================
@@ -22,7 +22,7 @@ solution is very promising in:
* Features
vhost-net is born to be a networking solution, which has lots of networking
- related featuers, like multi queue, tso, multi-seg mbuf, etc.
+ related features, like multi queue, tso, multi-seg mbuf, etc.
* Performance
@@ -38,7 +38,7 @@ in :numref:`figure_virtio_user_as_exceptional_path`.
.. figure:: img/virtio_user_as_exceptional_path.*
- Overview of a DPDK app using virtio-user as excpetional path
+ Overview of a DPDK app using virtio-user as exceptional path
Sample Usage
@@ -75,7 +75,7 @@ compiling the kernel and those kernel modules should be inserted.
* ``queues``
- Number of multi-queues. Each qeueue will be served by a kthread. For example:
+ Number of multi-queues. Each queue will be served by a kthread. For example:
.. code-block:: console
diff --git a/doc/guides/nics/af_packet.rst b/doc/guides/nics/af_packet.rst
index 1260bb2..efd6f1c 100644
--- a/doc/guides/nics/af_packet.rst
+++ b/doc/guides/nics/af_packet.rst
@@ -13,13 +13,13 @@ PACKET_MMAP, which provides a mmap'ed ring buffer, shared between user space
and kernel, that's used to send and receive packets. This helps reducing system
calls and the copies needed between user space and Kernel.
-The PACKET_FANOUT_HASH behaviour of AF_PACKET is used for frame reception.
+The PACKET_FANOUT_HASH behavior of AF_PACKET is used for frame reception.
Options and inherent limitations
--------------------------------
The following options can be provided to set up an af_packet port in DPDK.
-Some of these, in turn, will be used to configure the PAKET_MMAP settings.
+Some of these, in turn, will be used to configure the PACKET_MMAP settings.
* ``iface`` - name of the Kernel interface to attach to (required);
* ``qpairs`` - number of Rx and Tx queues (optional, default 1);
diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst
index 22f2410..3f3f294 100644
--- a/doc/guides/nics/atlantic.rst
+++ b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
- Port statistics
- RSS (Receive Side Scaling)
- Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
- MACSEC offload
Experimental API features
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index f3e6115..7a893cc 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -126,7 +126,7 @@ enabling debugging options may affect system performance.
- ``CONFIG_RTE_LIBRTE_CXGBE_TPUT`` (default **y**)
- Toggle behaviour to prefer Throughput or Latency.
+ Toggle behavior to prefer Throughput or Latency.
Runtime Options
~~~~~~~~~~~~~~~
@@ -140,7 +140,7 @@ be passed as part of EAL arguments. For example,
- ``keep_ovlan`` (default **0**)
- Toggle behaviour to keep/strip outer VLAN in Q-in-Q packets. If
+ Toggle behavior to keep/strip outer VLAN in Q-in-Q packets. If
enabled, the outer VLAN tag is preserved in Q-in-Q packets. Otherwise,
the outer VLAN tag is stripped in Q-in-Q packets.
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index fb7bc7d..2243a4a 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -251,7 +251,7 @@ state during application initialization:
automatically be assigned from the these high perf PUSH queues. Any queue
configuration beyond that will be standard Rx queues. The application can
choose to change their number if HW portals are limited.
- The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ The valid values are from '0' to '4'. The values shall be set to '0' if the
application want to use eventdev with DPAA device.
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index d74d8f8..b3b7678 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -379,7 +379,7 @@ active -- Ethernet, crypto, compression, etc.
DPBP based Mempool driver
~~~~~~~~~~~~~~~~~~~~~~~~~
-The DPBP driver is bound to a DPBP objects and provides sevices to
+The DPBP driver is bound to a DPBP objects and provides services to
create a hardware offloaded packet buffer mempool.
DPAA2 NIC Driver
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 80da4b6..d44f3cd 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -189,7 +189,7 @@ Prerequisites
reduces the latency of the packets by pushing the header directly through
the PCI to the device, before the DMA is even triggered. For proper work
kernel PCI driver must support write combining (WC). In mainline version of
- ``igb_uio`` (in DPDK repo) it must be enabled by loding module with
+ ``igb_uio`` (in DPDK repo) it must be enabled by loading module with
``wc_activate=1`` flag (example below). However, mainline's vfio-pci
driver in kernel doesn't have WC support yet (planed to be added).
If vfio-pci used user should be either turn off ENAv2 (to avoid performance
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 2620460..3c896ee 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -76,7 +76,7 @@ Supported ENETC SoCs
Prerequisites
~~~~~~~~~~~~~
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 726a69e..cdb55e0 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -224,7 +224,7 @@ the use of SR-IOV.
passthrough devices do not require libvirt, port profiles, and VM-FEX.
-.. _enic-genic-flow-api:
+.. _enic-generic-flow-api:
Generic Flow API support
------------------------
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c5bf322..d57ddc2 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -495,7 +495,7 @@ Supports adding traffic mirroring rules.
Inline crypto
-------------
-Supports inline crypto processing (eg. inline IPsec). See Security library and PMD documentation for more details.
+Supports inline crypto processing (e.g. inline IPsec). See Security library and PMD documentation for more details.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_SECURITY``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 9680a92..2e9ec79 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -580,7 +580,7 @@ bandwidth setting.
TC TX scheduling mode setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There're 2 TX scheduling modes for TCs, round robin and strict priority mode.
+There are 2 TX scheduling modes for TCs, round robin and strict priority mode.
If a TC is set to strict priority mode, it can consume unlimited bandwidth.
It means if APP has set the max bandwidth for that TC, it comes to no
effect.
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1c294b0..975143f 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -203,8 +203,8 @@ as a workaround.
X550 does not support legacy interrupt mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Desccription
-^^^^^^^^^^^^
+Description
+^^^^^^^^^^^
X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy
interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states
that the Interrupt Status bit is not implemented. The errata is the item #22
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index a66c595..602a06b 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -65,7 +65,7 @@ backend device by default.
PMD arguments
-------------
-``no_request_thread``, by default PMD creates a phtread for each KNI interface
+``no_request_thread``, by default PMD creates a pthread for each KNI interface
to handle Linux network interface control commands, like ``ifconfig kni0 up``
With ``no_request_thread`` option, pthread is not created and control commands
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index aaf1907..f6d7a16 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -83,7 +83,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx4**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx4**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5fa6b62..af1e408 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,7 +168,7 @@ Limitations
- must specify the VXLAN item with tunnel outer parameters.
- must specify the tunnel outer VNI in the VXLAN item.
- must specify the tunnel outer remote (destination) UDP port in the VXLAN item.
- - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed.
+ - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interface, wildcards not allowed.
- must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed.
- must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule.
@@ -216,7 +216,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx5**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx5**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 09e2f2a..bacc013 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -91,7 +91,7 @@ Limitations
chance to start in a sane state.
- MUSDK architecture does not support changing configuration in run time.
- All nessesary configurations should be done before first dev_start().
+ All necessary configurations should be done before first dev_start().
- RX queue start/stop is not supported.
diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 87fabf5..6dbb9a5 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -89,7 +89,7 @@ operations:
.. Note::
- The dpkd-devbind.py script can not be used since it only handles PCI devices.
+ The dpdk-devbind.py script can not be used since it only handles PCI devices.
Prerequisites
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index a7fb963..8df76c0 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -81,7 +81,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They are represented in DPDK as a single port.
-NFB-200G2QL card employs an addon cable which allows to connect it to two
+NFB-200G2QL card employs an add-on cable which allows to connect it to two
physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 09a8529..309fa5d 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -149,8 +149,8 @@ PF multiprocess support
-----------------------
Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary proceses with PF
-ports is limitted to only one.
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
This limitation will be solved in future versions but having basic multiprocess support
is important for allowing development and debugging through the PF using a secondary
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index eb47f25..6d01d05 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -96,7 +96,7 @@ Non-supported Features
The features not yet supported include:
-- Receive queue interupts
+- Receive queue interrupts
- Priority-based flow control
@@ -209,12 +209,12 @@ Validating flow rules depends on the firmware variant.
The :ref:`flow_isolated_mode` is supported.
-Ethernet destinaton individual/group match
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ethernet destination individual/group match
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet item supports I/G matching, if only the corresponding bit is set
-in the mask of destination address. If destinaton address in the spec is
-multicast, it matches all multicast (and broadcast) packets, oherwise it
+in the mask of destination address. If destination address in the spec is
+multicast, it matches all multicast (and broadcast) packets, otherwise it
matches unicast packets that are not filtered by other flow rules.
Exceptions to flow rules
@@ -348,10 +348,10 @@ boolean parameters value.
- ``perf_profile`` [auto|throughput|low-latency] (default **throughput**)
- Choose hardware tunning to be optimized for either throughput or
+ Choose hardware tuning to be optimized for either throughput or
low-latency.
**auto** allows NIC firmware to make a choice based on
- installed licences and firmware variant configured using **sfboot**.
+ installed licenses and firmware variant configured using **sfboot**.
- ``stats_update_period_ms`` [long] (default **1000**)
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index a2092f9..94dba82 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -89,7 +89,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They were historically represented in DPDK as a single port.
-However, the new NFB-200G2QL card employs an addon cable which allows to connect
+However, the new NFB-200G2QL card employs an add-on cable which allows to connect
it to two physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 063bd0b..4b6d77d 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -40,7 +40,7 @@ actual MAC address: ``00:64:74:61:70:[00-FF]``.
--vdev=net_tap0,mac="00:64:74:61:70:11"
The MAC address will have a user value passed as string. The MAC address is in
-format with delimeter ``:``. The string is byte converted to hex and you get
+format with delimiter ``:``. The string is byte converted to hex and you get
the actual MAC address: ``00:64:74:61:70:11``.
It is possible to specify a remote netdevice to capture packets from by adding
diff --git a/doc/guides/platform/dpaa.rst b/doc/guides/platform/dpaa.rst
index 3904871..6005f22 100644
--- a/doc/guides/platform/dpaa.rst
+++ b/doc/guides/platform/dpaa.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA Board Support Package
====================================
-This doc has information about steps to setup QorIq dpaa
+This doc has information about steps to setup QorIQ dpaa
based layerscape platform and information about common offload
hw block drivers of **NXP QorIQ DPAA** SoC family.
@@ -38,7 +38,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA PMD on a DPAA
+There are four main pre-requisites for executing DPAA PMD on a DPAA
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/platform/dpaa2.rst b/doc/guides/platform/dpaa2.rst
index 5a64406..2586af0 100644
--- a/doc/guides/platform/dpaa2.rst
+++ b/doc/guides/platform/dpaa2.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA2 Board Support Package
=====================================
-This doc has information about steps to setup NXP QoriQ DPAA2 platform
+This doc has information about steps to setup NXP QorIQ DPAA2 platform
and information about common offload hw block drivers of
**NXP QorIQ DPAA2** SoC family.
@@ -48,7 +48,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA2 PMD on a DPAA2
+There are four main pre-requisites for executing DPAA2 PMD on a DPAA2
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9de1444..658ffd4 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev device consists of
one or more queues identified by queue IDs. While different devices may have
different capabilities (e.g. support different operation types), all queues on
a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initializations time.
+for only one type of operation and is configured at initialization time.
When an operation is enqueued to a specific queue ID, the result is dequeued
from the same queue ID.
@@ -678,7 +678,7 @@ bbdev framework, by giving a sample code performing a loop-back operation with a
baseband processor capable of transceiving data packets.
The following sample C-like pseudo-code shows the basic steps to encode several
-buffers using (**sw_trubo**) bbdev PMD.
+buffers using (**sw_turbo**) bbdev PMD.
.. code-block:: c
diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst
index ad97037..a06c835 100644
--- a/doc/guides/prog_guide/compressdev.rst
+++ b/doc/guides/prog_guide/compressdev.rst
@@ -17,7 +17,7 @@ Device Creation
Physical compression devices are discovered during the bus probe of the EAL function
which is executed at DPDK initialization, based on their unique device identifier.
-For eg. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
+For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
@@ -379,7 +379,7 @@ using priv_xform would look like:
setup op->m_src and op->m_dst;
}
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, comp_ops, NUM_OPS);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deque = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, NUM_OPS);
} while (num_dqud < num_enqd);
@@ -526,7 +526,7 @@ An example pseudocode to set up and process a stream having NUM_CHUNKS with each
op->src.length = CHUNK_LEN;
op->input_chksum = 0;
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, &op[i], 1);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deqd = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, 1);
} while (num_deqd < num_enqd);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 74a930b..23fa5bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -14,7 +14,7 @@ and AEAD symmetric and asymmetric Crypto operations.
Design Principles
-----------------
-The cryptodev library follows the same basic principles as those used in DPDKs
+The cryptodev library follows the same basic principles as those used in DPDK's
Ethernet Device framework. The Crypto framework provides a generic Crypto device
framework which supports both physical (hardware) and virtual (software) Crypto
devices as well as a generic Crypto API which allows Crypto devices to be
@@ -48,7 +48,7 @@ From the command line using the --vdev EAL option
* If DPDK application requires multiple software crypto PMD devices then required
number of ``--vdev`` with appropriate libraries are to be added.
- * An Application with crypto PMD instaces sharing the same library requires unique ID.
+ * An Application with crypto PMD instances sharing the same library requires unique ID.
Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'``
@@ -396,7 +396,7 @@ Operation Management and Allocation
The cryptodev library provides an API set for managing Crypto operations which
utilize the Mempool Library to allocate operation buffers. Therefore, it ensures
-that the crytpo operation is interleaved optimally across the channels and
+that the crypto operation is interleaved optimally across the channels and
ranks for optimal processing.
A ``rte_crypto_op`` contains a field indicating the pool that it originated from.
When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool.
@@ -602,7 +602,7 @@ Sample code
There are various sample applications that show how to use the cryptodev library,
such as the L2fwd with Crypto sample application (L2fwd-crypto) and
-the IPSec Security Gateway application (ipsec-secgw).
+the IPsec Security Gateway application (ipsec-secgw).
While these applications demonstrate how an application can be created to perform
generic crypto operation, the required complexity hides the basic steps of
@@ -807,7 +807,7 @@ using one of the crypto PMDs available in DPDK.
/*
* Dequeue the crypto operations until all the operations
- * are proccessed in the crypto device.
+ * are processed in the crypto device.
*/
uint16_t num_dequeued_ops, total_num_dequeued_ops = 0;
do {
@@ -886,7 +886,7 @@ the order in which the transforms are passed indicates the order of the chaining
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
-asymmetric crypto xfroms.
+asymmetric crypto xforms.
Each xform defines specific asymmetric crypto algo. Currently supported are:
* RSA
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 96dbf30..74dba4d 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -204,7 +204,7 @@ Creates the following symbol:
Which ``dpdk-pmdinfogen`` scans for. Using this information other relevant
bits of data can be exported from the object file and used to produce a
hardware support description, that ``dpdk-pmdinfogen`` then encodes into a
-json formatted string in the following format:
+JSON formatted string in the following format:
.. code-block:: c
diff --git a/doc/guides/prog_guide/efd_lib.rst b/doc/guides/prog_guide/efd_lib.rst
index cb1a1df..2b355ff 100644
--- a/doc/guides/prog_guide/efd_lib.rst
+++ b/doc/guides/prog_guide/efd_lib.rst
@@ -423,6 +423,6 @@ References
1- EFD is based on collaborative research work between Intel and
Carnegie Mellon University (CMU), interested readers can refer to the paper
-“Scaling Up Clustered Network Appliances with ScaleBricks;” Dong Zhou et al.
+"Scaling Up Clustered Network Appliances with ScaleBricks" Dong Zhou et al.
at SIGCOMM 2015 (`http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p241.pdf`)
for more information.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index fa8afdb..c27f730 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -733,7 +733,7 @@ The most important fields in the structure and how they are used are described b
Malloc heap is a doubly-linked list, where each element keeps track of its
previous and next elements. Due to the fact that hugepage memory can come and
-go, neighbouring malloc elements may not necessarily be adjacent in memory.
+go, neighboring malloc elements may not necessarily be adjacent in memory.
Also, since a malloc element may span multiple pages, its contents may not
necessarily be IOVA-contiguous either - each malloc element is only guaranteed
to be virtually contiguous.
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index e955299..c7dda92 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -162,7 +162,7 @@ The servicing_weight member of struct rte_event_eth_rx_adapter_queue_conf
is applicable when the adapter uses a service core function. The application
has to enable Rx queue interrupts when configuring the ethernet device
using the ``rte_eth_dev_configure()`` function and then use a servicing_weight
-of zero when addding the Rx queue to the adapter.
+of zero when adding the Rx queue to the adapter.
The adapter creates a thread blocked on the interrupt, on an interrupt this
thread enqueues the port id and the queue id to a ring buffer. The adapter
@@ -180,9 +180,9 @@ Rx Callback for SW Rx Adapter
For SW based packet transfers, i.e., when the
``RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT`` is not set in the adapter's
capabilities flags for a particular ethernet device, the service function
-temporarily enqueues mbufs to an event buffer before batch enqueueing these
+temporarily enqueues mbufs to an event buffer before batch enqueuing these
to the event device. If the buffer fills up, the service function stops
-dequeueing packets from the ethernet device. The application may want to
+dequeuing packets from the ethernet device. The application may want to
monitor the buffer fill level and instruct the service function to selectively
enqueue packets to the event device. The application may also use some other
criteria to decide which packets should enter the event device even when
diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
index dcdfeb7..7ea14ba 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -42,7 +42,7 @@ The rte_event structure contains the following metadata fields, which the
application fills in to have the event scheduled as required:
* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
-* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``event_type`` - The source of this event, e.g. RTE_EVENT_TYPE_ETHDEV or CPU.
* ``sub_event_type`` - Distinguishes events inside the application, that have
the same event_type (see above)
* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
@@ -265,7 +265,7 @@ Linking Queues and Ports
The final step is to "wire up" the ports to the queues. After this, the
eventdev is capable of scheduling events, and when cores request work to do,
the correct events are provided to that core. Note that the RX core takes input
-from eg: a NIC so it is not linked to any eventdev queues.
+from e.g.: a NIC so it is not linked to any eventdev queues.
Linking all workers to atomic queues, and the TX core to the single-link queue
can be achieved like this:
@@ -276,7 +276,7 @@ can be achieved like this:
uint8_t tx_port_id = 5;
uint8_t atomic_qs[] = {0, 1};
uint8_t single_link_q = 2;
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
for(int worker_port_id = 1; worker_port_id <= 4; worker_port_id++) {
int links_made = rte_event_port_link(dev_id, worker_port_id, atomic_qs, NULL, 2);
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 84696d4..6fc0888 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -65,7 +65,7 @@ In that mode the library functions perform
- check SQN
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
- check padding data
- remove outer IP header (tunnel mode) / update IP header (transport mode)
@@ -88,7 +88,7 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
- check SQN
- check padding data
@@ -101,10 +101,10 @@ In that mode the library functions perform
- generate SQN and IV
- add outer IP header (tunnel mode) / update IP header (transport mode)
- add ESP header and trailer, padding and IV data
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -113,15 +113,15 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
* for outbound packets:
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ In that mode the library functions perform
* for inbound packets:
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
* for outbound packets:
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 7fcbd93..daf87f4 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -227,7 +227,7 @@ application functions:
``config_promiscusity``:
- Called when the user changes the promiscusity state of the KNI
+ Called when the user changes the promiscuity state of the KNI
interface. For example, when the user runs ``ip link set promisc
[on|off] dev <ifaceX>``. If the user sets this callback function to
NULL, but sets the ``port_id`` field to a value other than -1, a default
diff --git a/doc/guides/prog_guide/metrics_lib.rst b/doc/guides/prog_guide/metrics_lib.rst
index e68e4e7..89bc7d6 100644
--- a/doc/guides/prog_guide/metrics_lib.rst
+++ b/doc/guides/prog_guide/metrics_lib.rst
@@ -25,7 +25,7 @@ individual device. Since the metrics library is self-contained, the only
restriction on port numbers is that they are less than ``RTE_MAX_ETHPORTS``
- there is no requirement for the ports to actually exist.
-Initialising the library
+Initializing the library
------------------------
Before the library can be used, it has to be initialized by calling
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1384fe3..6196d3f 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -273,7 +273,7 @@ will be populated by IPC are as follows:
those peer processes that were active at the time of request, how many have
replied)
* ``msgs`` - pointer to where all of the responses are stored. The order in
- which responses appear is undefined. Whendoing sycnrhonous requests, this
+ which responses appear is undefined. When doing synchronous requests, this
memory must be freed by the requestor after request completes!
For asynchronous requests, a function pointer to the callback function must be
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 5af795c..a36ebef 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -64,7 +64,7 @@ The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
get a wall clock counter in user space. Typically it runs at <= 100MHz.
The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
-clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+clock counter is through the ARMv8 PMU subsystem. The PMU cycle counter runs
at CPU frequency. However, access to the PMU cycle counter from user space is
not enabled by default in the arm64 linux kernel. It is possible to enable
cycle counter for user space access by configuring the PMU from the privileged
@@ -75,7 +75,7 @@ scheme. Application can choose the PMU based implementation with
``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
The example below shows the steps to configure the PMU based cycle counter on
-an armv8 machine.
+an ARMv8 machine.
.. code-block:: console
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 0203f4f..937f52b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2129,7 +2129,7 @@ as defined in the ``rte_flow_action_raw_decap``
This action modifies the payload of matched flows. The data supplied must
be a valid header, either holding layer 2 data in case of removing layer 2
-before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
+before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
tunnel definition starting from layer 2 and moving to the tunnel item itself.
When applied to the original packet the resulting packet must be a
valid packet.
@@ -2279,7 +2279,7 @@ Action: ``DEC_TTL``
Decrease TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_dec_ttl:
@@ -2297,7 +2297,7 @@ Action: ``SET_TTL``
Assigns a new TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_set_ttl:
@@ -2725,7 +2725,7 @@ Caveats
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
-- There is no provision for reentrancy/multi-thread safety, although nothing
+- There is no provision for re-entrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index cb70caa..7d0734a 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -40,7 +40,7 @@ Inline Crypto
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
@@ -48,7 +48,7 @@ Ingress Data path - The packet is decrypted in RX path and relevant
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
arrived. The driver Rx path check the descriptors and and based on the
@@ -111,7 +111,7 @@ Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
@@ -119,7 +119,7 @@ Ingress Data path - The packet is decrypted in the RX path and relevant
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
@@ -132,7 +132,7 @@ to identify the security processing done on the packet.
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
@@ -150,7 +150,7 @@ to cross the MTU size.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
@@ -199,13 +199,13 @@ crypto device.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
@@ -217,7 +217,7 @@ for any protocol header addition.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
@@ -549,7 +549,7 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
struct rte_security_ipsec_sa_options options;
/**< various SA options */
enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
+ /**< IPsec SA Direction - Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< IPsec SA Protocol - AH/ESP */
enum rte_security_ipsec_sa_mode mode;
diff --git a/doc/guides/prog_guide/traffic_management.rst b/doc/guides/prog_guide/traffic_management.rst
index 98ac431..05b34d9 100644
--- a/doc/guides/prog_guide/traffic_management.rst
+++ b/doc/guides/prog_guide/traffic_management.rst
@@ -39,7 +39,7 @@ whether a specific implementation does meet the needs to the user application.
At the TM level, users can get high level idea with the help of various
parameters such as maximum number of nodes, maximum number of hierarchical
levels, maximum number of shapers, maximum number of private shapers, type of
-scheduling algorithm (Strict Priority, Weighted Fair Queueing , etc.), etc.,
+scheduling algorithm (Strict Priority, Weighted Fair Queuing , etc.), etc.,
supported by the implementation.
Likewise, users can query the capability of the TM at the hierarchical level to
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a86c07a..fc3ee43 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -63,7 +63,7 @@ The following is an overview of some key Vhost API functions:
512).
* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enableld).
+ boost could be above 70% (when TSO is enabled).
* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
PMD driver consume the mbuf but not release them timely.
diff --git a/doc/guides/rawdevs/ifpga_rawdev.rst b/doc/guides/rawdevs/ifpga_rawdev.rst
index d400db6..a3d92a6 100644
--- a/doc/guides/rawdevs/ifpga_rawdev.rst
+++ b/doc/guides/rawdevs/ifpga_rawdev.rst
@@ -91,7 +91,7 @@ Run-time parameters
-------------------
This driver is invoked automatically in systems added with Intel FPGA,
-but PR and IFPGA Bus scan is trigged by command line using
+but PR and IFPGA Bus scan is triggered by command line using
``--vdev 'ifpga_rawdev_cfg`` EAL option.
The following device parameters are supported:
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index 358dfa3..276327c 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -676,7 +676,7 @@ igb uio legacy mode can not be used in X710/XL710/XXV710
**Description**:
X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
- bit in the PCI status register. Linux delected them from INTx support table. The related
+ bit in the PCI status register. Linux deleted them from INTx support table. The related
`commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
**Implication**:
@@ -722,9 +722,9 @@ Linux kernel 4.10.0 iommu attribute read error
**Description**:
When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
/sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
- This bug is fixed in `Linux commmit a7fdb6e648fb
+ This bug is fixed in `Linux commit a7fdb6e648fb
<https://patchwork.kernel.org/patch/9595727/>`_,
- This bug is introduced in `Linux commmit 39ab9555c241
+ This bug is introduced in `Linux commit 39ab9555c241
<https://patchwork.kernel.org/patch/9554403/>`_,
**Implication**:
@@ -842,7 +842,7 @@ AVX-512 support disabled
drop.
On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
- on information accured from the GCC community defect.
+ on information accrued from the GCC community defect.
**Reason**:
Generated ``AVX-512`` code cause crash:
diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst
index 2a93af3..6448b6c 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -168,7 +168,7 @@ New Features
* The DES CBC algorithm.
* The DES DOCSIS BPI algorithm.
- This change requires version 0.47 of the IPSec Multi-buffer library. For
+ This change requires version 0.47 of the IPsec Multi-buffer library. For
more details see the :doc:`../cryptodevs/aesni_mb` documentation.
* **Updated the OpenSSL PMD.**
@@ -198,7 +198,7 @@ New Features
* **Added the Security Offload Library.**
Added an experimental library - ``rte_security``. This provide security APIs
- for protocols like IPSec using inline ipsec offload to ethernet devices or
+ for protocols like IPsec using inline ipsec offload to ethernet devices or
full protocol offload with lookaside crypto devices.
See the :doc:`../prog_guide/rte_security` section of the DPDK Programmers
@@ -207,11 +207,11 @@ New Features
* **Updated the DPAA2_SEC crypto driver to support rte_security.**
Updated the ``dpaa2_sec`` crypto PMD to support ``rte_security`` lookaside
- protocol offload for IPSec.
+ protocol offload for IPsec.
* **Updated the IXGBE ethernet driver to support rte_security.**
- Updated ixgbe ethernet PMD to support ``rte_security`` inline IPSec offload.
+ Updated ixgbe ethernet PMD to support ``rte_security`` inline IPsec offload.
* **Updated i40e driver to support GTP-C/GTP-U.**
@@ -509,7 +509,7 @@ ABI Changes
* **New parameter added to rte_eth_dev.**
A new parameter ``security_ctx`` has been added to ``rte_eth_dev`` to
- support security operations like IPSec inline.
+ support security operations like IPsec inline.
* **New parameter added to rte_cryptodev.**
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 40a3264..405e706 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -68,7 +68,7 @@ The application accepts a number of command line options:
where:
-* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2)
+* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2)
* ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4)
* ``p ETH_PORT_ID``: ethernet port ID (default = 0)
* ``b BBDEV_ID``: BBDev ID (default = 0)
@@ -87,7 +87,7 @@ issue the command:
$ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
--file-prefix=bbdev -- -e 0x10 -d 0x20
-where, NIC0PCIADDR is the PCI addresse of the Rx port
+where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index 0ec0290..dc7972a 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -49,7 +49,7 @@ these settings is shown below:
./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
-(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application
will print an error message:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index 159bcf7..9070419 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -106,7 +106,7 @@ examples are highlighted below.
(packet arrival) and TX (packet transmission) by adding callbacks to the RX
and TX packet processing functions.
-* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security
+* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security
Gateway application is minimal example of something closer to a real world
example. This is also a good example of an application using the DPDK
Cryptodev framework.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 447a544..4da0fcf 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -113,7 +113,7 @@ Application stages
Initialization
~~~~~~~~~~~~~~
-During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures
+During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures
(i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message
is displayed and the application is terminated.
@@ -185,7 +185,7 @@ Examples
+-----------------------+----------------------+----------------+------------------------------------+
| IP routing | LPM (IPv4) | Forward | 1. Mempool Create |
| | | | 2. Link create |
- | | * Key = IP dest addr | | 3. Pipeline creat |
+ | | * Key = IP dest addr | | 3. Pipeline create |
| | * Offset = 286 | | 4. Pipeline port in/out |
| | * Table size = 4K | | 5. Pipeline table |
| | | | 6. Pipeline port in table |
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 3d784e7..ac118c1 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*.
Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
@@ -124,7 +124,7 @@ Where:
* ``-e``: enables Security Association extended sequence number processing
(available only with librte_ipsec code path).
-* ``-a``: enables Security Association sequence number atomic behaviour
+* ``-a``: enables Security Association sequence number atomic behavior
(available only with librte_ipsec code path).
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
@@ -752,7 +752,7 @@ DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
-It then tries to perform some data transfer using the scheme decribed above.
+It then tries to perform some data transfer using the scheme described above.
usage
~~~~~
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index e2c04ef..ac6ee8a 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in
the L-thread struct.
For legacy and backward compatibility reasons two alternative methods are also
-offered, the first is modelled directly on the pthread get/set specific APIs,
-the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby
+offered, the first is modeled directly on the pthread get/set specific APIs,
+the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby
``PER_LTHREAD`` macros are introduced, in both cases the storage is local to
the L-thread.
diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst
index 2e8e017..d75f7da 100644
--- a/doc/guides/sample_app_ug/qos_metering.rst
+++ b/doc/guides/sample_app_ug/qos_metering.rst
@@ -151,5 +151,5 @@ In this particular case:
* For the rest of the cases, the color is changed to red.
.. note::
- * In color blind mode, first row GREEN colour is only valid.
+ * In color blind mode, first row GREEN color is only valid.
* To drop the packet, policer_table action has to be set to DROP.
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 5f313c5..5aefd8d 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -32,7 +32,7 @@ Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`
-The application is located in the ``$RTE_SDK/app/test-pipline`` directory.
+The application is located in the ``$RTE_SDK/app/test-pipeline`` directory.
Running the Application
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df4d6f9..a71ada6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file.
The vm2vm parameter sets the mode of packet switching between guests in
the host.
-- 0 disables vm2vm, impling that VM's packets will always go to the NIC port.
+- 0 disables vm2vm, implying that VM's packets will always go to the NIC port.
- 1 means a normal mac lookup packet routing.
- 2 means hardware mode packet forwarding between guests, it allows packets
go to the NIC port, hardware L2 switch will determine which guest the
@@ -148,7 +148,7 @@ default value is 15.
**--dequeue-zero-copy**
Dequeue zero copy will be enabled when this option is given. it is worth to
-note that if NIC is binded to driver with iommu enabled, dequeue zero copy
+note that if NIC is bound to driver with iommu enabled, dequeue zero copy
cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu
dma mapping for guest memory.
diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst
index 7ab7d0d..6b9bf62 100644
--- a/doc/guides/sample_app_ug/vhost_scsi.rst
+++ b/doc/guides/sample_app_ug/vhost_scsi.rst
@@ -63,7 +63,7 @@ Vhost_scsi Common Issues
* vhost_scsi can not start with block size 512 Bytes:
- Currently DPDK vhost library was designed for NET device(althrough the APIs
+ Currently DPDK vhost library was designed for NET device(although the APIs
are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced
Disk Device) will enumerate all block device and do some IOs to those block
devices with 512 Bytes sector size. DPDK vhost library can not process such
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e..109d109 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -344,7 +344,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs.
When this parameter is used, the list of cores specified will monitor the ratio
between branch hits and branch misses. A tightly polling PMD thread will have a
- very low branch ratio, so the core frequency will be scaled down to the minimim
+ very low branch ratio, so the core frequency will be scaled down to the minimum
allowed value. When packets are received, the code path will alter, causing the
branch ratio to increase. When the ratio goes above the ratio threshold, the
core frequency will be scaled up to the maximum allowed value.
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The JSON string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -734,7 +734,7 @@ policy down to the host application. These parameters are as follows:
A comma-separated list of cores in the VM that the user wants the host application to
monitor. The list of cores in any vm starts at zero, and these are mapped to the
physical cores by the host application once the policy is passed down.
- Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a
+ Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a
combination of both '1,3,5-7'
.. code-block:: console
@@ -742,7 +742,7 @@ policy down to the host application. These parameters are as follows:
--busy-hours {list of busy hours}
A comma-separated list of hours within which to set the core frequency to maximum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
@@ -750,7 +750,7 @@ policy down to the host application. These parameters are as follows:
--quiet-hours {list of quiet hours}
A comma-separated list of hours within which to set the core frequency to minimum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index fdf6ec7..e7db520 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -381,7 +381,7 @@ The command line options are:
* ``--hot-plug``
- Enable device event monitor mechanism for hot plug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -421,23 +421,23 @@ The command line options are:
* ``--noisy-lkup-memory=N``
- Set the size of the noisy neighbour simulation memory buffer in MB to N.
+ Set the size of the noisy neighbor simulation memory buffer in MB to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads=N``
- Set the number of reads to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of reads to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-writes=N``
- Set the number of writes to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of writes to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads-writes=N``
- Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of r/w accesses to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--no-iova-contig``
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 5d4dc6f..e602df5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -303,7 +303,7 @@ The available information categories are:
This is the default mode.
* ``mac``: Changes the source and the destination Ethernet addresses of packets before forwarding them.
- Default application behaviour is to set source Ethernet address to that of the transmitting interface, and destination
+ Default application behavior is to set source Ethernet address to that of the transmitting interface, and destination
address to a dummy value (set during init). The user may specify a target destination Ethernet address via the 'eth-peer' or
'eth-peers-configfile' command-line options. It is not currently possible to specify a specific source Ethernet address.
@@ -326,7 +326,7 @@ The available information categories are:
* ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is
similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``.
-* ``noisy``: Noisy neighbour simulation.
+* ``noisy``: Noisy neighbor simulation.
Simulate more realistic behavior of a guest machine engaged in receiving
and sending packets performing Virtual Network Function (VNF).
@@ -2289,7 +2289,7 @@ set bonding lacp dedicated_queue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
-when in mode 4 (link-aggregration-802.3ad)::
+when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
@@ -2297,7 +2297,7 @@ when in mode 4 (link-aggregration-802.3ad)::
set bonding agg_mode
~~~~~~~~~~~~~~~~~~~~
-Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+Enable one of the specific aggregators mode when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
@@ -2691,8 +2691,8 @@ where:
* ``shared_shaper_id``: Shared shaper ID to be deleted.
-Set port traffic management hiearchy node private shaper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Set port traffic management hierarchy node private shaper
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
set the port traffic management hierarchy node private shaper::
@@ -2743,7 +2743,7 @@ Delete the WRED profile::
Add port traffic management hierarchy nonleaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add nonleaf node to port traffic management hiearchy::
+Add nonleaf node to port traffic management hierarchy::
testpmd> add port tm nonleaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2758,7 +2758,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``n_sp_priorities``: Number of strict priorities.
@@ -2769,7 +2769,7 @@ where:
Add port traffic management hierarchy leaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add leaf node to port traffic management hiearchy::
+Add leaf node to port traffic management hierarchy::
testpmd> add port tm leaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2784,7 +2784,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``cman_mode``: Congestion management mode to be enabled for this node.
@@ -2796,7 +2796,7 @@ where:
Delete port traffic management hierarchy node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Delete node from port traffic management hiearchy::
+Delete node from port traffic management hierarchy::
testpmd> del port tm node (port_id) (node_id)
@@ -3989,7 +3989,7 @@ This section lists supported actions and their attributes, if any.
- ``dec_ttl``: Performs a decrease TTL value action
-- ``set_ttl``: Set TTL value with specificed value
+- ``set_ttl``: Set TTL value with specified value
- ``ttl_value {unsigned}``: The new TTL value to be set
- ``set_mac_src``: set source MAC address
@@ -4522,7 +4522,7 @@ The following sections show functions to load/unload eBPF based filters.
bpf-load
~~~~~~~~
-Load an eBPF program as a callback for partciular RX/TX queue::
+Load an eBPF program as a callback for particular RX/TX queue::
testpmd> bpf-load rx|tx (portid) (queueid) (load-flags) (bpf-prog-filename)
@@ -4560,7 +4560,7 @@ To load (not JITed) t1.o at TX queue 0, port 0::
bpf-unload
~~~~~~~~~~
-Unload previously loaded eBPF program for partciular RX/TX queue::
+Unload previously loaded eBPF program for particular RX/TX queue::
testpmd> bpf-unload rx|tx (portid) (queueid)
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index c366af4..2fc6544 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -59,7 +59,7 @@ To set on the linearization options add below definition to the
**Step 3: Build the application**
Execute the ``dpdk-setup.sh`` script to build the DPDK library together with the
-``dpdk-test-crypto-perf`` applcation.
+``dpdk-test-crypto-perf`` application.
Initially, the user must select a DPDK target to choose the correct target type
and compiler options to use when building the libraries.
@@ -80,7 +80,7 @@ EAL Options
~~~~~~~~~~~
The following are the EAL command-line options that can be used in conjunction
-with the ``dpdk-test-crypto-perf`` applcation.
+with the ``dpdk-test-crypto-perf`` application.
See the DPDK Getting Started Guides for more information on these options.
* ``-c <COREMASK>`` or ``-l <CORELIST>``
@@ -96,10 +96,10 @@ See the DPDK Getting Started Guides for more information on these options.
Add a virtual device.
-Appication Options
-~~~~~~~~~~~~~~~~~~
+Application Options
+~~~~~~~~~~~~~~~~~~~
-The following are the appication command-line options:
+The following are the application command-line options:
* ``--ptest type``
@@ -338,13 +338,13 @@ Test Vector File
The test vector file is a text file contain information about test vectors.
The file is made of the sections. The first section doesn't have header.
It contain global information used in each test variant vectors -
-typically information about plaintext, ciphertext, cipher key, aut key,
+typically information about plaintext, ciphertext, cipher key, auth key,
initial vector. All other sections begin header.
The sections contain particular information typically digest.
**Format of the file:**
-Each line beginig with sign '#' contain comment and it is ignored by parser::
+Each line beginning with sign '#' contain comment and it is ignored by parser::
# <comment>
@@ -352,16 +352,16 @@ Header line is just name in square bracket::
[<section name>]
-Data line contain information tocken then sign '=' and
+Data line contain information token then sign '=' and
a string of bytes in C byte array format::
- <tocken> = <C byte array>
+ <token> = <C byte array>
-**Tockens list:**
+**Tokens list:**
* ``plaintext``
- Original plaintext to be crypted.
+ Original plaintext to be encrypted.
* ``ciphertext``
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index 6bdf5a8..2ea1b59 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -44,7 +44,7 @@ If no port mask is specified xstats are reset for all DPDK ports.
**-m**: Print DPDK memory information.
**--show-port**
-The show-port parameter displays port level various configuration informationi
+The show-port parameter displays port level various configuration information
associated to RX port queue pair.
**--show-tm**
@@ -56,7 +56,7 @@ The show-crypto parameter displays available cryptodev configurations,
settings and stats per node.
**--show-ring[=name]**
-The show-ring pararmeter display current allocation of all ring with
+The show-ring parameter display current allocation of all ring with
debug information. Specifying the name allows to display details for specific
ring. For invalid or no ring name, whole list is dump.
@@ -76,7 +76,7 @@ Limitations
* When running ``dpdk-procinfo`` with shared library mode, it is required to
pass the same NIC PMD libraries as used for the primary application. Any
- mismatch in PMD library arguments can lead to undefined behaviour and results
+ mismatch in PMD library arguments can lead to undefined behavior and results
affecting primary application too.
* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP.
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 07da35e..7e6a4db 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -139,7 +139,7 @@ There are 6 main test cases that can be executed using testbbdev tool:
* Latency measurement [-c latency]
- Measures the time consumed from the first enqueue until the first
appearance of a dequeued result
- - This measurment represents the full latency of a bbdev operation
+ - This measurement represents the full latency of a bbdev operation
(encode or decode) to execute
* Poll-mode Throughput measurement [-c throughput]
--
2.7.5
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
@ 2019-04-26 15:14 4% John McNamara
2019-04-26 15:14 4% ` John McNamara
0 siblings, 1 reply; 53+ results
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/compressdevs/overview.rst | 2 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/cryptodevs/aesni_mb.rst | 2 +-
doc/guides/cryptodevs/overview.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 2 +-
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/howto/lm_bond_virtio_sriov.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 ++--
doc/guides/howto/rte_flow.rst | 6 ++---
doc/guides/howto/telemetry.rst | 2 +-
.../howto/virtio_user_as_exceptional_path.rst | 8 +++----
doc/guides/nics/af_packet.rst | 4 ++--
doc/guides/nics/atlantic.rst | 2 +-
doc/guides/nics/cxgbe.rst | 4 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/dpaa2.rst | 2 +-
doc/guides/nics/ena.rst | 2 +-
doc/guides/nics/enetc.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 2 +-
doc/guides/nics/ixgbe.rst | 4 ++--
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/mlx5.rst | 4 ++--
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.rst | 2 +-
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/nfp.rst | 4 ++--
doc/guides/nics/sfc_efx.rst | 14 +++++------
doc/guides/nics/szedata2.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/platform/dpaa.rst | 4 ++--
doc/guides/platform/dpaa2.rst | 4 ++--
doc/guides/prog_guide/bbdev.rst | 4 ++--
doc/guides/prog_guide/compressdev.rst | 6 ++---
doc/guides/prog_guide/cryptodev_lib.rst | 12 +++++-----
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/efd_lib.rst | 2 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
.../prog_guide/event_ethernet_rx_adapter.rst | 6 ++---
doc/guides/prog_guide/eventdev.rst | 6 ++---
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++-------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 2 +-
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 ++--
doc/guides/prog_guide/rte_flow.rst | 8 +++----
doc/guides/prog_guide/rte_security.rst | 20 ++++++++--------
doc/guides/prog_guide/traffic_management.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 2 +-
doc/guides/rawdevs/ifpga_rawdev.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 8 +++----
doc/guides/rel_notes/release_17_11.rst | 10 ++++----
doc/guides/sample_app_ug/bbdev_app.rst | 4 ++--
doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 2 +-
doc/guides/sample_app_ug/ip_pipeline.rst | 4 ++--
doc/guides/sample_app_ug/ipsec_secgw.rst | 8 +++----
doc/guides/sample_app_ug/performance_thread.rst | 4 ++--
doc/guides/sample_app_ug/qos_metering.rst | 2 +-
doc/guides/sample_app_ug/test_pipeline.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 4 ++--
doc/guides/sample_app_ug/vhost_scsi.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 10 ++++----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++---------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
71 files changed, 170 insertions(+), 170 deletions(-)
diff --git a/doc/guides/compressdevs/overview.rst b/doc/guides/compressdevs/overview.rst
index 70bbe82..809e4e6 100644
--- a/doc/guides/compressdevs/overview.rst
+++ b/doc/guides/compressdevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
without making any modifications to it (no compression done).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means PMD supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e6..3b2b174 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -8,7 +8,7 @@ Contributing Code to DPDK
This document outlines the guidelines for submitting code to DPDK.
-The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
`How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 8915201..1eff2b0 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -129,7 +129,7 @@ Extra notes
For AES Counter mode (AES-CTR), the library supports two different sizes for Initialization
Vector (IV):
-* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, which internally
+* 12 bytes: used mainly for IPsec, as it requires 12 bytes from the user, which internally
are appended the counter block (4 bytes), which is set to 1 for the first block
(no padding required from the user)
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index 12f342b..a972c79 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
being the operation in-place (input address = output address).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means pmd supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index a754a27..7004ca4 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -165,7 +165,7 @@ operation:
For pure small packet size (64 bytes) traffic however the multi-core mode is not
an optimal solution, as it doesn't give significant per-core performance improvement.
For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
- For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+ For large packets (1.5 kbytes) scheduler shows linear scaling in performance
up to eight cores.
Each worker uses its own slave cryptodev. Only software cryptodevs
are supported. Only the same type of cryptodevs should be used concurrently.
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
index 0262a33..979f6cd 100644
--- a/doc/guides/eventdevs/opdl.rst
+++ b/doc/guides/eventdevs/opdl.rst
@@ -8,7 +8,7 @@ The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
implementation of the eventdev API. It is particularly suited to packet\
processing workloads that have high throughput and low latency requirements.\
All packets follow the same path through the device. The order in which\
-packets follow is determinted by the order in which queues are set up.\
+packets follow is determined by the order in which queues are set up.\
Events are left on the ring until they are transmitted. As a result packets\
do not go out of order
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index afdcad7..04c8b03 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -70,7 +70,7 @@ Credit Quanta
The credit quanta is the number of credits that a port will fetch at a time from
the instance's credit pool. Higher numbers will cause less overhead in the
atomic credit fetch code, however it also reduces the overall number of credits
-in the system faster. A balanced number (eg 32) ensures that only small numbers
+in the system faster. A balanced number (e.g. 32) ensures that only small numbers
of credits are pre-allocated at a time, while also mitigating performance impact
of the atomics.
@@ -100,7 +100,7 @@ feature would be significant.
~~~~~~~~~~~~~~~~~~
The software eventdev does not support creating queues that handle all types of
-traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
+traffic. An eventdev with this capability allows enqueuing Atomic, Ordered and
Parallel traffic to the same queue, but scheduling each of them appropriately.
The reason to not allow Atomic, Ordered and Parallel event types in the
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index ee8ccda..07563b3 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -328,7 +328,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
testpmd> show bonding config 2
testpmd> port attach 0000:00:04.0
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 6ebc10f..ecb7832 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -243,7 +243,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
Virtio traffic is seen at P0 and P1.
@@ -338,7 +338,7 @@ reset_vf_on_212_131.sh
#!/bin/sh
# This script is run on the host 10.237.212.131 to reset SRIOV
- # BDF for Ninatic NIC is 0000:06:00.0
+ # BDF for Niantic NIC is 0000:06:00.0
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
echo 0 > /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 3dcda6c..e197376 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -23,7 +23,7 @@ In this example we will create a simple rule that drops packets whose IPv4
destination equals 192.168.3.2. This code is equivalent to the following
testpmd command (wrapped for clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst is 192.168.3.2 / end actions drop / end
Code
@@ -118,7 +118,7 @@ a mask.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 /
end actions drop / end
@@ -219,7 +219,7 @@ In this example we will create a rule that routes all vlan id 123 to queue 3.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
+ testpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
end actions queue index 3 / end
Code
diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst
index 00f8f7a..e10804d 100644
--- a/doc/guides/howto/telemetry.rst
+++ b/doc/guides/howto/telemetry.rst
@@ -18,7 +18,7 @@ which acts as the client.
In DPDK, applications are used to initialize the ``telemetry``. To view incoming
traffic on featured ports, the application should be run first (ie. after ports
are configured). Once the application is running, the service assurance agent
-(for example the collectd plugin) should be run to begin querying the API.
+(for example the CollectD plugin) should be run to begin querying the API.
A client connects their Service Assurance application to the DPDK application
via a UNIX socket. Once a connection is established, a client can send JSON
diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst
index 4910c12..ec021af 100644
--- a/doc/guides/howto/virtio_user_as_exceptional_path.rst
+++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2016 Intel Corporation.
-.. _virtio_user_as_excpetional_path:
+.. _virtio_user_as_exceptional_path:
Virtio_user as Exceptional Path
===============================
@@ -22,7 +22,7 @@ solution is very promising in:
* Features
vhost-net is born to be a networking solution, which has lots of networking
- related featuers, like multi queue, tso, multi-seg mbuf, etc.
+ related features, like multi queue, tso, multi-seg mbuf, etc.
* Performance
@@ -38,7 +38,7 @@ in :numref:`figure_virtio_user_as_exceptional_path`.
.. figure:: img/virtio_user_as_exceptional_path.*
- Overview of a DPDK app using virtio-user as excpetional path
+ Overview of a DPDK app using virtio-user as exceptional path
Sample Usage
@@ -75,7 +75,7 @@ compiling the kernel and those kernel modules should be inserted.
* ``queues``
- Number of multi-queues. Each qeueue will be served by a kthread. For example:
+ Number of multi-queues. Each queue will be served by a kthread. For example:
.. code-block:: console
diff --git a/doc/guides/nics/af_packet.rst b/doc/guides/nics/af_packet.rst
index 1260bb2..efd6f1c 100644
--- a/doc/guides/nics/af_packet.rst
+++ b/doc/guides/nics/af_packet.rst
@@ -13,13 +13,13 @@ PACKET_MMAP, which provides a mmap'ed ring buffer, shared between user space
and kernel, that's used to send and receive packets. This helps reducing system
calls and the copies needed between user space and Kernel.
-The PACKET_FANOUT_HASH behaviour of AF_PACKET is used for frame reception.
+The PACKET_FANOUT_HASH behavior of AF_PACKET is used for frame reception.
Options and inherent limitations
--------------------------------
The following options can be provided to set up an af_packet port in DPDK.
-Some of these, in turn, will be used to configure the PAKET_MMAP settings.
+Some of these, in turn, will be used to configure the PACKET_MMAP settings.
* ``iface`` - name of the Kernel interface to attach to (required);
* ``qpairs`` - number of Rx and Tx queues (optional, default 1);
diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst
index 22f2410..3f3f294 100644
--- a/doc/guides/nics/atlantic.rst
+++ b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
- Port statistics
- RSS (Receive Side Scaling)
- Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
- MACSEC offload
Experimental API features
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index f3e6115..7a893cc 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -126,7 +126,7 @@ enabling debugging options may affect system performance.
- ``CONFIG_RTE_LIBRTE_CXGBE_TPUT`` (default **y**)
- Toggle behaviour to prefer Throughput or Latency.
+ Toggle behavior to prefer Throughput or Latency.
Runtime Options
~~~~~~~~~~~~~~~
@@ -140,7 +140,7 @@ be passed as part of EAL arguments. For example,
- ``keep_ovlan`` (default **0**)
- Toggle behaviour to keep/strip outer VLAN in Q-in-Q packets. If
+ Toggle behavior to keep/strip outer VLAN in Q-in-Q packets. If
enabled, the outer VLAN tag is preserved in Q-in-Q packets. Otherwise,
the outer VLAN tag is stripped in Q-in-Q packets.
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index fb7bc7d..2243a4a 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -251,7 +251,7 @@ state during application initialization:
automatically be assigned from the these high perf PUSH queues. Any queue
configuration beyond that will be standard Rx queues. The application can
choose to change their number if HW portals are limited.
- The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ The valid values are from '0' to '4'. The values shall be set to '0' if the
application want to use eventdev with DPAA device.
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index d74d8f8..b3b7678 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -379,7 +379,7 @@ active -- Ethernet, crypto, compression, etc.
DPBP based Mempool driver
~~~~~~~~~~~~~~~~~~~~~~~~~
-The DPBP driver is bound to a DPBP objects and provides sevices to
+The DPBP driver is bound to a DPBP objects and provides services to
create a hardware offloaded packet buffer mempool.
DPAA2 NIC Driver
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 80da4b6..d44f3cd 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -189,7 +189,7 @@ Prerequisites
reduces the latency of the packets by pushing the header directly through
the PCI to the device, before the DMA is even triggered. For proper work
kernel PCI driver must support write combining (WC). In mainline version of
- ``igb_uio`` (in DPDK repo) it must be enabled by loding module with
+ ``igb_uio`` (in DPDK repo) it must be enabled by loading module with
``wc_activate=1`` flag (example below). However, mainline's vfio-pci
driver in kernel doesn't have WC support yet (planed to be added).
If vfio-pci used user should be either turn off ENAv2 (to avoid performance
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 2620460..3c896ee 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -76,7 +76,7 @@ Supported ENETC SoCs
Prerequisites
~~~~~~~~~~~~~
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 726a69e..cdb55e0 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -224,7 +224,7 @@ the use of SR-IOV.
passthrough devices do not require libvirt, port profiles, and VM-FEX.
-.. _enic-genic-flow-api:
+.. _enic-generic-flow-api:
Generic Flow API support
------------------------
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c5bf322..d57ddc2 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -495,7 +495,7 @@ Supports adding traffic mirroring rules.
Inline crypto
-------------
-Supports inline crypto processing (eg. inline IPsec). See Security library and PMD documentation for more details.
+Supports inline crypto processing (e.g. inline IPsec). See Security library and PMD documentation for more details.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_SECURITY``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 9680a92..2e9ec79 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -580,7 +580,7 @@ bandwidth setting.
TC TX scheduling mode setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There're 2 TX scheduling modes for TCs, round robin and strict priority mode.
+There are 2 TX scheduling modes for TCs, round robin and strict priority mode.
If a TC is set to strict priority mode, it can consume unlimited bandwidth.
It means if APP has set the max bandwidth for that TC, it comes to no
effect.
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1c294b0..975143f 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -203,8 +203,8 @@ as a workaround.
X550 does not support legacy interrupt mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Desccription
-^^^^^^^^^^^^
+Description
+^^^^^^^^^^^
X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy
interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states
that the Interrupt Status bit is not implemented. The errata is the item #22
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index a66c595..602a06b 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -65,7 +65,7 @@ backend device by default.
PMD arguments
-------------
-``no_request_thread``, by default PMD creates a phtread for each KNI interface
+``no_request_thread``, by default PMD creates a pthread for each KNI interface
to handle Linux network interface control commands, like ``ifconfig kni0 up``
With ``no_request_thread`` option, pthread is not created and control commands
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index aaf1907..f6d7a16 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -83,7 +83,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx4**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx4**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5fa6b62..af1e408 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,7 +168,7 @@ Limitations
- must specify the VXLAN item with tunnel outer parameters.
- must specify the tunnel outer VNI in the VXLAN item.
- must specify the tunnel outer remote (destination) UDP port in the VXLAN item.
- - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed.
+ - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interface, wildcards not allowed.
- must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed.
- must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule.
@@ -216,7 +216,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx5**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx5**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 09e2f2a..bacc013 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -91,7 +91,7 @@ Limitations
chance to start in a sane state.
- MUSDK architecture does not support changing configuration in run time.
- All nessesary configurations should be done before first dev_start().
+ All necessary configurations should be done before first dev_start().
- RX queue start/stop is not supported.
diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 87fabf5..6dbb9a5 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -89,7 +89,7 @@ operations:
.. Note::
- The dpkd-devbind.py script can not be used since it only handles PCI devices.
+ The dpdk-devbind.py script can not be used since it only handles PCI devices.
Prerequisites
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index a7fb963..8df76c0 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -81,7 +81,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They are represented in DPDK as a single port.
-NFB-200G2QL card employs an addon cable which allows to connect it to two
+NFB-200G2QL card employs an add-on cable which allows to connect it to two
physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 09a8529..309fa5d 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -149,8 +149,8 @@ PF multiprocess support
-----------------------
Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary proceses with PF
-ports is limitted to only one.
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
This limitation will be solved in future versions but having basic multiprocess support
is important for allowing development and debugging through the PF using a secondary
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index eb47f25..6d01d05 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -96,7 +96,7 @@ Non-supported Features
The features not yet supported include:
-- Receive queue interupts
+- Receive queue interrupts
- Priority-based flow control
@@ -209,12 +209,12 @@ Validating flow rules depends on the firmware variant.
The :ref:`flow_isolated_mode` is supported.
-Ethernet destinaton individual/group match
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ethernet destination individual/group match
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet item supports I/G matching, if only the corresponding bit is set
-in the mask of destination address. If destinaton address in the spec is
-multicast, it matches all multicast (and broadcast) packets, oherwise it
+in the mask of destination address. If destination address in the spec is
+multicast, it matches all multicast (and broadcast) packets, otherwise it
matches unicast packets that are not filtered by other flow rules.
Exceptions to flow rules
@@ -348,10 +348,10 @@ boolean parameters value.
- ``perf_profile`` [auto|throughput|low-latency] (default **throughput**)
- Choose hardware tunning to be optimized for either throughput or
+ Choose hardware tuning to be optimized for either throughput or
low-latency.
**auto** allows NIC firmware to make a choice based on
- installed licences and firmware variant configured using **sfboot**.
+ installed licenses and firmware variant configured using **sfboot**.
- ``stats_update_period_ms`` [long] (default **1000**)
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index a2092f9..94dba82 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -89,7 +89,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They were historically represented in DPDK as a single port.
-However, the new NFB-200G2QL card employs an addon cable which allows to connect
+However, the new NFB-200G2QL card employs an add-on cable which allows to connect
it to two physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 063bd0b..4b6d77d 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -40,7 +40,7 @@ actual MAC address: ``00:64:74:61:70:[00-FF]``.
--vdev=net_tap0,mac="00:64:74:61:70:11"
The MAC address will have a user value passed as string. The MAC address is in
-format with delimeter ``:``. The string is byte converted to hex and you get
+format with delimiter ``:``. The string is byte converted to hex and you get
the actual MAC address: ``00:64:74:61:70:11``.
It is possible to specify a remote netdevice to capture packets from by adding
diff --git a/doc/guides/platform/dpaa.rst b/doc/guides/platform/dpaa.rst
index 3904871..6005f22 100644
--- a/doc/guides/platform/dpaa.rst
+++ b/doc/guides/platform/dpaa.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA Board Support Package
====================================
-This doc has information about steps to setup QorIq dpaa
+This doc has information about steps to setup QorIQ dpaa
based layerscape platform and information about common offload
hw block drivers of **NXP QorIQ DPAA** SoC family.
@@ -38,7 +38,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA PMD on a DPAA
+There are four main pre-requisites for executing DPAA PMD on a DPAA
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/platform/dpaa2.rst b/doc/guides/platform/dpaa2.rst
index 5a64406..2586af0 100644
--- a/doc/guides/platform/dpaa2.rst
+++ b/doc/guides/platform/dpaa2.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA2 Board Support Package
=====================================
-This doc has information about steps to setup NXP QoriQ DPAA2 platform
+This doc has information about steps to setup NXP QorIQ DPAA2 platform
and information about common offload hw block drivers of
**NXP QorIQ DPAA2** SoC family.
@@ -48,7 +48,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA2 PMD on a DPAA2
+There are four main pre-requisites for executing DPAA2 PMD on a DPAA2
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9de1444..658ffd4 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev device consists of
one or more queues identified by queue IDs. While different devices may have
different capabilities (e.g. support different operation types), all queues on
a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initializations time.
+for only one type of operation and is configured at initialization time.
When an operation is enqueued to a specific queue ID, the result is dequeued
from the same queue ID.
@@ -678,7 +678,7 @@ bbdev framework, by giving a sample code performing a loop-back operation with a
baseband processor capable of transceiving data packets.
The following sample C-like pseudo-code shows the basic steps to encode several
-buffers using (**sw_trubo**) bbdev PMD.
+buffers using (**sw_turbo**) bbdev PMD.
.. code-block:: c
diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst
index ad97037..a06c835 100644
--- a/doc/guides/prog_guide/compressdev.rst
+++ b/doc/guides/prog_guide/compressdev.rst
@@ -17,7 +17,7 @@ Device Creation
Physical compression devices are discovered during the bus probe of the EAL function
which is executed at DPDK initialization, based on their unique device identifier.
-For eg. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
+For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
@@ -379,7 +379,7 @@ using priv_xform would look like:
setup op->m_src and op->m_dst;
}
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, comp_ops, NUM_OPS);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deque = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, NUM_OPS);
} while (num_dqud < num_enqd);
@@ -526,7 +526,7 @@ An example pseudocode to set up and process a stream having NUM_CHUNKS with each
op->src.length = CHUNK_LEN;
op->input_chksum = 0;
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, &op[i], 1);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deqd = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, 1);
} while (num_deqd < num_enqd);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 74a930b..23fa5bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -14,7 +14,7 @@ and AEAD symmetric and asymmetric Crypto operations.
Design Principles
-----------------
-The cryptodev library follows the same basic principles as those used in DPDKs
+The cryptodev library follows the same basic principles as those used in DPDK's
Ethernet Device framework. The Crypto framework provides a generic Crypto device
framework which supports both physical (hardware) and virtual (software) Crypto
devices as well as a generic Crypto API which allows Crypto devices to be
@@ -48,7 +48,7 @@ From the command line using the --vdev EAL option
* If DPDK application requires multiple software crypto PMD devices then required
number of ``--vdev`` with appropriate libraries are to be added.
- * An Application with crypto PMD instaces sharing the same library requires unique ID.
+ * An Application with crypto PMD instances sharing the same library requires unique ID.
Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'``
@@ -396,7 +396,7 @@ Operation Management and Allocation
The cryptodev library provides an API set for managing Crypto operations which
utilize the Mempool Library to allocate operation buffers. Therefore, it ensures
-that the crytpo operation is interleaved optimally across the channels and
+that the crypto operation is interleaved optimally across the channels and
ranks for optimal processing.
A ``rte_crypto_op`` contains a field indicating the pool that it originated from.
When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool.
@@ -602,7 +602,7 @@ Sample code
There are various sample applications that show how to use the cryptodev library,
such as the L2fwd with Crypto sample application (L2fwd-crypto) and
-the IPSec Security Gateway application (ipsec-secgw).
+the IPsec Security Gateway application (ipsec-secgw).
While these applications demonstrate how an application can be created to perform
generic crypto operation, the required complexity hides the basic steps of
@@ -807,7 +807,7 @@ using one of the crypto PMDs available in DPDK.
/*
* Dequeue the crypto operations until all the operations
- * are proccessed in the crypto device.
+ * are processed in the crypto device.
*/
uint16_t num_dequeued_ops, total_num_dequeued_ops = 0;
do {
@@ -886,7 +886,7 @@ the order in which the transforms are passed indicates the order of the chaining
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
-asymmetric crypto xfroms.
+asymmetric crypto xforms.
Each xform defines specific asymmetric crypto algo. Currently supported are:
* RSA
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 96dbf30..74dba4d 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -204,7 +204,7 @@ Creates the following symbol:
Which ``dpdk-pmdinfogen`` scans for. Using this information other relevant
bits of data can be exported from the object file and used to produce a
hardware support description, that ``dpdk-pmdinfogen`` then encodes into a
-json formatted string in the following format:
+JSON formatted string in the following format:
.. code-block:: c
diff --git a/doc/guides/prog_guide/efd_lib.rst b/doc/guides/prog_guide/efd_lib.rst
index cb1a1df..2b355ff 100644
--- a/doc/guides/prog_guide/efd_lib.rst
+++ b/doc/guides/prog_guide/efd_lib.rst
@@ -423,6 +423,6 @@ References
1- EFD is based on collaborative research work between Intel and
Carnegie Mellon University (CMU), interested readers can refer to the paper
-“Scaling Up Clustered Network Appliances with ScaleBricks;” Dong Zhou et al.
+"Scaling Up Clustered Network Appliances with ScaleBricks" Dong Zhou et al.
at SIGCOMM 2015 (`http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p241.pdf`)
for more information.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index fa8afdb..c27f730 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -733,7 +733,7 @@ The most important fields in the structure and how they are used are described b
Malloc heap is a doubly-linked list, where each element keeps track of its
previous and next elements. Due to the fact that hugepage memory can come and
-go, neighbouring malloc elements may not necessarily be adjacent in memory.
+go, neighboring malloc elements may not necessarily be adjacent in memory.
Also, since a malloc element may span multiple pages, its contents may not
necessarily be IOVA-contiguous either - each malloc element is only guaranteed
to be virtually contiguous.
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index e955299..c7dda92 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -162,7 +162,7 @@ The servicing_weight member of struct rte_event_eth_rx_adapter_queue_conf
is applicable when the adapter uses a service core function. The application
has to enable Rx queue interrupts when configuring the ethernet device
using the ``rte_eth_dev_configure()`` function and then use a servicing_weight
-of zero when addding the Rx queue to the adapter.
+of zero when adding the Rx queue to the adapter.
The adapter creates a thread blocked on the interrupt, on an interrupt this
thread enqueues the port id and the queue id to a ring buffer. The adapter
@@ -180,9 +180,9 @@ Rx Callback for SW Rx Adapter
For SW based packet transfers, i.e., when the
``RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT`` is not set in the adapter's
capabilities flags for a particular ethernet device, the service function
-temporarily enqueues mbufs to an event buffer before batch enqueueing these
+temporarily enqueues mbufs to an event buffer before batch enqueuing these
to the event device. If the buffer fills up, the service function stops
-dequeueing packets from the ethernet device. The application may want to
+dequeuing packets from the ethernet device. The application may want to
monitor the buffer fill level and instruct the service function to selectively
enqueue packets to the event device. The application may also use some other
criteria to decide which packets should enter the event device even when
diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
index dcdfeb7..7ea14ba 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -42,7 +42,7 @@ The rte_event structure contains the following metadata fields, which the
application fills in to have the event scheduled as required:
* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
-* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``event_type`` - The source of this event, e.g. RTE_EVENT_TYPE_ETHDEV or CPU.
* ``sub_event_type`` - Distinguishes events inside the application, that have
the same event_type (see above)
* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
@@ -265,7 +265,7 @@ Linking Queues and Ports
The final step is to "wire up" the ports to the queues. After this, the
eventdev is capable of scheduling events, and when cores request work to do,
the correct events are provided to that core. Note that the RX core takes input
-from eg: a NIC so it is not linked to any eventdev queues.
+from e.g.: a NIC so it is not linked to any eventdev queues.
Linking all workers to atomic queues, and the TX core to the single-link queue
can be achieved like this:
@@ -276,7 +276,7 @@ can be achieved like this:
uint8_t tx_port_id = 5;
uint8_t atomic_qs[] = {0, 1};
uint8_t single_link_q = 2;
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
for(int worker_port_id = 1; worker_port_id <= 4; worker_port_id++) {
int links_made = rte_event_port_link(dev_id, worker_port_id, atomic_qs, NULL, 2);
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 84696d4..6fc0888 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -65,7 +65,7 @@ In that mode the library functions perform
- check SQN
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
- check padding data
- remove outer IP header (tunnel mode) / update IP header (transport mode)
@@ -88,7 +88,7 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
- check SQN
- check padding data
@@ -101,10 +101,10 @@ In that mode the library functions perform
- generate SQN and IV
- add outer IP header (tunnel mode) / update IP header (transport mode)
- add ESP header and trailer, padding and IV data
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -113,15 +113,15 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
* for outbound packets:
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ In that mode the library functions perform
* for inbound packets:
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
* for outbound packets:
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 7fcbd93..daf87f4 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -227,7 +227,7 @@ application functions:
``config_promiscusity``:
- Called when the user changes the promiscusity state of the KNI
+ Called when the user changes the promiscuity state of the KNI
interface. For example, when the user runs ``ip link set promisc
[on|off] dev <ifaceX>``. If the user sets this callback function to
NULL, but sets the ``port_id`` field to a value other than -1, a default
diff --git a/doc/guides/prog_guide/metrics_lib.rst b/doc/guides/prog_guide/metrics_lib.rst
index e68e4e7..89bc7d6 100644
--- a/doc/guides/prog_guide/metrics_lib.rst
+++ b/doc/guides/prog_guide/metrics_lib.rst
@@ -25,7 +25,7 @@ individual device. Since the metrics library is self-contained, the only
restriction on port numbers is that they are less than ``RTE_MAX_ETHPORTS``
- there is no requirement for the ports to actually exist.
-Initialising the library
+Initializing the library
------------------------
Before the library can be used, it has to be initialized by calling
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1384fe3..6196d3f 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -273,7 +273,7 @@ will be populated by IPC are as follows:
those peer processes that were active at the time of request, how many have
replied)
* ``msgs`` - pointer to where all of the responses are stored. The order in
- which responses appear is undefined. Whendoing sycnrhonous requests, this
+ which responses appear is undefined. When doing synchronous requests, this
memory must be freed by the requestor after request completes!
For asynchronous requests, a function pointer to the callback function must be
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 5af795c..a36ebef 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -64,7 +64,7 @@ The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
get a wall clock counter in user space. Typically it runs at <= 100MHz.
The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
-clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+clock counter is through the ARMv8 PMU subsystem. The PMU cycle counter runs
at CPU frequency. However, access to the PMU cycle counter from user space is
not enabled by default in the arm64 linux kernel. It is possible to enable
cycle counter for user space access by configuring the PMU from the privileged
@@ -75,7 +75,7 @@ scheme. Application can choose the PMU based implementation with
``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
The example below shows the steps to configure the PMU based cycle counter on
-an armv8 machine.
+an ARMv8 machine.
.. code-block:: console
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 0203f4f..937f52b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2129,7 +2129,7 @@ as defined in the ``rte_flow_action_raw_decap``
This action modifies the payload of matched flows. The data supplied must
be a valid header, either holding layer 2 data in case of removing layer 2
-before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
+before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
tunnel definition starting from layer 2 and moving to the tunnel item itself.
When applied to the original packet the resulting packet must be a
valid packet.
@@ -2279,7 +2279,7 @@ Action: ``DEC_TTL``
Decrease TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_dec_ttl:
@@ -2297,7 +2297,7 @@ Action: ``SET_TTL``
Assigns a new TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_set_ttl:
@@ -2725,7 +2725,7 @@ Caveats
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
-- There is no provision for reentrancy/multi-thread safety, although nothing
+- There is no provision for re-entrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index cb70caa..7d0734a 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -40,7 +40,7 @@ Inline Crypto
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
@@ -48,7 +48,7 @@ Ingress Data path - The packet is decrypted in RX path and relevant
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
arrived. The driver Rx path check the descriptors and and based on the
@@ -111,7 +111,7 @@ Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
@@ -119,7 +119,7 @@ Ingress Data path - The packet is decrypted in the RX path and relevant
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
@@ -132,7 +132,7 @@ to identify the security processing done on the packet.
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
@@ -150,7 +150,7 @@ to cross the MTU size.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
@@ -199,13 +199,13 @@ crypto device.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
@@ -217,7 +217,7 @@ for any protocol header addition.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
@@ -549,7 +549,7 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
struct rte_security_ipsec_sa_options options;
/**< various SA options */
enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
+ /**< IPsec SA Direction - Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< IPsec SA Protocol - AH/ESP */
enum rte_security_ipsec_sa_mode mode;
diff --git a/doc/guides/prog_guide/traffic_management.rst b/doc/guides/prog_guide/traffic_management.rst
index 98ac431..05b34d9 100644
--- a/doc/guides/prog_guide/traffic_management.rst
+++ b/doc/guides/prog_guide/traffic_management.rst
@@ -39,7 +39,7 @@ whether a specific implementation does meet the needs to the user application.
At the TM level, users can get high level idea with the help of various
parameters such as maximum number of nodes, maximum number of hierarchical
levels, maximum number of shapers, maximum number of private shapers, type of
-scheduling algorithm (Strict Priority, Weighted Fair Queueing , etc.), etc.,
+scheduling algorithm (Strict Priority, Weighted Fair Queuing , etc.), etc.,
supported by the implementation.
Likewise, users can query the capability of the TM at the hierarchical level to
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a86c07a..fc3ee43 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -63,7 +63,7 @@ The following is an overview of some key Vhost API functions:
512).
* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enableld).
+ boost could be above 70% (when TSO is enabled).
* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
PMD driver consume the mbuf but not release them timely.
diff --git a/doc/guides/rawdevs/ifpga_rawdev.rst b/doc/guides/rawdevs/ifpga_rawdev.rst
index d400db6..a3d92a6 100644
--- a/doc/guides/rawdevs/ifpga_rawdev.rst
+++ b/doc/guides/rawdevs/ifpga_rawdev.rst
@@ -91,7 +91,7 @@ Run-time parameters
-------------------
This driver is invoked automatically in systems added with Intel FPGA,
-but PR and IFPGA Bus scan is trigged by command line using
+but PR and IFPGA Bus scan is triggered by command line using
``--vdev 'ifpga_rawdev_cfg`` EAL option.
The following device parameters are supported:
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index 358dfa3..276327c 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -676,7 +676,7 @@ igb uio legacy mode can not be used in X710/XL710/XXV710
**Description**:
X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
- bit in the PCI status register. Linux delected them from INTx support table. The related
+ bit in the PCI status register. Linux deleted them from INTx support table. The related
`commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
**Implication**:
@@ -722,9 +722,9 @@ Linux kernel 4.10.0 iommu attribute read error
**Description**:
When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
/sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
- This bug is fixed in `Linux commmit a7fdb6e648fb
+ This bug is fixed in `Linux commit a7fdb6e648fb
<https://patchwork.kernel.org/patch/9595727/>`_,
- This bug is introduced in `Linux commmit 39ab9555c241
+ This bug is introduced in `Linux commit 39ab9555c241
<https://patchwork.kernel.org/patch/9554403/>`_,
**Implication**:
@@ -842,7 +842,7 @@ AVX-512 support disabled
drop.
On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
- on information accured from the GCC community defect.
+ on information accrued from the GCC community defect.
**Reason**:
Generated ``AVX-512`` code cause crash:
diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst
index 2a93af3..6448b6c 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -168,7 +168,7 @@ New Features
* The DES CBC algorithm.
* The DES DOCSIS BPI algorithm.
- This change requires version 0.47 of the IPSec Multi-buffer library. For
+ This change requires version 0.47 of the IPsec Multi-buffer library. For
more details see the :doc:`../cryptodevs/aesni_mb` documentation.
* **Updated the OpenSSL PMD.**
@@ -198,7 +198,7 @@ New Features
* **Added the Security Offload Library.**
Added an experimental library - ``rte_security``. This provide security APIs
- for protocols like IPSec using inline ipsec offload to ethernet devices or
+ for protocols like IPsec using inline ipsec offload to ethernet devices or
full protocol offload with lookaside crypto devices.
See the :doc:`../prog_guide/rte_security` section of the DPDK Programmers
@@ -207,11 +207,11 @@ New Features
* **Updated the DPAA2_SEC crypto driver to support rte_security.**
Updated the ``dpaa2_sec`` crypto PMD to support ``rte_security`` lookaside
- protocol offload for IPSec.
+ protocol offload for IPsec.
* **Updated the IXGBE ethernet driver to support rte_security.**
- Updated ixgbe ethernet PMD to support ``rte_security`` inline IPSec offload.
+ Updated ixgbe ethernet PMD to support ``rte_security`` inline IPsec offload.
* **Updated i40e driver to support GTP-C/GTP-U.**
@@ -509,7 +509,7 @@ ABI Changes
* **New parameter added to rte_eth_dev.**
A new parameter ``security_ctx`` has been added to ``rte_eth_dev`` to
- support security operations like IPSec inline.
+ support security operations like IPsec inline.
* **New parameter added to rte_cryptodev.**
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 40a3264..405e706 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -68,7 +68,7 @@ The application accepts a number of command line options:
where:
-* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2)
+* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2)
* ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4)
* ``p ETH_PORT_ID``: ethernet port ID (default = 0)
* ``b BBDEV_ID``: BBDev ID (default = 0)
@@ -87,7 +87,7 @@ issue the command:
$ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
--file-prefix=bbdev -- -e 0x10 -d 0x20
-where, NIC0PCIADDR is the PCI addresse of the Rx port
+where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index 0ec0290..dc7972a 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -49,7 +49,7 @@ these settings is shown below:
./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
-(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application
will print an error message:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index 159bcf7..9070419 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -106,7 +106,7 @@ examples are highlighted below.
(packet arrival) and TX (packet transmission) by adding callbacks to the RX
and TX packet processing functions.
-* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security
+* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security
Gateway application is minimal example of something closer to a real world
example. This is also a good example of an application using the DPDK
Cryptodev framework.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 447a544..4da0fcf 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -113,7 +113,7 @@ Application stages
Initialization
~~~~~~~~~~~~~~
-During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures
+During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures
(i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message
is displayed and the application is terminated.
@@ -185,7 +185,7 @@ Examples
+-----------------------+----------------------+----------------+------------------------------------+
| IP routing | LPM (IPv4) | Forward | 1. Mempool Create |
| | | | 2. Link create |
- | | * Key = IP dest addr | | 3. Pipeline creat |
+ | | * Key = IP dest addr | | 3. Pipeline create |
| | * Offset = 286 | | 4. Pipeline port in/out |
| | * Table size = 4K | | 5. Pipeline table |
| | | | 6. Pipeline port in table |
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 3d784e7..ac118c1 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*.
Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
@@ -124,7 +124,7 @@ Where:
* ``-e``: enables Security Association extended sequence number processing
(available only with librte_ipsec code path).
-* ``-a``: enables Security Association sequence number atomic behaviour
+* ``-a``: enables Security Association sequence number atomic behavior
(available only with librte_ipsec code path).
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
@@ -752,7 +752,7 @@ DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
-It then tries to perform some data transfer using the scheme decribed above.
+It then tries to perform some data transfer using the scheme described above.
usage
~~~~~
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index e2c04ef..ac6ee8a 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in
the L-thread struct.
For legacy and backward compatibility reasons two alternative methods are also
-offered, the first is modelled directly on the pthread get/set specific APIs,
-the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby
+offered, the first is modeled directly on the pthread get/set specific APIs,
+the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby
``PER_LTHREAD`` macros are introduced, in both cases the storage is local to
the L-thread.
diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst
index 2e8e017..d75f7da 100644
--- a/doc/guides/sample_app_ug/qos_metering.rst
+++ b/doc/guides/sample_app_ug/qos_metering.rst
@@ -151,5 +151,5 @@ In this particular case:
* For the rest of the cases, the color is changed to red.
.. note::
- * In color blind mode, first row GREEN colour is only valid.
+ * In color blind mode, first row GREEN color is only valid.
* To drop the packet, policer_table action has to be set to DROP.
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 5f313c5..5aefd8d 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -32,7 +32,7 @@ Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`
-The application is located in the ``$RTE_SDK/app/test-pipline`` directory.
+The application is located in the ``$RTE_SDK/app/test-pipeline`` directory.
Running the Application
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df4d6f9..a71ada6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file.
The vm2vm parameter sets the mode of packet switching between guests in
the host.
-- 0 disables vm2vm, impling that VM's packets will always go to the NIC port.
+- 0 disables vm2vm, implying that VM's packets will always go to the NIC port.
- 1 means a normal mac lookup packet routing.
- 2 means hardware mode packet forwarding between guests, it allows packets
go to the NIC port, hardware L2 switch will determine which guest the
@@ -148,7 +148,7 @@ default value is 15.
**--dequeue-zero-copy**
Dequeue zero copy will be enabled when this option is given. it is worth to
-note that if NIC is binded to driver with iommu enabled, dequeue zero copy
+note that if NIC is bound to driver with iommu enabled, dequeue zero copy
cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu
dma mapping for guest memory.
diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst
index 7ab7d0d..6b9bf62 100644
--- a/doc/guides/sample_app_ug/vhost_scsi.rst
+++ b/doc/guides/sample_app_ug/vhost_scsi.rst
@@ -63,7 +63,7 @@ Vhost_scsi Common Issues
* vhost_scsi can not start with block size 512 Bytes:
- Currently DPDK vhost library was designed for NET device(althrough the APIs
+ Currently DPDK vhost library was designed for NET device(although the APIs
are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced
Disk Device) will enumerate all block device and do some IOs to those block
devices with 512 Bytes sector size. DPDK vhost library can not process such
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e..109d109 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -344,7 +344,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs.
When this parameter is used, the list of cores specified will monitor the ratio
between branch hits and branch misses. A tightly polling PMD thread will have a
- very low branch ratio, so the core frequency will be scaled down to the minimim
+ very low branch ratio, so the core frequency will be scaled down to the minimum
allowed value. When packets are received, the code path will alter, causing the
branch ratio to increase. When the ratio goes above the ratio threshold, the
core frequency will be scaled up to the maximum allowed value.
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The JSON string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -734,7 +734,7 @@ policy down to the host application. These parameters are as follows:
A comma-separated list of cores in the VM that the user wants the host application to
monitor. The list of cores in any vm starts at zero, and these are mapped to the
physical cores by the host application once the policy is passed down.
- Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a
+ Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a
combination of both '1,3,5-7'
.. code-block:: console
@@ -742,7 +742,7 @@ policy down to the host application. These parameters are as follows:
--busy-hours {list of busy hours}
A comma-separated list of hours within which to set the core frequency to maximum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
@@ -750,7 +750,7 @@ policy down to the host application. These parameters are as follows:
--quiet-hours {list of quiet hours}
A comma-separated list of hours within which to set the core frequency to minimum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index fdf6ec7..e7db520 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -381,7 +381,7 @@ The command line options are:
* ``--hot-plug``
- Enable device event monitor mechanism for hot plug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -421,23 +421,23 @@ The command line options are:
* ``--noisy-lkup-memory=N``
- Set the size of the noisy neighbour simulation memory buffer in MB to N.
+ Set the size of the noisy neighbor simulation memory buffer in MB to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads=N``
- Set the number of reads to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of reads to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-writes=N``
- Set the number of writes to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of writes to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads-writes=N``
- Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of r/w accesses to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--no-iova-contig``
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 5d4dc6f..e602df5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -303,7 +303,7 @@ The available information categories are:
This is the default mode.
* ``mac``: Changes the source and the destination Ethernet addresses of packets before forwarding them.
- Default application behaviour is to set source Ethernet address to that of the transmitting interface, and destination
+ Default application behavior is to set source Ethernet address to that of the transmitting interface, and destination
address to a dummy value (set during init). The user may specify a target destination Ethernet address via the 'eth-peer' or
'eth-peers-configfile' command-line options. It is not currently possible to specify a specific source Ethernet address.
@@ -326,7 +326,7 @@ The available information categories are:
* ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is
similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``.
-* ``noisy``: Noisy neighbour simulation.
+* ``noisy``: Noisy neighbor simulation.
Simulate more realistic behavior of a guest machine engaged in receiving
and sending packets performing Virtual Network Function (VNF).
@@ -2289,7 +2289,7 @@ set bonding lacp dedicated_queue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
-when in mode 4 (link-aggregration-802.3ad)::
+when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
@@ -2297,7 +2297,7 @@ when in mode 4 (link-aggregration-802.3ad)::
set bonding agg_mode
~~~~~~~~~~~~~~~~~~~~
-Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+Enable one of the specific aggregators mode when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
@@ -2691,8 +2691,8 @@ where:
* ``shared_shaper_id``: Shared shaper ID to be deleted.
-Set port traffic management hiearchy node private shaper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Set port traffic management hierarchy node private shaper
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
set the port traffic management hierarchy node private shaper::
@@ -2743,7 +2743,7 @@ Delete the WRED profile::
Add port traffic management hierarchy nonleaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add nonleaf node to port traffic management hiearchy::
+Add nonleaf node to port traffic management hierarchy::
testpmd> add port tm nonleaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2758,7 +2758,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``n_sp_priorities``: Number of strict priorities.
@@ -2769,7 +2769,7 @@ where:
Add port traffic management hierarchy leaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add leaf node to port traffic management hiearchy::
+Add leaf node to port traffic management hierarchy::
testpmd> add port tm leaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2784,7 +2784,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``cman_mode``: Congestion management mode to be enabled for this node.
@@ -2796,7 +2796,7 @@ where:
Delete port traffic management hierarchy node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Delete node from port traffic management hiearchy::
+Delete node from port traffic management hierarchy::
testpmd> del port tm node (port_id) (node_id)
@@ -3989,7 +3989,7 @@ This section lists supported actions and their attributes, if any.
- ``dec_ttl``: Performs a decrease TTL value action
-- ``set_ttl``: Set TTL value with specificed value
+- ``set_ttl``: Set TTL value with specified value
- ``ttl_value {unsigned}``: The new TTL value to be set
- ``set_mac_src``: set source MAC address
@@ -4522,7 +4522,7 @@ The following sections show functions to load/unload eBPF based filters.
bpf-load
~~~~~~~~
-Load an eBPF program as a callback for partciular RX/TX queue::
+Load an eBPF program as a callback for particular RX/TX queue::
testpmd> bpf-load rx|tx (portid) (queueid) (load-flags) (bpf-prog-filename)
@@ -4560,7 +4560,7 @@ To load (not JITed) t1.o at TX queue 0, port 0::
bpf-unload
~~~~~~~~~~
-Unload previously loaded eBPF program for partciular RX/TX queue::
+Unload previously loaded eBPF program for particular RX/TX queue::
testpmd> bpf-unload rx|tx (portid) (queueid)
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index c366af4..2fc6544 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -59,7 +59,7 @@ To set on the linearization options add below definition to the
**Step 3: Build the application**
Execute the ``dpdk-setup.sh`` script to build the DPDK library together with the
-``dpdk-test-crypto-perf`` applcation.
+``dpdk-test-crypto-perf`` application.
Initially, the user must select a DPDK target to choose the correct target type
and compiler options to use when building the libraries.
@@ -80,7 +80,7 @@ EAL Options
~~~~~~~~~~~
The following are the EAL command-line options that can be used in conjunction
-with the ``dpdk-test-crypto-perf`` applcation.
+with the ``dpdk-test-crypto-perf`` application.
See the DPDK Getting Started Guides for more information on these options.
* ``-c <COREMASK>`` or ``-l <CORELIST>``
@@ -96,10 +96,10 @@ See the DPDK Getting Started Guides for more information on these options.
Add a virtual device.
-Appication Options
-~~~~~~~~~~~~~~~~~~
+Application Options
+~~~~~~~~~~~~~~~~~~~
-The following are the appication command-line options:
+The following are the application command-line options:
* ``--ptest type``
@@ -338,13 +338,13 @@ Test Vector File
The test vector file is a text file contain information about test vectors.
The file is made of the sections. The first section doesn't have header.
It contain global information used in each test variant vectors -
-typically information about plaintext, ciphertext, cipher key, aut key,
+typically information about plaintext, ciphertext, cipher key, auth key,
initial vector. All other sections begin header.
The sections contain particular information typically digest.
**Format of the file:**
-Each line beginig with sign '#' contain comment and it is ignored by parser::
+Each line beginning with sign '#' contain comment and it is ignored by parser::
# <comment>
@@ -352,16 +352,16 @@ Header line is just name in square bracket::
[<section name>]
-Data line contain information tocken then sign '=' and
+Data line contain information token then sign '=' and
a string of bytes in C byte array format::
- <tocken> = <C byte array>
+ <token> = <C byte array>
-**Tockens list:**
+**Tokens list:**
* ``plaintext``
- Original plaintext to be crypted.
+ Original plaintext to be encrypted.
* ``ciphertext``
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index 6bdf5a8..2ea1b59 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -44,7 +44,7 @@ If no port mask is specified xstats are reset for all DPDK ports.
**-m**: Print DPDK memory information.
**--show-port**
-The show-port parameter displays port level various configuration informationi
+The show-port parameter displays port level various configuration information
associated to RX port queue pair.
**--show-tm**
@@ -56,7 +56,7 @@ The show-crypto parameter displays available cryptodev configurations,
settings and stats per node.
**--show-ring[=name]**
-The show-ring pararmeter display current allocation of all ring with
+The show-ring parameter display current allocation of all ring with
debug information. Specifying the name allows to display details for specific
ring. For invalid or no ring name, whole list is dump.
@@ -76,7 +76,7 @@ Limitations
* When running ``dpdk-procinfo`` with shared library mode, it is required to
pass the same NIC PMD libraries as used for the primary application. Any
- mismatch in PMD library arguments can lead to undefined behaviour and results
+ mismatch in PMD library arguments can lead to undefined behavior and results
affecting primary application too.
* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP.
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 07da35e..7e6a4db 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -139,7 +139,7 @@ There are 6 main test cases that can be executed using testbbdev tool:
* Latency measurement [-c latency]
- Measures the time consumed from the first enqueue until the first
appearance of a dequeued result
- - This measurment represents the full latency of a bbdev operation
+ - This measurement represents the full latency of a bbdev operation
(encode or decode) to execute
* Poll-mode Throughput measurement [-c throughput]
--
2.7.5
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell
2019-04-03 13:26 4% [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell John McNamara
@ 2019-04-03 13:26 4% ` John McNamara
0 siblings, 0 replies; 53+ 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 4%]
* [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell
@ 2019-04-03 13:26 4% John McNamara
2019-04-03 13:26 4% ` John McNamara
0 siblings, 1 reply; 53+ 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 4%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 18.05
@ 2018-05-30 20:25 16% John McNamara
0 siblings, 0 replies; 53+ results
From: John McNamara @ 2018-05-30 20:25 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix grammar, spelling and formatting of DPDK 18.05 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_18_05.rst | 308 +++++++++++++++++----------------
1 file changed, 157 insertions(+), 151 deletions(-)
diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst
index 42a5b37..b24217e 100644
--- a/doc/guides/rel_notes/release_18_05.rst
+++ b/doc/guides/rel_notes/release_18_05.rst
@@ -45,7 +45,7 @@ New Features
Memory subsystem has been reworked to support new functionality.
- On Linux, support for reserving/unreserving hugepage memory at runtime was
+ On Linux, support for reserving/unreserving hugepage memory at runtime has been
added, so applications no longer need to pre-reserve memory at startup. Due to
reorganized internal workings of memory subsystem, any memory allocated
through ``rte_malloc()`` or ``rte_memzone_reserve()`` is no longer guaranteed
@@ -53,64 +53,64 @@ New Features
This functionality has introduced the following changes:
- * ``rte_eal_get_physmem_layout()`` was removed
+ * ``rte_eal_get_physmem_layout()`` was removed.
* A new flag for memzone reservation (``RTE_MEMZONE_IOVA_CONTIG``) was added
to ensure reserved memory will be IOVA-contiguous, for use with device
- drivers and other cases requiring such memory
- * New callbacks for memory allocation/deallocation events, allowing user (or
+ drivers and other cases requiring such memory.
+ * New callbacks for memory allocation/deallocation events, allowing users (or
drivers) to be notified of new memory being allocated or deallocated
- * New callbacks for validating memory allocations above specified limit,
- allowing user to permit or deny memory allocations
+ * New callbacks for validating memory allocations above a specified limit,
+ allowing user to permit or deny memory allocations.
* A new command-line switch ``--legacy-mem`` to enable EAL behavior similar to
how older versions of DPDK worked (memory segments that are IOVA-contiguous,
- but hugepages are reserved at startup only, and can never be released)
+ but hugepages are reserved at startup only, and can never be released).
* A new command-line switch ``--single-file-segments`` to put all memory
- segments within a segment list in a single file
+ segments within a segment list in a single file.
* A set of convenience function calls to look up and iterate over allocated
- memory segments
+ memory segments.
* ``-m`` and ``--socket-mem`` command-line arguments now carry an additional
meaning and mark pre-reserved hugepages as "unfree-able", thereby acting as
a mechanism guaranteeing minimum availability of hugepage memory to the
- application
+ application.
Reserving/unreserving memory at runtime is not currently supported on FreeBSD.
* **Added bucket mempool driver.**
- Added bucket mempool driver which provides a way to allocate contiguous
+ Added a bucket mempool driver which provides a way to allocate contiguous
block of objects.
- Number of objects in the block depends on how many objects fit in
- RTE_DRIVER_MEMPOOL_BUCKET_SIZE_KB memory chunk which is build time option.
- The number may be obtained using rte_mempool_ops_get_info() API.
- Contiguous blocks may be allocated using rte_mempool_get_contig_blocks() API.
+ The number of objects in the block depends on how many objects fit in the
+ ``RTE_DRIVER_MEMPOOL_BUCKET_SIZE_KB`` memory chunk which is a build time option.
+ The number may be obtained using ``rte_mempool_ops_get_info()`` API.
+ Contiguous blocks may be allocated using ``rte_mempool_get_contig_blocks()`` API.
* **Added support for port representors.**
- The DPDK port representors (also known as "VF representors" in the specific
+ Added DPDK port representors (also known as "VF representors" in the specific
context of VFs), which are to DPDK what the Ethernet switch device driver
model (**switchdev**) is to Linux, and which can be thought as a software
"patch panel" front-end for applications. DPDK port representors are
implemented as additional virtual Ethernet device (**ethdev**) instances,
- spawned on an as needed basis through configuration parameters passed to the
+ spawned on an as-needed basis through configuration parameters passed to the
driver of the underlying device using devargs.
* **Added support for VXLAN and NVGRE tunnel endpoint.**
New actions types have been added to support encapsulation and decapsulation
operations for a tunnel endpoint. The new action types are
- RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP, RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP,
- RTE_FLOW_ACTION_TYPE_JUMP. New item type RTE_FLOW_ACTION_TYPE_MARK has been
- added to match a flow against a previously marked flow. It also introduced shared
- counter to flow API to counte for a group of flows.
+ ``RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP``, ``RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP``,
+ ``RTE_FLOW_ACTION_TYPE_JUMP``. A new item type ``RTE_FLOW_ACTION_TYPE_MARK`` has been
+ added to match a flow against a previously marked flow. A shared counter has also been
+ introduced to the flow API to count a group of flows.
-* **Added PMD-recommended Tx and Rx parameters**
+* **Added PMD-recommended Tx and Rx parameters.**
Applications can now query drivers for device-tuned values of
ring sizes, burst sizes, and number of queues.
* **Added RSS hash and key update to CXGBE PMD.**
- Support to update RSS hash and key has been added to CXGBE PMD.
+ Added support for updating the RSS hash and key to the CXGBE PMD.
* **Added CXGBE VF PMD.**
@@ -121,29 +121,29 @@ New Features
Updated the mlx5 driver including the following changes:
- * Introduced Multi-packet Rx. With it, achieved 100Gb/sec with 64B frames.
- * Supported to be run by non-root users given reduced set of capabilities
- CAP_NET_ADMIN, CAP_NET_RAW and CAP_IPC_LOCK.
- * Supported TSO and checksum for generic UDP and IP tunnels.
- * Supported inner checksum and RSS for GRE, VXLAN-GPE, MPLSoGRE
+ * Introduced Multi-packet Rx to enable 100Gb/sec with 64B frames.
+ * Support for being run by non-root users given a reduced set of capabilities
+ ``CAP_NET_ADMIN``, ``CAP_NET_RAW`` and ``CAP_IPC_LOCK``.
+ * Support for TSO and checksum for generic UDP and IP tunnels.
+ * Support for inner checksum and RSS for GRE, VXLAN-GPE, MPLSoGRE
and MPLSoUDP tunnels.
- * Accommodate to the new memory hotplug model.
- * Supported non virtually contiguous mempools.
- * Supported MAC adding along with allmulti and promiscuous modes from VF.
- * Supported Mellanox BlueField SoC device.
- * Supported PMD defaults for queue number and depth to improve the out
+ * Accommodate the new memory hotplug model.
+ * Support for non virtually contiguous mempools.
+ * Support for MAC adding along with allmulti and promiscuous modes from VF.
+ * Support for Mellanox BlueField SoC device.
+ * Support for PMD defaults for queue number and depth to improve the out
of the box performance.
* **Updated mlx4 driver.**
Updated the mlx4 driver including the following changes:
- * Supported to be run by non-root users given reduced set of capabilities
- CAP_NET_ADMIN, CAP_NET_RAW and CAP_IPC_LOCK.
+ * Support for to being run by non-root users given a reduced set of capabilities
+ ``CAP_NET_ADMIN``, ``CAP_NET_RAW`` and ``CAP_IPC_LOCK``.
* Supported CRC strip toggling.
- * Accommodate to the new memory hotplug model.
- * Supported non virtually contiguous mempools.
- * Dropped support in Mellanox OFED 4.2.
+ * Accommodate the new memory hotplug model.
+ * Support non virtually contiguous mempools.
+ * Dropped support for Mellanox OFED 4.2.
* **Updated Solarflare network PMD.**
@@ -164,58 +164,61 @@ New Features
* **Updated szedata2 PMD.**
Added support for new NFB-200G2QL card.
- New API was introduced in the libsze2 library which the szedata2 PMD depends
- on thus the new version of the library was needed.
+ A new API was introduced in the libsze2 library which the szedata2 PMD depends
+ on, thus the new version of the library was needed.
New versions of the packages are available and the minimum required version
is 4.4.1.
-* **Added support for Broadcom NetXtreme-S (BCM58800) family of controllers (aka Stingray)**
+* **Added support for Broadcom NetXtreme-S (BCM58800) family of controllers (aka Stingray).**
- The BCM58800 devices feature a NetXtreme E-Series advanced network controller, a high-performance
- ARM CPU block, PCI Express (PCIe) Gen3 interfaces, key accelerators for compute offload and a high-
- speed memory subsystem including L3 cache and DDR4 interfaces, all interconnected by a coherent
- Network-on-chip (NOC) fabric.
+ Added support for the Broadcom NetXtreme-S (BCM58800) family of controllers
+ (aka Stingray). The BCM58800 devices feature a NetXtreme E-Series advanced
+ network controller, a high-performance ARM CPU block, PCI Express (PCIe)
+ Gen3 interfaces, key accelerators for compute offload and a high-speed
+ memory subsystem including L3 cache and DDR4 interfaces, all interconnected
+ by a coherent Network-on-chip (NOC) fabric.
- The ARM CPU subsystem features eight ARMv8 Cortex-A72 CPUs at 3.0 GHz, arranged in a multi-cluster
- configuration.
+ The ARM CPU subsystem features eight ARMv8 Cortex-A72 CPUs at 3.0 GHz,
+ arranged in a multi-cluster configuration.
* **Added vDPA in vhost-user lib.**
- Added support for selective datapath in vhost-user lib. vDPA stands for vhost
+ Added support for selective datapath in the vhost-user lib. vDPA stands for vhost
Data Path Acceleration. It supports virtio ring compatible devices to serve
- virtio driver directly to enable datapath acceleration.
+ the virtio driver directly to enable datapath acceleration.
* **Added IFCVF vDPA driver.**
- Added IFCVF vDPA driver to support Intel FPGA 100G VF device. IFCVF works
+ Added IFCVF vDPA driver to support Intel FPGA 100G VF devices. IFCVF works
as a HW vhost data path accelerator, it supports live migration and is
- compatible with virtio 0.95 and 1.0. This driver registers ifcvf vDPA driver
- to vhost lib, when virtio connected, with the help of the registered vDPA
+ compatible with virtio 0.95 and 1.0. This driver registers the ifcvf vDPA driver
+ to vhost lib, when virtio connects. With the help of the registered vDPA
driver the assigned VF gets configured to Rx/Tx directly to VM's virtio
vrings.
* **Added support for vhost dequeue interrupt mode.**
- Added support for vhost dequeue interrupt mode to release cpus to others when
- no data to transmit. Applications could register an epoll event fd to associate
- Rx queues with interrupt vectors.
+ Added support for vhost dequeue interrupt mode to release CPUs to others
+ when there is no data to transmit. Applications can register an epoll event
+ file descriptor to associate Rx queues with interrupt vectors.
* **Added support for virtio-user server mode.**
+
In a container environment if the vhost-user backend restarts, there's no way
for it to reconnect to virtio-user. To address this, support for server mode
- is added. In this mode the socket file is created by virtio-user, which the
+ has been added. In this mode the socket file is created by virtio-user, which the
backend connects to. This means that if the backend restarts, it can reconnect
to virtio-user and continue communications.
* **Added crypto workload support to vhost library.**
- New APIs are introduced in vhost library to enable virtio crypto support
+ New APIs have been introduced in the vhost library to enable virtio crypto support
including session creation/deletion handling and translating virtio-crypto
- request into DPDK crypto operations. A sample application is also introduced.
+ requests into DPDK crypto operations. A sample application has also been introduced.
* **Added virtio crypto PMD.**
- Added a new poll mode driver for virtio crypto devices, which provides
+ Added a new Poll Mode Driver for virtio crypto devices, which provides
AES-CBC ciphering and AES-CBC with HMAC-SHA1 algorithm-chaining. See the
:doc:`../cryptodevs/virtio` crypto driver guide for more details on
this new driver.
@@ -232,9 +235,9 @@ New Features
* AES-CMAC (128-bit key).
-* **Added Compressdev Library, a generic compression service library.**
+* **Added the Compressdev Library, a generic compression service library.**
- The compressdev library provides an API for offload of compression and
+ Added the Compressdev library which provides an API for offload of compression and
decompression operations to hardware or software accelerator devices.
* **Added a new compression poll mode driver using Intels ISA-L.**
@@ -253,36 +256,36 @@ New Features
* **Added OcteonTx TIM Driver (Event timer adapter).**
The OcteonTx Timer block enables software to schedule events for a future
- time, it is exposed to an application via Event timer adapter library.
+ time, it is exposed to an application via the Event timer adapter library.
See the :doc:`../eventdevs/octeontx` guide for more details
* **Added Event Crypto Adapter Library.**
- Added the Event Crypto Adapter Library. This library extends the
- event-based model by introducing APIs that allow applications to
- enqueue/dequeue crypto operations to/from cryptodev as events scheduled
- by an event device.
+ Added the Event Crypto Adapter Library. This library extends the
+ event-based model by introducing APIs that allow applications to
+ enqueue/dequeue crypto operations to/from cryptodev as events scheduled
+ by an event device.
* **Added Ifpga Bus, a generic Intel FPGA Bus library.**
- The Ifpga Bus library provides support for integrating any Intel FPGA device with
- the DPDK framework. It provides Intel FPGA Partial Bit Stream AFU (Accelerated
- Function Unit) scan and drivers probe.
+ Added the Ifpga Bus library which provides support for integrating any Intel
+ FPGA device with the DPDK framework. It provides Intel FPGA Partial Bit
+ Stream AFU (Accelerated Function Unit) scan and drivers probe.
* **Added IFPGA (Intel FPGA) Rawdev Driver.**
- Added a new Rawdev driver called IFPGA(Intel FPGA) Rawdev Driver, which cooperates
- with OPAE (Open Programmable Acceleration Engine) share code provides common FPGA
+ Added a new Rawdev driver called IFPGA (Intel FPGA) Rawdev Driver, which cooperates
+ with OPAE (Open Programmable Acceleration Engine) shared code to provide common FPGA
management ops for FPGA operation.
See the :doc:`../rawdevs/ifpga_rawdev` programmer's guide for more details.
* **Added DPAA2 QDMA Driver (in rawdev).**
- The DPAA2 QDMA is an implementation of the rawdev API, that provide means
- to initiate a DMA transaction from CPU. The initiated DMA is performed
- without CPU being involved in the actual DMA transaction.
+ The DPAA2 QDMA is an implementation of the rawdev API, that provide a means
+ of initiating a DMA transaction from CPU. The initiated DMA is performed
+ without the CPU being involved in the actual DMA transaction.
See the :doc:`../rawdevs/dpaa2_qdma` guide for more details.
@@ -290,8 +293,8 @@ New Features
The DPAA2 CMDIF is an implementation of the rawdev API, that provides
communication between the GPP and NXP's QorIQ based AIOP Block (Firmware).
- Advanced IO Processor i.e. AIOP is clusters of programmable RISC engines
- optimised for flexible networking and I/O operations. The communication
+ Advanced IO Processor i.e. AIOP are clusters of programmable RISC engines
+ optimized for flexible networking and I/O operations. The communication
between GPP and AIOP is achieved via using DPCI devices exposed by MC for
GPP <--> AIOP interaction.
@@ -299,26 +302,27 @@ New Features
* **Added device event monitor framework.**
- Added a general device event monitor framework at EAL, for device dynamic management.
- Such as device hotplug awareness and actions adopted accordingly. The list of new APIs:
+ Added a general device event monitor framework to EAL, for device dynamic
+ management to facilitate device hotplug awareness and associated
+ actions. The list of new APIs is:
- * ``rte_dev_event_monitor_start`` and ``rte_dev_event_monitor_stop`` are for
- the event monitor enable and disable.
+ * ``rte_dev_event_monitor_start`` and ``rte_dev_event_monitor_stop`` for
+ the event monitor enabling and disabling.
* ``rte_dev_event_callback_register`` and ``rte_dev_event_callback_unregister``
- are for the user's callbacks register and unregister.
+ for registering and un-registering user callbacks.
- Linux uevent is supported as backend of this device event notification framework.
+ Linux uevent is supported as a backend of this device event notification framework.
* **Added support for procinfo and pdump on eth vdev.**
- For ethernet virtual devices (like tap, pcap, etc), with this feature, we can get
- stats/xstats on shared memory from secondary process, and also pdump packets on
+ For ethernet virtual devices (like TAP, PCAP, etc.), with this feature, we can get
+ stats/xstats on shared memory from a secondary process, and also pdump packets on
those virtual devices.
-* **Advancement to Packet Framework Library.**
+* **Enhancements to the Packet Framework Library.**
Design and development of new API functions for Packet Framework library that
- implements common set of actions such as traffic metering, packet
+ implement a common set of actions such as traffic metering, packet
encapsulation, network address translation, TTL update, etc., for pipeline
table and input ports to speed up application development. The API functions
includes creating action profiles, registering actions to the profiles,
@@ -327,10 +331,10 @@ New Features
* **Added the BPF Library.**
The BPF Library provides the ability to load and execute
- Enhanced Berkeley Packet Filter (eBPF) within user-space dpdk application.
- Also it introduces basic framework to load/unload BPF-based filters
- on eth devices (right now only via SW RX/TX callbacks).
- It also adds dependency on libelf.
+ Enhanced Berkeley Packet Filters (eBPF) within user-space DPDK applications.
+ It also introduces a basic framework to load/unload BPF-based filters
+ on Eth devices (right now only via SW RX/TX callbacks).
+ It also adds a dependency on libelf.
API Changes
@@ -346,28 +350,28 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
-* service cores: no longer marked as experimental.
+* service cores: Service cores no longer marked as experimental.
The service cores functions are no longer marked as experimental, and have
become part of the normal DPDK API and ABI. Any future ABI changes will be
announced at least one release before the ABI change is made. There are no
ABI breaking changes planned.
-* eal: ``rte_lcore_has_role()`` return value changed.
+* eal: The ``rte_lcore_has_role()`` return value changed.
This function now returns true or false, respectively,
- rather than 0 or <0 for success or failure.
+ rather than 0 or < 0 for success or failure.
It makes use of the function more intuitive.
-* mempool: capability flags and related functions have been removed.
+* mempool: The capability flags and related functions have been removed.
Flags ``MEMPOOL_F_CAPA_PHYS_CONTIG`` and
``MEMPOOL_F_CAPA_BLK_ALIGNED_OBJECTS`` were used by octeontx mempool
- driver to customize generic mempool library behaviour.
+ driver to customize generic mempool library behavior.
Now the new driver callbacks ``calc_mem_size`` and ``populate`` may be
used to achieve it without specific knowledge in the generic code.
-* mempool: xmem functions have been deprecated:
+* mempool: The following xmem functions have been deprecated:
- ``rte_mempool_xmem_create``
- ``rte_mempool_xmem_size``
@@ -387,59 +391,59 @@ API Changes
The packet mbuf API should be used as a replacement.
-* meter: updated to accommodate configuration profiles.
+* meter: API updated to accommodate configuration profiles.
- The meter API is changed to support meter configuration profiles. The
+ The meter API has been changed to support meter configuration profiles. The
configuration profile represents the set of configuration parameters
for a given meter object, such as the rates and sizes for the token
- buckets. These configuration parameters were previously the part of meter
- object internal data strcuture. The separation of the configuration
- parameters from meter object data structure results in reducing its
- memory footprint which helps in better cache utilization when large number
+ buckets. These configuration parameters were previously part of the meter
+ object internal data structure. The separation of the configuration
+ parameters from the meter object data structure results in reducing its
+ memory footprint which helps in better cache utilization when a large number
of meter objects are used.
-* ethdev: The function ``rte_eth_dev_count``, often mis-used to iterate
- over ports, is deprecated and replaced by ``rte_eth_dev_count_avail``.
- There is also a new function ``rte_eth_dev_count_total`` to get the
+* ethdev: The function ``rte_eth_dev_count()``, often mis-used to iterate
+ over ports, is deprecated and replaced by ``rte_eth_dev_count_avail()``.
+ There is also a new function ``rte_eth_dev_count_total()`` to get the
total number of allocated ports, available or not.
The hotplug-proof applications should use ``RTE_ETH_FOREACH_DEV`` or
``RTE_ETH_FOREACH_DEV_OWNED_BY`` as port iterators.
-* ethdev, in struct ``struct rte_eth_dev_info``, field ``rte_pci_device *pci_dev``
- replaced with field ``struct rte_device *device``.
+* ethdev: In struct ``struct rte_eth_dev_info``, field ``rte_pci_device *pci_dev``
+ has been replaced with field ``struct rte_device *device``.
-* **Changes to semantics of rte_eth_dev_configure() parameters.**
+* Changes to the semantics of ``rte_eth_dev_configure()`` parameters.
- If both the ``nb_rx_q`` and ``nb_tx_q`` parameters are zero,
- ``rte_eth_dev_configure`` will now use PMD-recommended queue sizes, or if
- recommendations are not provided by the PMD the function will use ethdev
- fall-back values. Previously setting both of the parameters to zero would
- have resulted in ``-EINVAL`` being returned.
+ If both the ``nb_rx_q`` and ``nb_tx_q`` parameters are zero,
+ ``rte_eth_dev_configure()`` will now use PMD-recommended queue sizes, or if
+ recommendations are not provided by the PMD the function will use ethdev
+ fall-back values. Previously setting both of the parameters to zero would
+ have resulted in ``-EINVAL`` being returned.
-* **Changes to semantics of rte_eth_rx_queue_setup() parameters.**
+* Changes to the semantics of ``rte_eth_rx_queue_setup()`` parameters.
- If the ``nb_rx_desc`` parameter is zero, ``rte_eth_rx_queue_setup`` will
- now use the PMD-recommended Rx ring size, or in the case where the PMD
- does not provide a recommendation, will use an ethdev-provided
- fall-back value. Previously, setting ``nb_rx_desc`` to zero would have
- resulted in an error.
+ If the ``nb_rx_desc`` parameter is zero, ``rte_eth_rx_queue_setup`` will
+ now use the PMD-recommended Rx ring size, or in the case where the PMD
+ does not provide a recommendation, will use an ethdev-provided
+ fall-back value. Previously, setting ``nb_rx_desc`` to zero would have
+ resulted in an error.
-* **Changes to semantics of rte_eth_tx_queue_setup() parameters.**
+* Changes to the semantics of ``rte_eth_tx_queue_setup()`` parameters.
If the ``nb_tx_desc`` parameter is zero, ``rte_eth_tx_queue_setup`` will
now use the PMD-recommended Tx ring size, or in the case where the PMD
- does not provide a recoomendation, will use an ethdev-provided
+ does not provide a recommendation, will use an ethdev-provided
fall-back value. Previously, setting ``nb_tx_desc`` to zero would have
resulted in an error.
* ethdev: several changes were made to the flow API.
- * Unused DUP action was removed.
+ * The unused DUP action was removed.
* Actions semantics in flow rules: list order now matters ("first
to last" instead of "all simultaneously"), repeated actions are now
all performed, and they do not individually have (non-)terminating
properties anymore.
- * Flow rules are now always terminating unless a PASSTHRU action is
+ * Flow rules are now always terminating unless a ``PASSTHRU`` action is
present.
* C99-style flexible arrays were replaced with standard pointers in RSS
action and in RAW pattern item structures due to compatibility issues.
@@ -458,7 +462,7 @@ API Changes
* A new transfer attribute was added to ``struct rte_flow_attr`` in order
to clarify the behavior of some pattern items.
* PF and VF pattern items are now only accepted by PMDs that implement
- them (bnxt and i40e) when the transfer attribute is also present for
+ them (bnxt and i40e) when the transfer attribute is also present, for
consistency.
* Pattern item PORT was renamed PHY_PORT to avoid confusion with DPDK port
IDs.
@@ -466,16 +470,17 @@ API Changes
redirect matching traffic to a specific physical port.
* PORT_ID pattern item and actions were added to match and target DPDK
port IDs at a higher level than PHY_PORT.
- * RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP action items were added to support
+ * ``RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP`` action items were added to support
tunnel encapsulation operation for VXLAN and NVGRE type tunnel endpoint.
- * RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP action items were added to support
+ * ``RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP`` action items were added to support
tunnel decapsulation operation for VXLAN and NVGRE type tunnel endpoint.
- * RTE_FLOW_ACTION_TYPE_JUMP action item was added to support a matched flow
+ * ``RTE_FLOW_ACTION_TYPE_JUMP`` action item was added to support a matched flow
to be redirected to the specific group.
- * RTE_FLOW_ACTION_TYPE_MARK item type has been added to match a flow against
+ * ``RTE_FLOW_ACTION_TYPE_MARK`` item type has been added to match a flow against
a previously marked flow.
* ethdev: change flow APIs regarding count action:
+
* ``rte_flow_create()`` API count action now requires the ``struct rte_flow_action_count``.
* ``rte_flow_query()`` API parameter changed from action type to action structure.
@@ -485,14 +490,14 @@ API Changes
``rte_eth_[rt]x_queue_setup()``. Now any offloading enabled in ``rte_eth_dev_configure()``
can't be disabled by ``rte_eth_[rt]x_queue_setup()``. Any new added offloading which has
not been enabled in ``rte_eth_dev_configure()`` and is requested to be enabled in
- ``rte_eth_[rt]x_queue_setup()`` must be per-queue type, otherwise trigger an error log.
+ ``rte_eth_[rt]x_queue_setup()`` must be per-queue type, or otherwise trigger an error log.
* ethdev: runtime queue setup:
``rte_eth_rx_queue_setup`` and ``rte_eth_tx_queue_setup`` can be called after
- ``rte_eth_dev_start`` if device support runtime queue setup. Device driver can
- expose this capability through ``rte_eth_dev_info_get``. A Rx or Tx queue be
- setup at runtime need to be started explicitly by ``rte_eth_dev_rx_queue_start``
+ ``rte_eth_dev_start`` if the device supports runtime queue setup. The device driver can
+ expose this capability through ``rte_eth_dev_info_get``. A Rx or Tx queue
+ set up at runtime need to be started explicitly by ``rte_eth_dev_rx_queue_start``
or ``rte_eth_dev_tx_queue_start``.
@@ -509,18 +514,18 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
-* ring: the alignment constraints on the ring structure has been relaxed
+* ring: The alignment constraints on the ring structure has been relaxed
to one cache line instead of two, and an empty cache line padding is
added between the producer and consumer structures. The size of the
structure and the offset of the fields remains the same on platforms
- with 64B cache line, but change on other platforms.
+ with 64B cache line, but changes on other platforms.
-* mempool: ops have changed.
+* mempool: Some Ops have changed.
A new callback ``calc_mem_size`` has been added to ``rte_mempool_ops``
- to allow to customize required memory size calculation.
+ to allow customization of the required memory size calculation.
A new callback ``populate`` has been added to ``rte_mempool_ops``
- to allow to customize objects population.
+ to allow customized object population.
Callback ``get_capabilities`` has been removed from ``rte_mempool_ops``
since its features are covered by ``calc_mem_size`` and ``populate``
callbacks.
@@ -554,9 +559,9 @@ ABI Changes
``rte_bbdev_op_cap_turbo_dec`` structure to specify maximal LLR (likelihood
ratio) absolute value.
-* **BBdev Queue Groups split into UL/DL Groups**
+* **BBdev Queue Groups split into UL/DL Groups.**
- Queue Groups have been split into UL/DL Groups in Turbo Software Driver.
+ Queue Groups have been split into UL/DL Groups in the Turbo Software Driver.
They are independent for Decode/Encode. ``rte_bbdev_driver_info`` reflects
introduced changes.
@@ -591,7 +596,7 @@ Known Issues
* **Secondary process launch is not reliable.**
Recent memory hotplug patches have made multiprocess startup less reliable
- than it was in the past. A number of workarounds are known to work depending
+ than it was in past releases. A number of workarounds are known to work depending
on the circumstances. As such it isn't recommended to use the secondary
process mechanism for critical systems. The underlying issues will be
addressed in upcoming releases.
@@ -603,29 +608,30 @@ Known Issues
* **pdump is not compatible with old applications.**
- As we changed to use generic multi-process communication for pdump negotiation
- instead of previous dedicated unix socket way, pdump applications, including
- dpdk-pdump example and any other applications using librte_pdump, cannot work
- with older version DPDK primary applications.
+ As we changed to use generic multi-process communication for pdump
+ negotiation instead of previous dedicated unix socket way, pdump
+ applications, including the dpdk-pdump example and any other applications
+ using ``librte_pdump``, will not work with older version DPDK primary
+ applications.
* **rte_abort takes a long time on FreeBSD.**
- DPDK processes now allocates a large area of virtual memory address space,
- with this change during rte_abort FreeBSD now dumps the contents of the
+ DPDK processes now allocates a large area of virtual memory address space.
+ As a result ``rte_abort`` on FreeBSD now dumps the contents of the
whole reserved memory range, not just the used portion, to a core dump file.
- Write this large core file can take a significant amount of time, causing
- processes to appear hung on the system.
+ Writing this large core file can take a significant amount of time, causing
+ processes to appear to hang on the system.
The work around for the issue is to set the system resource limits for core
- dumps before running any tests e.g."limit coredumpsize 0". This will
+ dumps before running any tests, e.g. ``limit coredumpsize 0``. This will
effectively disable core dumps on FreeBSD. If they are not to be completely
disabled, a suitable limit, e.g. 1G might be specified instead of 0. This
needs to be run per-shell session, or before every test run. This change
- can also be made persistent by adding "kern.coredump=0" to /etc/sysctl.conf
+ can also be made persistent by adding ``kern.coredump=0`` to ``/etc/sysctl.conf``.
Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=53
-* **Bonding PMD may fail to accept new slaves in certain conditions.**
+* **Bonding PMD may fail to accept new slaves ports in certain conditions.**
In certain conditions when using testpmd,
bonding may fail to register new slave ports.
--
2.7.5
^ permalink raw reply [relevance 16%]
Results 1-53 of 53 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2018-05-30 20:25 16% [dpdk-dev] [PATCH v1] doc: update release notes for 18.05 John McNamara
2019-04-03 13:26 4% [dpdk-dev] [PATCH v1] doc: fix spelling errors reported by aspell John McNamara
2019-04-03 13:26 4% ` John McNamara
2019-04-26 15:14 4% [dpdk-dev] [PATCH v2 1/2] " John McNamara
2019-04-26 15:14 4% ` John McNamara
2019-11-26 6:15 [dpdk-dev] [PATCH v2 1/5] drivers/octeontx2: allow experimental symbols Sunil Kumar Kori
2019-11-27 10:22 ` [dpdk-dev] [PATCH v2 1/4] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-11-27 10:22 7% ` [dpdk-dev] [PATCH v2 4/4] drivers/octeontx2: enhancing mbox APIs to get response Sunil Kumar Kori
2020-07-09 15:20 15% [dpdk-dev] [PATCH 20.11 0/5] Enhance rawdev APIs Bruce Richardson
2020-08-13 11:27 16% ` [dpdk-dev] [PATCH v2 0/7] " Bruce Richardson
2020-09-02 11:21 8% ` Nipun Gupta
2020-09-09 9:47 8% ` Thomas Monjalon
2020-09-10 14:36 16% ` [dpdk-dev] [PATCH v3 " Bruce Richardson
2020-09-11 9:56 8% ` Thomas Monjalon
2020-07-21 9:51 [dpdk-dev] [PATCH 20.11 00/20] raw/ioat: enhancements and new hardware support Bruce Richardson
2020-09-25 11:08 ` [dpdk-dev] [PATCH v3 00/25] " Bruce Richardson
2020-09-25 11:08 11% ` [dpdk-dev] [PATCH v3 07/25] raw/ioat: rename functions to be operation-agnostic Bruce Richardson
2020-09-28 16:42 ` [dpdk-dev] [PATCH v4 00/25] raw/ioat: enhancements and new hardware support Bruce Richardson
2020-09-28 16:42 11% ` [dpdk-dev] [PATCH v4 07/25] raw/ioat: rename functions to be operation-agnostic Bruce Richardson
2020-10-07 16:29 ` [dpdk-dev] [PATCH v5 00/25] raw/ioat: enhancements and new hardware support Bruce Richardson
2020-10-07 16:30 11% ` [dpdk-dev] [PATCH v5 07/25] raw/ioat: rename functions to be operation-agnostic Bruce Richardson
2020-10-08 9:51 ` [dpdk-dev] [PATCH v6 00/25] raw/ioat: enhancements and new hardware support Bruce Richardson
2020-10-08 9:51 11% ` [dpdk-dev] [PATCH v6 07/25] raw/ioat: rename functions to be operation-agnostic Bruce Richardson
2020-08-02 10:51 [dpdk-dev] [PATCH] doc: announce changes to eventdev public structures pbhagavatula
2020-08-03 7:29 ` [dpdk-dev] [PATCH v2] doc: add reserve fields " pbhagavatula
2020-08-04 10:41 8% ` Bruce Richardson
2020-08-04 11:37 0% ` Jerin Jacob
2020-08-04 16:20 0% ` Stephen Hemminger
2020-08-05 8:46 0% ` Kinsella, Ray
2020-08-05 9:10 0% ` Jerin Jacob
2020-08-06 0:59 2% ` Stephen Hemminger
2020-08-06 16:57 0% ` Jerin Jacob
2020-08-21 15:59 [dpdk-dev] [PATCH 0/4] simplify unit-testing of rawdevs Bruce Richardson
2020-09-10 16:47 13% ` [dpdk-dev] [PATCH v2 0/3] " Bruce Richardson
2020-09-07 9:25 9% [dpdk-dev] [PATCH 0/7] raw/dpaa2_qdma: driver enhancement Gagandeep Singh
2020-09-25 10:54 2% ` Hemant Agrawal
2020-10-15 9:47 9% ` [dpdk-dev] [PATCH v2 " Gagandeep Singh
2020-11-24 20:40 19% [dpdk-dev] [PATCH v1] doc: update release notes for 20.11 John McNamara
2021-06-02 20:35 [dpdk-dev] [PATCH] gpudev: introduce memory API Thomas Monjalon
2021-06-06 1:13 ` Honnappa Nagarahalli
2021-06-07 7:20 ` Wang, Haiyue
2021-06-07 10:43 ` Thomas Monjalon
2021-06-07 13:54 3% ` Jerin Jacob
2021-06-07 23:31 2% ` Honnappa Nagarahalli
2021-07-30 13:55 ` [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library Thomas Monjalon
2021-07-31 7:06 ` Jerin Jacob
2021-07-31 8:21 ` Thomas Monjalon
2021-07-31 13:42 2% ` Jerin Jacob
2021-08-27 9:44 2% ` Thomas Monjalon
2021-08-27 12:19 3% ` Jerin Jacob
2021-08-29 5:32 0% ` Wang, Haiyue
2021-09-01 15:35 0% ` Elena Agostini
2021-09-02 13:12 0% ` Jerin Jacob
2021-09-06 16:11 0% ` Elena Agostini
2021-09-10 17:27 8% [dpdk-dev] [PATCH 0/6] port ioatfwd app to dmadev Kevin Laatz
2021-09-17 16:41 8% ` [dpdk-dev] [PATCH v2 " Kevin Laatz
2021-09-23 13:53 0% ` fengchengwen
2021-09-23 14:00 0% ` Kevin Laatz
2021-09-28 16:29 8% ` [dpdk-dev] [PATCH v3 0/8] " Kevin Laatz
2021-10-14 9:53 8% ` [dpdk-dev] [PATCH v4 " Kevin Laatz
2021-10-26 0:56 0% ` fengchengwen
2021-10-26 13:14 8% ` [dpdk-dev] [PATCH v5 " Kevin Laatz
2021-10-27 14:54 0% ` Thomas Monjalon
2023-06-12 11:15 [RFC] lib/ethdev: introduce table driven APIs Qi Zhang
2023-06-14 18:30 ` Ori Kam
2023-06-15 2:25 ` Zhang, Qi Z
2023-06-15 4:57 ` Jerin Jacob
2023-06-15 6:03 ` Zhang, Qi Z
2023-06-15 6:21 6% ` Jerin Jacob
2023-06-15 7:42 8% ` Zhang, Qi Z
2023-06-15 8:37 4% ` Jerin Jacob
2023-06-15 13:25 2% ` Zhang, Qi Z
2023-06-16 1:20 ` Jerin Jacob
2023-06-19 0:22 ` Zhang, Qi Z
2023-06-19 9:52 5% ` Jerin Jacob
2023-06-20 1:52 2% ` Zhang, Qi Z
2023-07-31 9:43 [PATCH 0/3] version: 23.11-rc0 David Marchand
2023-07-31 9:43 6% ` [PATCH 1/3] " David Marchand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).