* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
@ 2019-04-26 15:14 John McNamara
2019-04-26 15:14 ` John McNamara
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
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 [flat|nested] 10+ messages in thread
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
@ 2019-04-26 15:14 ` John McNamara
2019-04-26 15:14 ` [dpdk-dev] [PATCH v2 2/2] " John McNamara
2019-04-27 18:53 ` [dpdk-dev] [PATCH v2 1/2] " Rami Rosen
2 siblings, 0 replies; 10+ messages in thread
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 [flat|nested] 10+ messages in thread
* [dpdk-dev] [PATCH v2 2/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
2019-04-26 15:14 ` John McNamara
@ 2019-04-26 15:14 ` John McNamara
2019-04-26 15:14 ` John McNamara
2019-04-27 18:53 ` [dpdk-dev] [PATCH v2 1/2] " Rami Rosen
2 siblings, 1 reply; 10+ messages in thread
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the doxygen docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h | 2 +-
drivers/common/qat/qat_adf/icp_qat_fw_pke.h | 2 +-
drivers/event/opdl/opdl_ring.h | 8 ++++----
drivers/net/i40e/rte_pmd_i40e.h | 4 ++--
drivers/net/nfp/nfp_net.c | 18 +++++++++---------
drivers/net/nfp/nfp_net_pmd.h | 4 ++--
drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h | 6 +++---
examples/performance-thread/common/lthread_api.h | 10 +++++-----
lib/librte_acl/acl_vect.h | 4 ++--
lib/librte_bbdev/rte_bbdev.h | 4 ++--
lib/librte_bpf/rte_bpf.h | 6 +++---
lib/librte_bpf/rte_bpf_ethdev.h | 4 ++--
lib/librte_cryptodev/rte_crypto_asym.h | 12 ++++++------
lib/librte_cryptodev/rte_cryptodev.h | 2 +-
lib/librte_distributor/rte_distributor_private.h | 2 +-
lib/librte_eal/common/include/generic/rte_cycles.h | 2 +-
lib/librte_eal/common/include/rte_class.h | 2 +-
lib/librte_eal/common/include/rte_common.h | 4 ++--
lib/librte_eal/common/include/rte_eal.h | 4 ++--
lib/librte_eal/common/include/rte_log.h | 2 +-
lib/librte_eal/common/include/rte_service.h | 2 +-
lib/librte_eal/common/include/rte_tailq.h | 2 +-
lib/librte_eal/common/include/rte_uuid.h | 4 ++--
lib/librte_eal/common/include/rte_vfio.h | 2 +-
lib/librte_eal/linux/eal/eal_memory.c | 2 +-
lib/librte_efd/rte_efd.h | 2 +-
lib/librte_ethdev/rte_eth_ctrl.h | 2 +-
lib/librte_ethdev/rte_ethdev.h | 8 ++++----
lib/librte_ethdev/rte_ethdev_core.h | 4 ++--
lib/librte_ethdev/rte_ethdev_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 8 ++++----
lib/librte_eventdev/rte_event_crypto_adapter.h | 2 +-
lib/librte_eventdev/rte_event_eth_rx_adapter.h | 4 ++--
lib/librte_eventdev/rte_eventdev.h | 4 ++--
lib/librte_eventdev/rte_eventdev_pmd.h | 2 +-
lib/librte_flow_classify/rte_flow_classify.h | 4 ++--
lib/librte_hash/rte_hash.h | 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 2 +-
lib/librte_ipsec/crypto.h | 2 +-
lib/librte_ipsec/misc.h | 2 +-
lib/librte_ipsec/rte_ipsec_group.h | 2 +-
lib/librte_ipsec/rte_ipsec_sa.h | 2 +-
lib/librte_latencystats/rte_latencystats.h | 2 +-
lib/librte_lpm/rte_lpm.h | 2 +-
lib/librte_mbuf/rte_mbuf.h | 8 ++++----
lib/librte_mbuf/rte_mbuf_ptype.h | 2 +-
lib/librte_mempool/rte_mempool.h | 4 ++--
lib/librte_pipeline/rte_table_action.h | 2 +-
lib/librte_power/rte_power_empty_poll.h | 2 +-
lib/librte_rawdev/rte_rawdev.h | 6 +++---
lib/librte_rawdev/rte_rawdev_pmd.h | 8 ++++----
lib/librte_reorder/rte_reorder.h | 2 +-
lib/librte_ring/rte_ring.h | 2 +-
lib/librte_sched/rte_sched.h | 2 +-
lib/librte_security/rte_security.h | 4 ++--
lib/librte_table/rte_table_hash.h | 6 +++---
lib/librte_vhost/rte_vhost.h | 4 ++--
57 files changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
index d9a42dd..00813cf 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
@@ -8,7 +8,7 @@
* @brief
* This file documents the external interfaces that the QAT FW running
* on the QAT Acceleration Engine provides to clients wanting to
- * accelerate crypto assymetric applications
+ * accelerate crypto asymmetric applications
*/
#ifndef _ICP_QAT_FW_MMP_IDS_
diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_pke.h b/drivers/common/qat/qat_adf/icp_qat_fw_pke.h
index 1c1560a..b2cdf0a 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_pke.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_pke.h
@@ -10,7 +10,7 @@
* @brief
* This file documents the external interfaces that the QAT FW running
* on the QAT Acceleration Engine provides to clients wanting to
- * accelerate crypto assymetric applications
+ * accelerate crypto asymmetric applications
*/
#ifndef _ICP_QAT_FW_PKE_H_
diff --git a/drivers/event/opdl/opdl_ring.h b/drivers/event/opdl/opdl_ring.h
index 751a59d..14ababe 100644
--- a/drivers/event/opdl/opdl_ring.h
+++ b/drivers/event/opdl/opdl_ring.h
@@ -24,7 +24,7 @@
* packets.
*
* A opdl_ring can be used as the basis for pipeline based applications. Instead
- * of each stage in a pipeline dequeueing from a ring, processing and enqueueing
+ * of each stage in a pipeline dequeuing from a ring, processing and enqueuing
* to another ring, it can process entries in-place on the ring. If stages do
* not depend on each other, they can run in parallel.
*
@@ -152,7 +152,7 @@ opdl_ring_get_name(const struct opdl_ring *t);
* Enabling this may have a negative impact on performance if only one thread
* will be processing this stage.
* @param is_input
- * Indication to nitialise the stage with all slots available or none
+ * Indication to initialise the stage with all slots available or none
*
* @return
* A pointer to the new stage, or NULL on error.
@@ -589,7 +589,7 @@ opdl_ring_set_stage_threadsafe(struct opdl_stage *s, bool threadsafe);
* Compare the event descriptor with original version in the ring.
* if key field event descriptor is changed by application, then
* update the slot in the ring otherwise do nothing with it.
- * the key field is flow_id, prioirty, mbuf, impl_opaque
+ * the key field is flow_id, priority, mbuf, impl_opaque
*
* @param s
* The opdl_stage.
@@ -600,7 +600,7 @@ opdl_ring_set_stage_threadsafe(struct opdl_stage *s, bool threadsafe);
* @param atomic
* queue type associate with the stage.
* @return
- * if the evevnt key field is changed compare with previous record.
+ * if the event key field is changed compare with previous record.
*/
bool
diff --git a/drivers/net/i40e/rte_pmd_i40e.h b/drivers/net/i40e/rte_pmd_i40e.h
index be4a602..a131314 100644
--- a/drivers/net/i40e/rte_pmd_i40e.h
+++ b/drivers/net/i40e/rte_pmd_i40e.h
@@ -270,7 +270,7 @@ struct rte_pmd_i40e_pkt_template_action {
struct rte_pmd_i40e_pkt_template_input {
/** the pctype used for raw packet template */
uint16_t pctype;
- /** the buffer conatining raw packet template */
+ /** the buffer containing raw packet template */
void *packet;
/** the length of buffer with raw packet template */
uint32_t length;
@@ -314,7 +314,7 @@ struct rte_pmd_i40e_inset {
* @param conf
* Specifies configuration parameters of raw packet template filter.
* @param add
- * Speicifes an action to be taken - add or remove raw packet template filter.
+ * Specifies an action to be taken - add or remove raw packet template filter.
* @return
* - (0) if successful.
* - (-ENODEV) if *port* invalid.
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index b2ff03a..9394309 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -770,7 +770,7 @@ nfp_net_start(struct rte_eth_dev *dev)
return -EIO;
/*
- * Allocating rte mbuffs for configured rx queues.
+ * Allocating rte mbufs for configured rx queues.
* This requires queues being enabled before
*/
if (nfp_net_rx_freelist_setup(dev) < 0) {
@@ -1551,7 +1551,7 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
if (rxq == NULL)
return -ENOMEM;
- /* Hw queues mapping based on firmware confifguration */
+ /* Hw queues mapping based on firmware configuration */
rxq->qidx = queue_idx;
rxq->fl_qcidx = queue_idx * hw->stride_rx;
rxq->rx_qcidx = rxq->fl_qcidx + (hw->stride_rx - 1);
@@ -1583,7 +1583,7 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
socket_id);
if (tz == NULL) {
- PMD_DRV_LOG(ERR, "Error allocatig rx dma");
+ PMD_DRV_LOG(ERR, "Error allocating rx dma");
nfp_net_rx_queue_release(rxq);
return -ENOMEM;
}
@@ -1970,7 +1970,7 @@ nfp_net_mbuf_alloc_failed(struct nfp_net_rxq *rxq)
/*
* RX path design:
*
- * There are some decissions to take:
+ * There are some decisions to take:
* 1) How to check DD RX descriptors bit
* 2) How and when to allocate new mbufs
*
@@ -2040,7 +2040,7 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
rte_rmb();
/*
- * We got a packet. Let's alloc a new mbuff for refilling the
+ * We got a packet. Let's alloc a new mbuf for refilling the
* free descriptor ring as soon as possible
*/
new_mb = rte_pktmbuf_alloc(rxq->mem_pool);
@@ -2055,8 +2055,8 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
nb_hold++;
/*
- * Grab the mbuff and refill the descriptor with the
- * previously allocated mbuff
+ * Grab the mbuf and refill the descriptor with the
+ * previously allocated mbuf
*/
mb = rxb->mbuf;
rxb->mbuf = new_mb;
@@ -2088,7 +2088,7 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
return -EINVAL;
}
- /* Filling the received mbuff with packet info */
+ /* Filling the received mbuf with packet info */
if (hw->rx_offset)
mb->data_off = RTE_PKTMBUF_HEADROOM + hw->rx_offset;
else
@@ -2113,7 +2113,7 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
mb->ol_flags |= PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED;
}
- /* Adding the mbuff to the mbuff array passed by the app */
+ /* Adding the mbuf to the mbuf array passed by the app */
rx_pkts[avail++] = mb;
/* Now resetting and updating the descriptor */
diff --git a/drivers/net/nfp/nfp_net_pmd.h b/drivers/net/nfp/nfp_net_pmd.h
index 7913a29..61a6eba 100644
--- a/drivers/net/nfp/nfp_net_pmd.h
+++ b/drivers/net/nfp/nfp_net_pmd.h
@@ -34,7 +34,7 @@
*
* @file dpdk/pmd/nfp_net_pmd.h
*
- * Netronome NFP_NET PDM driver
+ * Netronome NFP_NET PMD driver
*/
#ifndef _NFP_NET_PMD_H_
@@ -240,7 +240,7 @@ struct nfp_net_txq {
uint32_t tx_free_thresh;
/*
- * For each descriptor keep a reference to the mbuff and
+ * For each descriptor keep a reference to the mbuf and
* DMA address used until completion is signalled.
*/
struct {
diff --git a/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h b/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
index ce491d5..caf0293 100644
--- a/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
+++ b/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
@@ -34,7 +34,7 @@ enum {
};
/**
- * If user has configued a Virtual Queue mode, but for some particular VQ
+ * If user has configured a Virtual Queue mode, but for some particular VQ
* user needs an exclusive H/W queue associated (for better performance
* on that particular VQ), then user can pass this flag while creating the
* Virtual Queue. A H/W queue will be allocated corresponding to
@@ -307,7 +307,7 @@ rte_qdma_vq_stats(uint16_t vq_id,
* VQ's at runtime.
*
* @param vq_id
- * Virtual Queue ID which needs to be deinialized.
+ * Virtual Queue ID which needs to be uninitialized.
*
* @returns
* - 0: Success.
@@ -322,7 +322,7 @@ rte_qdma_vq_destroy(uint16_t vq_id);
* VQ's at runtime.
*
* @param vq_id
- * RBP based Virtual Queue ID which needs to be deinialized.
+ * RBP based Virtual Queue ID which needs to be uninitialized.
*
* @returns
* - 0: Success.
diff --git a/examples/performance-thread/common/lthread_api.h b/examples/performance-thread/common/lthread_api.h
index 995deb4..e6879ea 100644
--- a/examples/performance-thread/common/lthread_api.h
+++ b/examples/performance-thread/common/lthread_api.h
@@ -206,12 +206,12 @@ void lthread_run(void);
* Creates an lthread and places it in the ready queue on a particular
* lcore.
*
- * If no scheduler exists yet on the curret lcore then one is created.
+ * If no scheduler exists yet on the current lcore then one is created.
*
* @param new_lt
* Pointer to an lthread pointer that will be initialized
* @param lcore
- * the lcore the thread should be started on or the current clore
+ * the lcore the thread should be started on or the current lcore
* -1 the current lcore
* 0 - LTHREAD_MAX_LCORES any other lcore
* @param lthread_func
@@ -469,7 +469,7 @@ void
/**
* Set lthread TLS
*
- * This function is modelled on pthread_set_sepcific()
+ * This function is modelled on pthread_set_specific()
* It associates a thread-specific value with a key obtained via a previous
* call to lthread_key_create().
* Different threads may bind different values to the same key. These values
@@ -749,7 +749,7 @@ int lthread_cond_wait(struct lthread_cond *c, uint64_t reserved);
* Signal a condition variable
*
* The function unblocks one thread waiting for the condition variable cond.
- * If no threads are waiting on cond, the rte_lthead_cond_signal() function
+ * If no threads are waiting on cond, the rte_lthread_cond_signal() function
* has no effect.
*
* @param cond
@@ -765,7 +765,7 @@ int lthread_cond_signal(struct lthread_cond *c);
* Broadcast a condition variable
*
* The function unblocks all threads waiting for the condition variable cond.
- * If no threads are waiting on cond, the rte_lthead_cond_broadcast()
+ * If no threads are waiting on cond, the rte_lathed_cond_broadcast()
* function has no effect.
*
* @param cond
diff --git a/lib/librte_acl/acl_vect.h b/lib/librte_acl/acl_vect.h
index 194fca9..951e582 100644
--- a/lib/librte_acl/acl_vect.h
+++ b/lib/librte_acl/acl_vect.h
@@ -17,7 +17,7 @@ extern "C" {
/*
- * Takes 2 SIMD registers containing N transitions eachi (tr0, tr1).
+ * Takes 2 SIMD registers containing N transitions each (tr0, tr1).
* Shuffles it into different representation:
* lo - contains low 32 bits of given N transitions.
* hi - contains high 32 bits of given N transitions.
@@ -66,7 +66,7 @@ extern "C" {
\
dfa_ofs = _##P##_sub_epi32(t, r); \
\
- /* QUAD/SINGLE caluclations. */ \
+ /* QUAD/SINGLE calculations. */ \
t = _##P##_cmpgt_epi8(in, tr_hi); \
t = _##P##_sign_epi8(t, t); \
t = _##P##_maddubs_epi16(t, t); \
diff --git a/lib/librte_bbdev/rte_bbdev.h b/lib/librte_bbdev/rte_bbdev.h
index bec1ef6..d131692 100644
--- a/lib/librte_bbdev/rte_bbdev.h
+++ b/lib/librte_bbdev/rte_bbdev.h
@@ -43,7 +43,7 @@ extern "C" {
#define RTE_BBDEV_MAX_DEVS 128 /**< Max number of devices */
#endif
-/** Flags indiciate current state of BBDEV device */
+/** Flags indicate current state of BBDEV device */
enum rte_bbdev_state {
RTE_BBDEV_UNUSED,
RTE_BBDEV_INITIALIZED
@@ -161,7 +161,7 @@ rte_bbdev_queue_configure(uint16_t dev_id, uint16_t queue_id,
/**
* Start a device.
- * This is the last step needed before enqueueing operations is possible.
+ * This is the last step needed before enqueuing operations is possible.
*
* @param dev_id
* The identifier of the device.
diff --git a/lib/librte_bpf/rte_bpf.h b/lib/librte_bpf/rte_bpf.h
index ad62ef2..ab92af8 100644
--- a/lib/librte_bpf/rte_bpf.h
+++ b/lib/librte_bpf/rte_bpf.h
@@ -120,7 +120,7 @@ rte_bpf_destroy(struct rte_bpf *bpf);
* Create a new eBPF execution context and load given BPF code into it.
*
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @return
* BPF handle that is used in future BPF operations,
* or NULL on error, with error code set in rte_errno.
@@ -136,7 +136,7 @@ rte_bpf_load(const struct rte_bpf_prm *prm);
* file into it.
*
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @param fname
* Pathname for a ELF file.
* @param sname
@@ -183,7 +183,7 @@ rte_bpf_exec_burst(const struct rte_bpf *bpf, void *ctx[], uint64_t rc[],
uint32_t num);
/**
- * Provide information about natively compield code for given BPF handle.
+ * Provide information about natively compiled code for given BPF handle.
*
* @param bpf
* handle for the BPF code.
diff --git a/lib/librte_bpf/rte_bpf_ethdev.h b/lib/librte_bpf/rte_bpf_ethdev.h
index 11d09cd..1943372 100644
--- a/lib/librte_bpf/rte_bpf_ethdev.h
+++ b/lib/librte_bpf/rte_bpf_ethdev.h
@@ -73,7 +73,7 @@ rte_bpf_eth_tx_unload(uint16_t port, uint16_t queue);
* @param sname
* Name of the executable section within the file to load.
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @param flags
* Flags that define expected behavior of the loaded filter
* (i.e. jited/non-jited version to use).
@@ -98,7 +98,7 @@ rte_bpf_eth_rx_elf_load(uint16_t port, uint16_t queue,
* @param sname
* Name of the executable section within the file to load.
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @param flags
* Flags that define expected expected behavior of the loaded filter
* (i.e. jited/non-jited version to use).
diff --git a/lib/librte_cryptodev/rte_crypto_asym.h b/lib/librte_cryptodev/rte_crypto_asym.h
index 5e43620..2f181a4 100644
--- a/lib/librte_cryptodev/rte_crypto_asym.h
+++ b/lib/librte_cryptodev/rte_crypto_asym.h
@@ -112,15 +112,15 @@ enum rte_crypto_rsa_padding_type {
/**< RSA no padding scheme */
RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
- * as descibed in rfc2313
+ * as described in rfc2313
*/
RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
- * as descibed in rfc2313
+ * as described in rfc2313
*/
RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
- * as descibed in rfc2313
+ * as described in rfc2313
*/
RTE_CRYPTO_RSA_PADDING_OAEP,
/**< RSA PKCS#1 OAEP padding scheme */
@@ -227,7 +227,7 @@ struct rte_crypto_rsa_xform {
/**
* Asymmetric Modular exponentiation transform data
*
- * Structure describing modular exponentation xform param
+ * Structure describing modular exponentiation xform param
*
*/
struct rte_crypto_modex_xform {
@@ -280,7 +280,7 @@ struct rte_crypto_dh_xform {
rte_crypto_param p;
/**< p : Prime modulus data
- * DH prime modulous data in octet-string network byte order format.
+ * DH prime modulus data in octet-string network byte order format.
*
*/
@@ -346,7 +346,7 @@ struct rte_crypto_mod_op_param {
* data in octet-string network byte order format.
*
* This field shall be big enough to hold the result of Modular
- * Exponentiation or Modular Multplicative Inverse
+ * Exponentiation or Modular Multiplicative Inverse
* (bigger or equal to length of modulus)
*/
};
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 298b352..2d4f6d7 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -1141,7 +1141,7 @@ rte_cryptodev_asym_session_clear(uint8_t dev_id,
* the user data size.
*
* @return
- * Size of the symmetric eader session.
+ * Size of the symmetric header session.
*/
unsigned int
rte_cryptodev_sym_get_header_session_size(void);
diff --git a/lib/librte_distributor/rte_distributor_private.h b/lib/librte_distributor/rte_distributor_private.h
index fce68c9..33cd894 100644
--- a/lib/librte_distributor/rte_distributor_private.h
+++ b/lib/librte_distributor/rte_distributor_private.h
@@ -41,7 +41,7 @@ extern "C" {
/**
* Maximum number of workers allowed.
- * Be aware of increasing the limit, becaus it is limited by how we track
+ * Be aware of increasing the limit, because it is limited by how we track
* in-flight tags. See in_flight_bitmask and rte_distributor_process
*/
#define RTE_DISTRIB_MAX_WORKERS 64
diff --git a/lib/librte_eal/common/include/generic/rte_cycles.h b/lib/librte_eal/common/include/generic/rte_cycles.h
index ac379e8..d318b91 100644
--- a/lib/librte_eal/common/include/generic/rte_cycles.h
+++ b/lib/librte_eal/common/include/generic/rte_cycles.h
@@ -173,7 +173,7 @@ rte_delay_us_sleep(unsigned int us);
*
* @param userfunc
* User function which replaces rte_delay_us. rte_delay_us_block restores
- * buildin block delay function.
+ * builtin block delay function.
*/
void rte_delay_us_callback_register(void(*userfunc)(unsigned int));
diff --git a/lib/librte_eal/common/include/rte_class.h b/lib/librte_eal/common/include/rte_class.h
index 276c91e..856d09b 100644
--- a/lib/librte_eal/common/include/rte_class.h
+++ b/lib/librte_eal/common/include/rte_class.h
@@ -15,7 +15,7 @@
*
* A device class defines the type of function a device
* will be used for e.g.: Ethernet adapter (eth),
- * cryptographic coprocessor (crypto), etc.
+ * cryptographic co-processor (crypto), etc.
*/
#ifdef __cplusplus
diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index b475f76..05a3a64 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -359,7 +359,7 @@ rte_is_power_of_2(uint32_t n)
* Aligns input parameter to the next power of 2
*
* @param x
- * The integer value to algin
+ * The integer value to align
*
* @return
* Input parameter aligned to the next power of 2
@@ -377,7 +377,7 @@ rte_align32pow2(uint32_t x)
* Aligns input parameter to the previous power of 2
*
* @param x
- * The integer value to algin
+ * The integer value to align
*
* @return
* Input parameter aligned to the previous power of 2
diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
index f928866..0603eaf 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -284,7 +284,7 @@ rte_mp_action_unregister(const char *name);
*
* Send a message to the peer process.
*
- * This function will send a message which will be responsed by the action
+ * This function will send a message which will be responded by the action
* identified by name in the peer process.
*
* @param msg
@@ -421,7 +421,7 @@ rte_set_application_usage_hook(rte_usage_hook_t usage_func);
#define RTE_EAL_TAILQ_RWLOCK (&rte_eal_get_configuration()->mem_config->qlock)
/**
- * macro to get the multiple lock of mempool shared by mutiple-instance
+ * macro to get the multiple lock of mempool shared by multiple-instance
*/
#define RTE_EAL_MEMPOOL_RWLOCK (&rte_eal_get_configuration()->mem_config->mplock)
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index f334efc..cbb4184 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -37,7 +37,7 @@ struct rte_logs {
struct rte_log_dynamic_type *dynamic_types;
};
-/** Global log informations */
+/** Global log information */
extern struct rte_logs rte_logs;
/* SDK log type */
diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h
index 670c89a..bf25aec 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -337,7 +337,7 @@ int32_t rte_service_set_stats_enable(uint32_t id, int32_t enable);
int32_t rte_service_lcore_list(uint32_t array[], uint32_t n);
/**
- * Get the numer of services running on the supplied lcore.
+ * Get the number of services running on the supplied lcore.
*
* @param lcore Id of the service core.
* @retval >=0 Number of services registered to this core.
diff --git a/lib/librte_eal/common/include/rte_tailq.h b/lib/librte_eal/common/include/rte_tailq.h
index 9b01abb..b6fe4e5 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -53,7 +53,7 @@ struct rte_tailq_elem {
};
/**
- * Return the first tailq entry casted to the right struct.
+ * Return the first tailq entry cast to the right struct.
*/
#define RTE_TAILQ_CAST(tailq_entry, struct_name) \
(struct struct_name *)&(tailq_entry)->tailq_head
diff --git a/lib/librte_eal/common/include/rte_uuid.h b/lib/librte_eal/common/include/rte_uuid.h
index 2c846b5..16bbed3 100644
--- a/lib/librte_eal/common/include/rte_uuid.h
+++ b/lib/librte_eal/common/include/rte_uuid.h
@@ -43,7 +43,7 @@ extern "C" {
#include <stdbool.h>
/**
- * Struct describing a Universal Unique Identifer
+ * Struct describing a Universal Unique Identifier
*/
typedef unsigned char rte_uuid_t[16];
@@ -105,7 +105,7 @@ int rte_uuid_compare(const rte_uuid_t a, const rte_uuid_t b);
* @param uu
* Destination UUID
* @return
- * Returns 0 on succes, and -1 if string is not a valid UUID.
+ * Returns 0 on success, and -1 if string is not a valid UUID.
*/
int rte_uuid_parse(const char *in, rte_uuid_t uu);
diff --git a/lib/librte_eal/common/include/rte_vfio.h b/lib/librte_eal/common/include/rte_vfio.h
index 247fa2f..b360485 100644
--- a/lib/librte_eal/common/include/rte_vfio.h
+++ b/lib/librte_eal/common/include/rte_vfio.h
@@ -180,7 +180,7 @@ int rte_vfio_noiommu_is_enabled(void);
* an error on BSD.
*
* @param vfio_group_fd
- * VFIO Grouup FD.
+ * VFIO Group FD.
*
* @return
* 0 on success.
diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index 3193525..416dad8 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -1443,7 +1443,7 @@ eal_legacy_hugepage_init(void)
if (mcfg->dma_maskbits &&
rte_mem_check_dma_mask_thread_unsafe(mcfg->dma_maskbits)) {
RTE_LOG(ERR, EAL,
- "%s(): couldnt allocate memory due to IOVA exceeding limits of current DMA mask.\n",
+ "%s(): couldn't allocate memory due to IOVA exceeding limits of current DMA mask.\n",
__func__);
if (rte_eal_iova_mode() == RTE_IOVA_VA &&
rte_eal_using_phys_addrs())
diff --git a/lib/librte_efd/rte_efd.h b/lib/librte_efd/rte_efd.h
index 2ace008..c2be4c0 100644
--- a/lib/librte_efd/rte_efd.h
+++ b/lib/librte_efd/rte_efd.h
@@ -191,7 +191,7 @@ rte_efd_find_existing(const char *name);
* This operation was still successful, and entry contains a valid update
* RTE_EFD_UPDATE_FAILED
* Either the EFD failed to find a suitable perfect hash or the group was full
- * This is a fatal error, and the table is now in an indeterminite state
+ * This is a fatal error, and the table is now in an indeterminate state
* RTE_EFD_UPDATE_NO_CHANGE
* Operation resulted in no change to the table (same value already exists)
* 0 - success
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 9fb0657..1ef4ed9 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -540,7 +540,7 @@ struct rte_eth_fdir_masks {
uint16_t vlan_tci_mask; /**< Bit mask for vlan_tci in big endian */
/** Bit mask for ipv4 flow in big endian. */
struct rte_eth_ipv4_flow ipv4_mask;
- /** Bit maks for ipv6 flow in big endian. */
+ /** Bit mask for ipv6 flow in big endian. */
struct rte_eth_ipv6_flow ipv6_mask;
/** Bit mask for L4 source port in big endian. */
uint16_t src_port_mask;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index b8d19c6..1f35e1d 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -448,7 +448,7 @@ struct rte_eth_rss_conf {
/*
* A packet can be identified by hardware as different flow types. Different
- * NIC hardwares may support different flow types.
+ * NIC hardware may support different flow types.
* Basically, the NIC hardware identifies the flow type as deep protocol as
* possible, and exclusively. For example, if a packet is identified as
* 'RTE_ETH_FLOW_NONFRAG_IPV4_TCP', it will not be any of other flow types,
@@ -483,7 +483,7 @@ struct rte_eth_rss_conf {
/*
* The RSS offload types are defined based on flow types.
- * Different NIC hardwares may support different RSS offload
+ * Different NIC hardware may support different RSS offload
* types. The supported flow types or RSS offload types can be queried by
* rte_eth_dev_info_get().
*/
@@ -2220,7 +2220,7 @@ rte_eth_xstats_get_names_by_id(uint16_t port_id,
* A pointer to an ids array passed by application. This tells which
* statistics values function should retrieve. This parameter
* can be set to NULL if size is 0. In this case function will retrieve
- * all avalible statistics.
+ * all available statistics.
* @param values
* A pointer to a table to be filled with device statistics values.
* @param size
@@ -2690,7 +2690,7 @@ rte_eth_tx_buffer_count_callback(struct rte_mbuf **pkts, uint16_t unsent,
/**
* Request the driver to free mbufs currently cached by the driver. The
* driver will only free the mbuf if it is no longer in use. It is the
- * application's responsibity to ensure rte_eth_tx_buffer_flush(..) is
+ * application's responsibility to ensure rte_eth_tx_buffer_flush(..) is
* called if needed.
*
* @param port_id
diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
index 8f03f83..16300b1 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -105,7 +105,7 @@ typedef int (*eth_queue_stats_mapping_set_t)(struct rte_eth_dev *dev,
typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
-/**< @internal Get specific informations of an Ethernet device. */
+/**< @internal Get specific information of an Ethernet device. */
typedef const uint32_t *(*eth_dev_supported_ptypes_get_t)(struct rte_eth_dev *dev);
/**< @internal Get supported ptypes of an Ethernet device. */
@@ -367,7 +367,7 @@ typedef int (*eth_tm_ops_get_t)(struct rte_eth_dev *dev, void *ops);
/**< @internal Get Traffic Management (TM) operations on an Ethernet device */
typedef int (*eth_mtr_ops_get_t)(struct rte_eth_dev *dev, void *ops);
-/**< @internal Get Trafffic Metering and Policing (MTR) operations */
+/**< @internal Get Traffic Metering and Policing (MTR) operations */
typedef int (*eth_get_dcb_info)(struct rte_eth_dev *dev,
struct rte_eth_dcb_info *dcb_info);
diff --git a/lib/librte_ethdev/rte_ethdev_driver.h b/lib/librte_ethdev/rte_ethdev_driver.h
index c2ac263..f227480 100644
--- a/lib/librte_ethdev/rte_ethdev_driver.h
+++ b/lib/librte_ethdev/rte_ethdev_driver.h
@@ -317,7 +317,7 @@ typedef int (*ethdev_uninit_t)(struct rte_eth_dev *ethdev);
* @warning
* @b EXPERIMENTAL: this API may change without prior notice.
*
- * PMD helper function for cleaing up the resources of a ethdev port on it's
+ * PMD helper function for cleaning up the resources of a ethdev port on it's
* destruction.
*
* @param ethdev
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index ea54938..03eaa00 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -369,7 +369,7 @@ struct rte_tm_capabilities {
uint32_t sched_wfq_weight_max;
/** WRED packet mode support. When non-zero, this parameter indicates
- * that there is atleast one leaf node that supports the WRED packet
+ * that there is at least one leaf node that supports the WRED packet
* mode, which might not be true for all the leaf nodes. In packet
* mode, the WRED thresholds specify the queue length in packets, as
* opposed to bytes.
@@ -377,7 +377,7 @@ struct rte_tm_capabilities {
int cman_wred_packet_mode_supported;
/** WRED byte mode support. When non-zero, this parameter indicates that
- * there is atleast one leaf node that supports the WRED byte mode,
+ * there is at least one leaf node that supports the WRED byte mode,
* which might not be true for all the leaf nodes. In byte mode, the
* WRED thresholds specify the queue length in bytes, as opposed to
* packets.
@@ -636,7 +636,7 @@ struct rte_tm_level_capabilities {
uint32_t shaper_shared_n_max;
/** WRED packet mode support. When non-zero, this
- * parameter indicates that there is atleast one leaf
+ * parameter indicates that there is at least one leaf
* node on this level that supports the WRED packet
* mode, which might not be true for all the leaf
* nodes. In packet mode, the WRED thresholds specify
@@ -645,7 +645,7 @@ struct rte_tm_level_capabilities {
int cman_wred_packet_mode_supported;
/** WRED byte mode support. When non-zero, this
- * parameter indicates that there is atleast one leaf
+ * parameter indicates that there is at least one leaf
* node on this level that supports the WRED byte mode,
* which might not be true for all the leaf nodes. In
* byte mode, the WRED thresholds specify the queue
diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h b/lib/librte_eventdev/rte_event_crypto_adapter.h
index 528d1d9..60630ef 100644
--- a/lib/librte_eventdev/rte_event_crypto_adapter.h
+++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
@@ -139,7 +139,7 @@
* - rte_event_crypto_adapter_stats_get()
* - rte_event_crypto_adapter_stats_reset()
- * The applicaton creates an instance using rte_event_crypto_adapter_create()
+ * The application creates an instance using rte_event_crypto_adapter_create()
* or rte_event_crypto_adapter_create_ext().
*
* Cryptodev queue pair addition/deletion is done using the
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.h b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
index cf23cde..f1e301f 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
@@ -66,9 +66,9 @@
* 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 buffer packets. The application may also use some other
* criteria to decide which packets should enter the event device even when
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 62edc09..43b1a24 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1155,7 +1155,7 @@ rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t *caps);
*/
#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8
-/**< Flag indicates HW/SW suports a mechanism to store and retrieve
+/**< Flag indicates HW/SW supports a mechanism to store and retrieve
* the private data information along with the crypto session.
*/
@@ -1731,7 +1731,7 @@ rte_event_port_unlink(uint8_t dev_id, uint8_t port_id,
* @see rte_event_port_unlink() to issue unlink requests.
*
* @param dev_id
- * The indentifier of the device.
+ * The identifier of the device.
*
* @param port_id
* Event port identifier to select port to check for unlinks in progress.
diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h b/lib/librte_eventdev/rte_eventdev_pmd.h
index 1a01326..d118b9e 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd.h
@@ -873,7 +873,7 @@ typedef int (*eventdev_eth_tx_adapter_free_t)(uint8_t id,
* Ethernet device pointer
*
* @param tx_queue_id
- * Transmt queue index
+ * Transmit queue index
*
* @return
* - 0: Success.
diff --git a/lib/librte_flow_classify/rte_flow_classify.h b/lib/librte_flow_classify/rte_flow_classify.h
index 56e0635..01e88e5 100644
--- a/lib/librte_flow_classify/rte_flow_classify.h
+++ b/lib/librte_flow_classify/rte_flow_classify.h
@@ -208,7 +208,7 @@ rte_flow_classify_validate(struct rte_flow_classifier *cls,
struct rte_flow_error *error);
/**
- * Add a flow classify rule to the flow_classifer table.
+ * Add a flow classify rule to the flow_classifier table.
*
* @param[in] cls
* Flow classifier handle
@@ -235,7 +235,7 @@ rte_flow_classify_table_entry_add(struct rte_flow_classifier *cls,
struct rte_flow_error *error);
/**
- * Delete a flow classify rule from the flow_classifer table.
+ * Delete a flow classify rule from the flow_classifier table.
*
* @param[in] cls
* Flow classifier handle
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index c93d1a1..e5970b4 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -39,7 +39,7 @@ extern "C" {
/** Flag to support reader writer concurrency */
#define RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY 0x04
-/** Flag to indicate the extendabe bucket table feature should be used */
+/** Flag to indicate the extendable bucket table feature should be used */
#define RTE_HASH_EXTRA_FLAGS_EXT_TABLE 0x08
/** Flag to disable freeing of key index on hash delete.
diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 04fd9df..bc4c100 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag/rte_ip_frag.h
@@ -274,7 +274,7 @@ int32_t rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
/**
* This function implements reassembly of fragmented IPv4 packets.
- * Incoming mbufs should have its l2_len/l3_len fields setup correclty.
+ * Incoming mbufs should have its l2_len/l3_len fields setup correctly.
*
* @param tbl
* Table where to lookup/add the fragmented packet.
diff --git a/lib/librte_ipsec/crypto.h b/lib/librte_ipsec/crypto.h
index 3e9a8f4..45d4ef7 100644
--- a/lib/librte_ipsec/crypto.h
+++ b/lib/librte_ipsec/crypto.h
@@ -95,7 +95,7 @@ gen_iv(uint64_t iv[IPSEC_MAX_IV_QWORD], rte_be64_t sqn)
/*
* Helper routine to copy IV
- * Righ now we support only algorithms with IV length equals 0/8/16 bytes.
+ * Right now we support only algorithms with IV length equals 0/8/16 bytes.
*/
static inline void
copy_iv(uint64_t dst[IPSEC_MAX_IV_QWORD],
diff --git a/lib/librte_ipsec/misc.h b/lib/librte_ipsec/misc.h
index 67a6be2..693a4af 100644
--- a/lib/librte_ipsec/misc.h
+++ b/lib/librte_ipsec/misc.h
@@ -7,7 +7,7 @@
/**
* @file misc.h
- * Contains miscelaneous functions/structures/macros used internally
+ * Contains miscellaneous functions/structures/macros used internally
* by ipsec library.
*/
diff --git a/lib/librte_ipsec/rte_ipsec_group.h b/lib/librte_ipsec/rte_ipsec_group.h
index 696ed27..740fa7c 100644
--- a/lib/librte_ipsec/rte_ipsec_group.h
+++ b/lib/librte_ipsec/rte_ipsec_group.h
@@ -10,7 +10,7 @@
* @b EXPERIMENTAL: this API may change without prior notice
*
* RTE IPsec support.
- * It is not recommended to include this file direclty,
+ * It is not recommended to include this file directly,
* include <rte_ipsec.h> instead.
* Contains helper functions to process completed crypto-ops
* and group related packets by sessions they belong to.
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 7802da3..fd9b3ed 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -134,7 +134,7 @@ rte_ipsec_sa_type(const struct rte_ipsec_sa *sa);
/**
* Calculate required SA size based on provided input parameters.
* @param prm
- * Parameters that wil be used to initialise SA object.
+ * Parameters that will be used to initialise SA object.
* @return
* - Actual size required for SA with given parameters.
* - -EINVAL if the parameters are invalid.
diff --git a/lib/librte_latencystats/rte_latencystats.h b/lib/librte_latencystats/rte_latencystats.h
index efcfa02..6712072 100644
--- a/lib/librte_latencystats/rte_latencystats.h
+++ b/lib/librte_latencystats/rte_latencystats.h
@@ -24,7 +24,7 @@ extern "C" {
* Note: This function pointer is for future flow based latency stats
* implementation.
*
- * Function type used for identifting flow types of a Rx packet.
+ * Function type used for identifying flow types of a Rx packet.
*
* The callback function is called on Rx for each packet.
* This function is used for flow based latency calculations.
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 2155044..b886f54 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -442,7 +442,7 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t *ips,
* @param hop
* Next hop of the most specific rule found for IP (valid on lookup hit only).
* This is an 4 elements array of two byte values.
- * If the lookup was succesfull for the given IP, then least significant byte
+ * If the lookup was successful for the given IP, then least significant byte
* of the corresponding element is the actual next hop and the most
* significant byte is zero.
* If the lookup for the given IP failed, then corresponding element would
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 68415af..e4c2da6 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -210,7 +210,7 @@ extern "C" {
/**
* Outer UDP checksum offload flag. This flag is used for enabling
* outer UDP checksum in PMD. To use outer UDP checksum, the user needs to
- * 1) Enable the following in mbuff,
+ * 1) Enable the following in mbuf,
* a) Fill outer_l2_len and outer_l3_len in mbuf.
* b) Set the PKT_TX_OUTER_UDP_CKSUM flag.
* c) Set the PKT_TX_OUTER_IPV4 or PKT_TX_OUTER_IPV6 flag.
@@ -485,7 +485,7 @@ struct rte_mbuf_sched {
}; /**< Hierarchical scheduler */
/**
- * enum for the tx_offload bit-fields lenghts and offsets.
+ * enum for the tx_offload bit-fields lengths and offsets.
* defines the layout of rte_mbuf tx_offload field.
*/
enum {
@@ -1423,7 +1423,7 @@ static inline void rte_pktmbuf_reset_headroom(struct rte_mbuf *m)
* The given mbuf must have only one segment.
*
* @param m
- * The packet mbuf to be resetted.
+ * The packet mbuf to be reset.
*/
#define MBUF_INVALID_PORT UINT16_MAX
@@ -1596,7 +1596,7 @@ rte_pktmbuf_ext_shinfo_init_helper(void *buf_addr, uint16_t *buf_len,
* ``rte_pktmbuf_detach()``.
*
* Memory for shared data must be provided and user must initialize all of
- * the content properly, escpecially free callback and refcnt. The pointer
+ * the content properly, especially free callback and refcnt. The pointer
* of shared data will be stored in m->shinfo.
* ``rte_pktmbuf_ext_shinfo_init_helper`` can help to simply spare a few
* bytes at the end of buffer for the shared data, store free callback and
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 23bc635..17a2dd3 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -426,7 +426,7 @@ extern "C" {
*/
#define RTE_PTYPE_TUNNEL_ESP 0x00009000
/**
- * L2TP (Layer 2 Tunneling Protocol) tunnleing packet type.
+ * L2TP (Layer 2 Tunneling Protocol) tunneling packet type.
*
* Packet format:
* <'ether type'=0x0800
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index fd19470..8053f7a 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -427,7 +427,7 @@ typedef int (*rte_mempool_dequeue_t)(struct rte_mempool *mp,
* @warning
* @b EXPERIMENTAL: this API may change without prior notice.
*
- * Dequeue a number of contiquous object blocks from the external pool.
+ * Dequeue a number of contiguous object blocks from the external pool.
*/
typedef int (*rte_mempool_dequeue_contig_blocks_t)(struct rte_mempool *mp,
void **first_obj_table, unsigned int n);
@@ -1363,7 +1363,7 @@ __mempool_generic_get(struct rte_mempool *mp, void **obj_table,
&cache->objs[cache->len], req);
if (unlikely(ret < 0)) {
/*
- * In the offchance that we are buffer constrained,
+ * In the off chance that we are buffer constrained,
* where we are not able to allocate cache + n, go to
* the ring directly. If that fails, we are truly out of
* buffers.
diff --git a/lib/librte_pipeline/rte_table_action.h b/lib/librte_pipeline/rte_table_action.h
index e77551c..cf6eeaa 100644
--- a/lib/librte_pipeline/rte_table_action.h
+++ b/lib/librte_pipeline/rte_table_action.h
@@ -532,7 +532,7 @@ struct rte_table_action_encap_config {
};
};
-/** QinQ_PPPoE encap paramaeters. */
+/** QinQ_PPPoE encap parameters. */
struct rte_table_encap_ether_qinq_pppoe {
/** Only valid when *type* is set to QinQ. */
diff --git a/lib/librte_power/rte_power_empty_poll.h b/lib/librte_power/rte_power_empty_poll.h
index c1ad5c2..33f24e0 100644
--- a/lib/librte_power/rte_power_empty_poll.h
+++ b/lib/librte_power/rte_power_empty_poll.h
@@ -59,7 +59,7 @@ struct freq_threshold {
uint32_t cur_train_iter;
};
-/* Each Worder Thread Empty Poll Stats */
+/* Each Worker Thread Empty Poll Stats */
struct priority_worker {
/* Current dequeue and throughput counts */
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index 684bfdb..ed011ca 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -25,7 +25,7 @@ extern "C" {
#include <rte_memory.h>
#include <rte_errno.h>
-/* Rawdevice object - essentially a void to be typecasted by implementation */
+/* Rawdevice object - essentially a void to be typecast by implementation */
typedef void *rte_rawdev_obj_t;
/**
@@ -244,7 +244,7 @@ rte_rawdev_close(uint16_t dev_id);
* @param dev_id
* Raw device identifiers
* @return
- * 0 for sucessful reset,
+ * 0 for successful reset,
* !0 for failure in resetting
*/
int
@@ -373,7 +373,7 @@ rte_rawdev_set_attr(uint16_t dev_id,
* @param dev_id
* The identifier of the device to configure.
* @param buffers
- * Collection of buffers for enqueueing
+ * Collection of buffers for enqueuing
* @param count
* Count of buffers to enqueue
* @param context
diff --git a/lib/librte_rawdev/rte_rawdev_pmd.h b/lib/librte_rawdev/rte_rawdev_pmd.h
index 811e51d..5e6cf1d 100644
--- a/lib/librte_rawdev/rte_rawdev_pmd.h
+++ b/lib/librte_rawdev/rte_rawdev_pmd.h
@@ -282,7 +282,7 @@ typedef uint16_t (*rawdev_queue_count_t)(struct rte_rawdev *dev);
* an opaque object representing context of the call; for example, an
* application can pass information about the queues on which enqueue needs
* to be done. Or, the enqueue operation might be passed reference to an
- * object containing a callback (agreed upon between applicatio and driver).
+ * object containing a callback (agreed upon between application and driver).
*
* @return
* >=0 Count of buffers successfully enqueued (0: no buffers enqueued)
@@ -463,7 +463,7 @@ typedef int (*rawdev_firmware_version_get_t)(struct rte_rawdev *dev,
rte_rawdev_obj_t version_info);
/**
- * Load firwmare from a buffer (DMA'able)
+ * Load firmware from a buffer (DMA'able)
*
* @param dev
* Raw device pointer
@@ -480,7 +480,7 @@ typedef int (*rawdev_firmware_load_t)(struct rte_rawdev *dev,
rte_rawdev_obj_t firmware_buf);
/**
- * Unload firwmare
+ * Unload firmware
*
* @param dev
* Raw device pointer
@@ -548,7 +548,7 @@ struct rte_rawdev_ops {
/**< Reset the statistics values in xstats. */
rawdev_xstats_reset_t xstats_reset;
- /**< Obtainer firmware status */
+ /**< Obtain firmware status */
rawdev_firmware_status_get_t firmware_status_get;
/**< Obtain firmware version information */
rawdev_firmware_version_get_t firmware_version_get;
diff --git a/lib/librte_reorder/rte_reorder.h b/lib/librte_reorder/rte_reorder.h
index 1bcc2e3..6d39710 100644
--- a/lib/librte_reorder/rte_reorder.h
+++ b/lib/librte_reorder/rte_reorder.h
@@ -70,7 +70,7 @@ rte_reorder_init(struct rte_reorder_buffer *b, unsigned int bufsize,
* and return a pointer to it.
*
* @param name
- * Name of the reorder buffer instacne as passed to rte_reorder_create()
+ * Name of the reorder buffer instance as passed to rte_reorder_create()
* @return
* Pointer to reorder buffer instance or NULL if object not found with rte_errno
* set appropriately. Possible rte_errno values include:
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 83d0f6f..e265e94 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -302,7 +302,7 @@ void rte_ring_dump(FILE *f, const struct rte_ring *r);
* (powerpc/arm).
* There are 2 choices for the users
* 1.use rmb() memory barrier
- * 2.use one-direcion load_acquire/store_release barrier,defined by
+ * 2.use one-direction load_acquire/store_release barrier,defined by
* CONFIG_RTE_USE_C11_MEM_MODEL=y
* It depends on performance test results.
* By default, move common functions to rte_ring_generic.h
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 904d09d..9c55a78 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -33,7 +33,7 @@ extern "C" {
* classes of the same subport;
* - When any subport traffic class is oversubscribed
* (configuration time event), the usage of subport member
- * pipes with high demand for thattraffic class pipes is
+ * pipes with high demand for that traffic class pipes is
* truncated to a dynamically adjusted value with no
* impact to low demand pipes;
* 3. Pipe:
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index c8e438f..76f54e0 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -536,7 +536,7 @@ struct rte_security_capability {
enum rte_security_pdcp_domain domain;
/**< PDCP mode of operation: Control or data */
uint32_t capa_flags;
- /**< Capabilitity flags, see RTE_SECURITY_PDCP_* */
+ /**< Capability flags, see RTE_SECURITY_PDCP_* */
} pdcp;
/**< PDCP capability */
};
@@ -568,7 +568,7 @@ struct rte_security_capability {
#define RTE_SECURITY_TX_HW_TRAILER_OFFLOAD 0x00000002
/**< HW constructs trailer of packets
* Transmitted packets will have the trailer added to them
- * by hardawre. The next protocol field will be based on
+ * by hardware. The next protocol field will be based on
* the mbuf->inner_esp_next_proto field.
*/
#define RTE_SECURITY_RX_HW_TRAILER_OFFLOAD 0x00010000
diff --git a/lib/librte_table/rte_table_hash.h b/lib/librte_table/rte_table_hash.h
index 6f55bd5..61a0eed 100644
--- a/lib/librte_table/rte_table_hash.h
+++ b/lib/librte_table/rte_table_hash.h
@@ -29,7 +29,7 @@ extern "C" {
* be picked and dropped, the most likely candidate for drop, i.e. the
* current LRU key, is always picked. The LRU logic requires maintaining
* specific data structures per each bucket. Use-cases: flow cache, etc.
- * b. Extendible bucket (ext): The bucket is extended with space for 4 more
+ * b. Extendable bucket (ext): The bucket is extended with space for 4 more
* keys. This is done by allocating additional memory at table init time,
* which is used to create a pool of free keys (the size of this pool is
* configurable and always a multiple of 4). On key add operation, the
@@ -41,7 +41,7 @@ extern "C" {
* current bucket is in extended state and a match is not found in the
* first group of 4 keys, the search continues beyond the first group of
* 4 keys, potentially until all keys in this bucket are examined. The
- * extendible bucket logic requires maintaining specific data structures
+ * extendable bucket logic requires maintaining specific data structures
* per table and per each bucket. Use-cases: flow table, etc.
* 2. Key size:
* a. Configurable key size
@@ -86,7 +86,7 @@ struct rte_table_hash_params {
uint64_t seed;
};
-/** Extendible bucket hash table operations */
+/** Extendable bucket hash table operations */
extern struct rte_table_ops rte_table_hash_ext_ops;
extern struct rte_table_ops rte_table_hash_key8_ext_ops;
extern struct rte_table_ops rte_table_hash_key16_ext_ops;
diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
index d2c0c93..0226b3e 100644
--- a/lib/librte_vhost/rte_vhost.h
+++ b/lib/librte_vhost/rte_vhost.h
@@ -542,7 +542,7 @@ int rte_vhost_get_ifname(int vid, char *buf, size_t len);
* virtio queue index
*
* @return
- * num of avail entires left
+ * num of avail entries left
*/
uint16_t rte_vhost_avail_entries(int vid, uint16_t queue_id);
@@ -590,7 +590,7 @@ uint16_t rte_vhost_dequeue_burst(int vid, uint16_t queue_id,
/**
* Get guest mem table: a list of memory regions.
*
- * An rte_vhost_vhost_memory object will be allocated internaly, to hold the
+ * An rte_vhost_vhost_memory object will be allocated internally, to hold the
* guest memory regions. Application should free it at destroy_device()
* callback.
*
--
2.7.5
^ permalink raw reply [flat|nested] 10+ messages in thread
* [dpdk-dev] [PATCH v2 2/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 ` [dpdk-dev] [PATCH v2 2/2] " John McNamara
@ 2019-04-26 15:14 ` John McNamara
0 siblings, 0 replies; 10+ messages in thread
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the doxygen docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h | 2 +-
drivers/common/qat/qat_adf/icp_qat_fw_pke.h | 2 +-
drivers/event/opdl/opdl_ring.h | 8 ++++----
drivers/net/i40e/rte_pmd_i40e.h | 4 ++--
drivers/net/nfp/nfp_net.c | 18 +++++++++---------
drivers/net/nfp/nfp_net_pmd.h | 4 ++--
drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h | 6 +++---
examples/performance-thread/common/lthread_api.h | 10 +++++-----
lib/librte_acl/acl_vect.h | 4 ++--
lib/librte_bbdev/rte_bbdev.h | 4 ++--
lib/librte_bpf/rte_bpf.h | 6 +++---
lib/librte_bpf/rte_bpf_ethdev.h | 4 ++--
lib/librte_cryptodev/rte_crypto_asym.h | 12 ++++++------
lib/librte_cryptodev/rte_cryptodev.h | 2 +-
lib/librte_distributor/rte_distributor_private.h | 2 +-
lib/librte_eal/common/include/generic/rte_cycles.h | 2 +-
lib/librte_eal/common/include/rte_class.h | 2 +-
lib/librte_eal/common/include/rte_common.h | 4 ++--
lib/librte_eal/common/include/rte_eal.h | 4 ++--
lib/librte_eal/common/include/rte_log.h | 2 +-
lib/librte_eal/common/include/rte_service.h | 2 +-
lib/librte_eal/common/include/rte_tailq.h | 2 +-
lib/librte_eal/common/include/rte_uuid.h | 4 ++--
lib/librte_eal/common/include/rte_vfio.h | 2 +-
lib/librte_eal/linux/eal/eal_memory.c | 2 +-
lib/librte_efd/rte_efd.h | 2 +-
lib/librte_ethdev/rte_eth_ctrl.h | 2 +-
lib/librte_ethdev/rte_ethdev.h | 8 ++++----
lib/librte_ethdev/rte_ethdev_core.h | 4 ++--
lib/librte_ethdev/rte_ethdev_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 8 ++++----
lib/librte_eventdev/rte_event_crypto_adapter.h | 2 +-
lib/librte_eventdev/rte_event_eth_rx_adapter.h | 4 ++--
lib/librte_eventdev/rte_eventdev.h | 4 ++--
lib/librte_eventdev/rte_eventdev_pmd.h | 2 +-
lib/librte_flow_classify/rte_flow_classify.h | 4 ++--
lib/librte_hash/rte_hash.h | 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 2 +-
lib/librte_ipsec/crypto.h | 2 +-
lib/librte_ipsec/misc.h | 2 +-
lib/librte_ipsec/rte_ipsec_group.h | 2 +-
lib/librte_ipsec/rte_ipsec_sa.h | 2 +-
lib/librte_latencystats/rte_latencystats.h | 2 +-
lib/librte_lpm/rte_lpm.h | 2 +-
lib/librte_mbuf/rte_mbuf.h | 8 ++++----
lib/librte_mbuf/rte_mbuf_ptype.h | 2 +-
lib/librte_mempool/rte_mempool.h | 4 ++--
lib/librte_pipeline/rte_table_action.h | 2 +-
lib/librte_power/rte_power_empty_poll.h | 2 +-
lib/librte_rawdev/rte_rawdev.h | 6 +++---
lib/librte_rawdev/rte_rawdev_pmd.h | 8 ++++----
lib/librte_reorder/rte_reorder.h | 2 +-
lib/librte_ring/rte_ring.h | 2 +-
lib/librte_sched/rte_sched.h | 2 +-
lib/librte_security/rte_security.h | 4 ++--
lib/librte_table/rte_table_hash.h | 6 +++---
lib/librte_vhost/rte_vhost.h | 4 ++--
57 files changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
index d9a42dd..00813cf 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
@@ -8,7 +8,7 @@
* @brief
* This file documents the external interfaces that the QAT FW running
* on the QAT Acceleration Engine provides to clients wanting to
- * accelerate crypto assymetric applications
+ * accelerate crypto asymmetric applications
*/
#ifndef _ICP_QAT_FW_MMP_IDS_
diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_pke.h b/drivers/common/qat/qat_adf/icp_qat_fw_pke.h
index 1c1560a..b2cdf0a 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_pke.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_pke.h
@@ -10,7 +10,7 @@
* @brief
* This file documents the external interfaces that the QAT FW running
* on the QAT Acceleration Engine provides to clients wanting to
- * accelerate crypto assymetric applications
+ * accelerate crypto asymmetric applications
*/
#ifndef _ICP_QAT_FW_PKE_H_
diff --git a/drivers/event/opdl/opdl_ring.h b/drivers/event/opdl/opdl_ring.h
index 751a59d..14ababe 100644
--- a/drivers/event/opdl/opdl_ring.h
+++ b/drivers/event/opdl/opdl_ring.h
@@ -24,7 +24,7 @@
* packets.
*
* A opdl_ring can be used as the basis for pipeline based applications. Instead
- * of each stage in a pipeline dequeueing from a ring, processing and enqueueing
+ * of each stage in a pipeline dequeuing from a ring, processing and enqueuing
* to another ring, it can process entries in-place on the ring. If stages do
* not depend on each other, they can run in parallel.
*
@@ -152,7 +152,7 @@ opdl_ring_get_name(const struct opdl_ring *t);
* Enabling this may have a negative impact on performance if only one thread
* will be processing this stage.
* @param is_input
- * Indication to nitialise the stage with all slots available or none
+ * Indication to initialise the stage with all slots available or none
*
* @return
* A pointer to the new stage, or NULL on error.
@@ -589,7 +589,7 @@ opdl_ring_set_stage_threadsafe(struct opdl_stage *s, bool threadsafe);
* Compare the event descriptor with original version in the ring.
* if key field event descriptor is changed by application, then
* update the slot in the ring otherwise do nothing with it.
- * the key field is flow_id, prioirty, mbuf, impl_opaque
+ * the key field is flow_id, priority, mbuf, impl_opaque
*
* @param s
* The opdl_stage.
@@ -600,7 +600,7 @@ opdl_ring_set_stage_threadsafe(struct opdl_stage *s, bool threadsafe);
* @param atomic
* queue type associate with the stage.
* @return
- * if the evevnt key field is changed compare with previous record.
+ * if the event key field is changed compare with previous record.
*/
bool
diff --git a/drivers/net/i40e/rte_pmd_i40e.h b/drivers/net/i40e/rte_pmd_i40e.h
index be4a602..a131314 100644
--- a/drivers/net/i40e/rte_pmd_i40e.h
+++ b/drivers/net/i40e/rte_pmd_i40e.h
@@ -270,7 +270,7 @@ struct rte_pmd_i40e_pkt_template_action {
struct rte_pmd_i40e_pkt_template_input {
/** the pctype used for raw packet template */
uint16_t pctype;
- /** the buffer conatining raw packet template */
+ /** the buffer containing raw packet template */
void *packet;
/** the length of buffer with raw packet template */
uint32_t length;
@@ -314,7 +314,7 @@ struct rte_pmd_i40e_inset {
* @param conf
* Specifies configuration parameters of raw packet template filter.
* @param add
- * Speicifes an action to be taken - add or remove raw packet template filter.
+ * Specifies an action to be taken - add or remove raw packet template filter.
* @return
* - (0) if successful.
* - (-ENODEV) if *port* invalid.
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index b2ff03a..9394309 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -770,7 +770,7 @@ nfp_net_start(struct rte_eth_dev *dev)
return -EIO;
/*
- * Allocating rte mbuffs for configured rx queues.
+ * Allocating rte mbufs for configured rx queues.
* This requires queues being enabled before
*/
if (nfp_net_rx_freelist_setup(dev) < 0) {
@@ -1551,7 +1551,7 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
if (rxq == NULL)
return -ENOMEM;
- /* Hw queues mapping based on firmware confifguration */
+ /* Hw queues mapping based on firmware configuration */
rxq->qidx = queue_idx;
rxq->fl_qcidx = queue_idx * hw->stride_rx;
rxq->rx_qcidx = rxq->fl_qcidx + (hw->stride_rx - 1);
@@ -1583,7 +1583,7 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
socket_id);
if (tz == NULL) {
- PMD_DRV_LOG(ERR, "Error allocatig rx dma");
+ PMD_DRV_LOG(ERR, "Error allocating rx dma");
nfp_net_rx_queue_release(rxq);
return -ENOMEM;
}
@@ -1970,7 +1970,7 @@ nfp_net_mbuf_alloc_failed(struct nfp_net_rxq *rxq)
/*
* RX path design:
*
- * There are some decissions to take:
+ * There are some decisions to take:
* 1) How to check DD RX descriptors bit
* 2) How and when to allocate new mbufs
*
@@ -2040,7 +2040,7 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
rte_rmb();
/*
- * We got a packet. Let's alloc a new mbuff for refilling the
+ * We got a packet. Let's alloc a new mbuf for refilling the
* free descriptor ring as soon as possible
*/
new_mb = rte_pktmbuf_alloc(rxq->mem_pool);
@@ -2055,8 +2055,8 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
nb_hold++;
/*
- * Grab the mbuff and refill the descriptor with the
- * previously allocated mbuff
+ * Grab the mbuf and refill the descriptor with the
+ * previously allocated mbuf
*/
mb = rxb->mbuf;
rxb->mbuf = new_mb;
@@ -2088,7 +2088,7 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
return -EINVAL;
}
- /* Filling the received mbuff with packet info */
+ /* Filling the received mbuf with packet info */
if (hw->rx_offset)
mb->data_off = RTE_PKTMBUF_HEADROOM + hw->rx_offset;
else
@@ -2113,7 +2113,7 @@ nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
mb->ol_flags |= PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED;
}
- /* Adding the mbuff to the mbuff array passed by the app */
+ /* Adding the mbuf to the mbuf array passed by the app */
rx_pkts[avail++] = mb;
/* Now resetting and updating the descriptor */
diff --git a/drivers/net/nfp/nfp_net_pmd.h b/drivers/net/nfp/nfp_net_pmd.h
index 7913a29..61a6eba 100644
--- a/drivers/net/nfp/nfp_net_pmd.h
+++ b/drivers/net/nfp/nfp_net_pmd.h
@@ -34,7 +34,7 @@
*
* @file dpdk/pmd/nfp_net_pmd.h
*
- * Netronome NFP_NET PDM driver
+ * Netronome NFP_NET PMD driver
*/
#ifndef _NFP_NET_PMD_H_
@@ -240,7 +240,7 @@ struct nfp_net_txq {
uint32_t tx_free_thresh;
/*
- * For each descriptor keep a reference to the mbuff and
+ * For each descriptor keep a reference to the mbuf and
* DMA address used until completion is signalled.
*/
struct {
diff --git a/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h b/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
index ce491d5..caf0293 100644
--- a/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
+++ b/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
@@ -34,7 +34,7 @@ enum {
};
/**
- * If user has configued a Virtual Queue mode, but for some particular VQ
+ * If user has configured a Virtual Queue mode, but for some particular VQ
* user needs an exclusive H/W queue associated (for better performance
* on that particular VQ), then user can pass this flag while creating the
* Virtual Queue. A H/W queue will be allocated corresponding to
@@ -307,7 +307,7 @@ rte_qdma_vq_stats(uint16_t vq_id,
* VQ's at runtime.
*
* @param vq_id
- * Virtual Queue ID which needs to be deinialized.
+ * Virtual Queue ID which needs to be uninitialized.
*
* @returns
* - 0: Success.
@@ -322,7 +322,7 @@ rte_qdma_vq_destroy(uint16_t vq_id);
* VQ's at runtime.
*
* @param vq_id
- * RBP based Virtual Queue ID which needs to be deinialized.
+ * RBP based Virtual Queue ID which needs to be uninitialized.
*
* @returns
* - 0: Success.
diff --git a/examples/performance-thread/common/lthread_api.h b/examples/performance-thread/common/lthread_api.h
index 995deb4..e6879ea 100644
--- a/examples/performance-thread/common/lthread_api.h
+++ b/examples/performance-thread/common/lthread_api.h
@@ -206,12 +206,12 @@ void lthread_run(void);
* Creates an lthread and places it in the ready queue on a particular
* lcore.
*
- * If no scheduler exists yet on the curret lcore then one is created.
+ * If no scheduler exists yet on the current lcore then one is created.
*
* @param new_lt
* Pointer to an lthread pointer that will be initialized
* @param lcore
- * the lcore the thread should be started on or the current clore
+ * the lcore the thread should be started on or the current lcore
* -1 the current lcore
* 0 - LTHREAD_MAX_LCORES any other lcore
* @param lthread_func
@@ -469,7 +469,7 @@ void
/**
* Set lthread TLS
*
- * This function is modelled on pthread_set_sepcific()
+ * This function is modelled on pthread_set_specific()
* It associates a thread-specific value with a key obtained via a previous
* call to lthread_key_create().
* Different threads may bind different values to the same key. These values
@@ -749,7 +749,7 @@ int lthread_cond_wait(struct lthread_cond *c, uint64_t reserved);
* Signal a condition variable
*
* The function unblocks one thread waiting for the condition variable cond.
- * If no threads are waiting on cond, the rte_lthead_cond_signal() function
+ * If no threads are waiting on cond, the rte_lthread_cond_signal() function
* has no effect.
*
* @param cond
@@ -765,7 +765,7 @@ int lthread_cond_signal(struct lthread_cond *c);
* Broadcast a condition variable
*
* The function unblocks all threads waiting for the condition variable cond.
- * If no threads are waiting on cond, the rte_lthead_cond_broadcast()
+ * If no threads are waiting on cond, the rte_lathed_cond_broadcast()
* function has no effect.
*
* @param cond
diff --git a/lib/librte_acl/acl_vect.h b/lib/librte_acl/acl_vect.h
index 194fca9..951e582 100644
--- a/lib/librte_acl/acl_vect.h
+++ b/lib/librte_acl/acl_vect.h
@@ -17,7 +17,7 @@ extern "C" {
/*
- * Takes 2 SIMD registers containing N transitions eachi (tr0, tr1).
+ * Takes 2 SIMD registers containing N transitions each (tr0, tr1).
* Shuffles it into different representation:
* lo - contains low 32 bits of given N transitions.
* hi - contains high 32 bits of given N transitions.
@@ -66,7 +66,7 @@ extern "C" {
\
dfa_ofs = _##P##_sub_epi32(t, r); \
\
- /* QUAD/SINGLE caluclations. */ \
+ /* QUAD/SINGLE calculations. */ \
t = _##P##_cmpgt_epi8(in, tr_hi); \
t = _##P##_sign_epi8(t, t); \
t = _##P##_maddubs_epi16(t, t); \
diff --git a/lib/librte_bbdev/rte_bbdev.h b/lib/librte_bbdev/rte_bbdev.h
index bec1ef6..d131692 100644
--- a/lib/librte_bbdev/rte_bbdev.h
+++ b/lib/librte_bbdev/rte_bbdev.h
@@ -43,7 +43,7 @@ extern "C" {
#define RTE_BBDEV_MAX_DEVS 128 /**< Max number of devices */
#endif
-/** Flags indiciate current state of BBDEV device */
+/** Flags indicate current state of BBDEV device */
enum rte_bbdev_state {
RTE_BBDEV_UNUSED,
RTE_BBDEV_INITIALIZED
@@ -161,7 +161,7 @@ rte_bbdev_queue_configure(uint16_t dev_id, uint16_t queue_id,
/**
* Start a device.
- * This is the last step needed before enqueueing operations is possible.
+ * This is the last step needed before enqueuing operations is possible.
*
* @param dev_id
* The identifier of the device.
diff --git a/lib/librte_bpf/rte_bpf.h b/lib/librte_bpf/rte_bpf.h
index ad62ef2..ab92af8 100644
--- a/lib/librte_bpf/rte_bpf.h
+++ b/lib/librte_bpf/rte_bpf.h
@@ -120,7 +120,7 @@ rte_bpf_destroy(struct rte_bpf *bpf);
* Create a new eBPF execution context and load given BPF code into it.
*
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @return
* BPF handle that is used in future BPF operations,
* or NULL on error, with error code set in rte_errno.
@@ -136,7 +136,7 @@ rte_bpf_load(const struct rte_bpf_prm *prm);
* file into it.
*
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @param fname
* Pathname for a ELF file.
* @param sname
@@ -183,7 +183,7 @@ rte_bpf_exec_burst(const struct rte_bpf *bpf, void *ctx[], uint64_t rc[],
uint32_t num);
/**
- * Provide information about natively compield code for given BPF handle.
+ * Provide information about natively compiled code for given BPF handle.
*
* @param bpf
* handle for the BPF code.
diff --git a/lib/librte_bpf/rte_bpf_ethdev.h b/lib/librte_bpf/rte_bpf_ethdev.h
index 11d09cd..1943372 100644
--- a/lib/librte_bpf/rte_bpf_ethdev.h
+++ b/lib/librte_bpf/rte_bpf_ethdev.h
@@ -73,7 +73,7 @@ rte_bpf_eth_tx_unload(uint16_t port, uint16_t queue);
* @param sname
* Name of the executable section within the file to load.
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @param flags
* Flags that define expected behavior of the loaded filter
* (i.e. jited/non-jited version to use).
@@ -98,7 +98,7 @@ rte_bpf_eth_rx_elf_load(uint16_t port, uint16_t queue,
* @param sname
* Name of the executable section within the file to load.
* @param prm
- * Parameters used to create and initialise the BPF exeution context.
+ * Parameters used to create and initialise the BPF execution context.
* @param flags
* Flags that define expected expected behavior of the loaded filter
* (i.e. jited/non-jited version to use).
diff --git a/lib/librte_cryptodev/rte_crypto_asym.h b/lib/librte_cryptodev/rte_crypto_asym.h
index 5e43620..2f181a4 100644
--- a/lib/librte_cryptodev/rte_crypto_asym.h
+++ b/lib/librte_cryptodev/rte_crypto_asym.h
@@ -112,15 +112,15 @@ enum rte_crypto_rsa_padding_type {
/**< RSA no padding scheme */
RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
- * as descibed in rfc2313
+ * as described in rfc2313
*/
RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
- * as descibed in rfc2313
+ * as described in rfc2313
*/
RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
- * as descibed in rfc2313
+ * as described in rfc2313
*/
RTE_CRYPTO_RSA_PADDING_OAEP,
/**< RSA PKCS#1 OAEP padding scheme */
@@ -227,7 +227,7 @@ struct rte_crypto_rsa_xform {
/**
* Asymmetric Modular exponentiation transform data
*
- * Structure describing modular exponentation xform param
+ * Structure describing modular exponentiation xform param
*
*/
struct rte_crypto_modex_xform {
@@ -280,7 +280,7 @@ struct rte_crypto_dh_xform {
rte_crypto_param p;
/**< p : Prime modulus data
- * DH prime modulous data in octet-string network byte order format.
+ * DH prime modulus data in octet-string network byte order format.
*
*/
@@ -346,7 +346,7 @@ struct rte_crypto_mod_op_param {
* data in octet-string network byte order format.
*
* This field shall be big enough to hold the result of Modular
- * Exponentiation or Modular Multplicative Inverse
+ * Exponentiation or Modular Multiplicative Inverse
* (bigger or equal to length of modulus)
*/
};
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 298b352..2d4f6d7 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -1141,7 +1141,7 @@ rte_cryptodev_asym_session_clear(uint8_t dev_id,
* the user data size.
*
* @return
- * Size of the symmetric eader session.
+ * Size of the symmetric header session.
*/
unsigned int
rte_cryptodev_sym_get_header_session_size(void);
diff --git a/lib/librte_distributor/rte_distributor_private.h b/lib/librte_distributor/rte_distributor_private.h
index fce68c9..33cd894 100644
--- a/lib/librte_distributor/rte_distributor_private.h
+++ b/lib/librte_distributor/rte_distributor_private.h
@@ -41,7 +41,7 @@ extern "C" {
/**
* Maximum number of workers allowed.
- * Be aware of increasing the limit, becaus it is limited by how we track
+ * Be aware of increasing the limit, because it is limited by how we track
* in-flight tags. See in_flight_bitmask and rte_distributor_process
*/
#define RTE_DISTRIB_MAX_WORKERS 64
diff --git a/lib/librte_eal/common/include/generic/rte_cycles.h b/lib/librte_eal/common/include/generic/rte_cycles.h
index ac379e8..d318b91 100644
--- a/lib/librte_eal/common/include/generic/rte_cycles.h
+++ b/lib/librte_eal/common/include/generic/rte_cycles.h
@@ -173,7 +173,7 @@ rte_delay_us_sleep(unsigned int us);
*
* @param userfunc
* User function which replaces rte_delay_us. rte_delay_us_block restores
- * buildin block delay function.
+ * builtin block delay function.
*/
void rte_delay_us_callback_register(void(*userfunc)(unsigned int));
diff --git a/lib/librte_eal/common/include/rte_class.h b/lib/librte_eal/common/include/rte_class.h
index 276c91e..856d09b 100644
--- a/lib/librte_eal/common/include/rte_class.h
+++ b/lib/librte_eal/common/include/rte_class.h
@@ -15,7 +15,7 @@
*
* A device class defines the type of function a device
* will be used for e.g.: Ethernet adapter (eth),
- * cryptographic coprocessor (crypto), etc.
+ * cryptographic co-processor (crypto), etc.
*/
#ifdef __cplusplus
diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index b475f76..05a3a64 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -359,7 +359,7 @@ rte_is_power_of_2(uint32_t n)
* Aligns input parameter to the next power of 2
*
* @param x
- * The integer value to algin
+ * The integer value to align
*
* @return
* Input parameter aligned to the next power of 2
@@ -377,7 +377,7 @@ rte_align32pow2(uint32_t x)
* Aligns input parameter to the previous power of 2
*
* @param x
- * The integer value to algin
+ * The integer value to align
*
* @return
* Input parameter aligned to the previous power of 2
diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
index f928866..0603eaf 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -284,7 +284,7 @@ rte_mp_action_unregister(const char *name);
*
* Send a message to the peer process.
*
- * This function will send a message which will be responsed by the action
+ * This function will send a message which will be responded by the action
* identified by name in the peer process.
*
* @param msg
@@ -421,7 +421,7 @@ rte_set_application_usage_hook(rte_usage_hook_t usage_func);
#define RTE_EAL_TAILQ_RWLOCK (&rte_eal_get_configuration()->mem_config->qlock)
/**
- * macro to get the multiple lock of mempool shared by mutiple-instance
+ * macro to get the multiple lock of mempool shared by multiple-instance
*/
#define RTE_EAL_MEMPOOL_RWLOCK (&rte_eal_get_configuration()->mem_config->mplock)
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index f334efc..cbb4184 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -37,7 +37,7 @@ struct rte_logs {
struct rte_log_dynamic_type *dynamic_types;
};
-/** Global log informations */
+/** Global log information */
extern struct rte_logs rte_logs;
/* SDK log type */
diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h
index 670c89a..bf25aec 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -337,7 +337,7 @@ int32_t rte_service_set_stats_enable(uint32_t id, int32_t enable);
int32_t rte_service_lcore_list(uint32_t array[], uint32_t n);
/**
- * Get the numer of services running on the supplied lcore.
+ * Get the number of services running on the supplied lcore.
*
* @param lcore Id of the service core.
* @retval >=0 Number of services registered to this core.
diff --git a/lib/librte_eal/common/include/rte_tailq.h b/lib/librte_eal/common/include/rte_tailq.h
index 9b01abb..b6fe4e5 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -53,7 +53,7 @@ struct rte_tailq_elem {
};
/**
- * Return the first tailq entry casted to the right struct.
+ * Return the first tailq entry cast to the right struct.
*/
#define RTE_TAILQ_CAST(tailq_entry, struct_name) \
(struct struct_name *)&(tailq_entry)->tailq_head
diff --git a/lib/librte_eal/common/include/rte_uuid.h b/lib/librte_eal/common/include/rte_uuid.h
index 2c846b5..16bbed3 100644
--- a/lib/librte_eal/common/include/rte_uuid.h
+++ b/lib/librte_eal/common/include/rte_uuid.h
@@ -43,7 +43,7 @@ extern "C" {
#include <stdbool.h>
/**
- * Struct describing a Universal Unique Identifer
+ * Struct describing a Universal Unique Identifier
*/
typedef unsigned char rte_uuid_t[16];
@@ -105,7 +105,7 @@ int rte_uuid_compare(const rte_uuid_t a, const rte_uuid_t b);
* @param uu
* Destination UUID
* @return
- * Returns 0 on succes, and -1 if string is not a valid UUID.
+ * Returns 0 on success, and -1 if string is not a valid UUID.
*/
int rte_uuid_parse(const char *in, rte_uuid_t uu);
diff --git a/lib/librte_eal/common/include/rte_vfio.h b/lib/librte_eal/common/include/rte_vfio.h
index 247fa2f..b360485 100644
--- a/lib/librte_eal/common/include/rte_vfio.h
+++ b/lib/librte_eal/common/include/rte_vfio.h
@@ -180,7 +180,7 @@ int rte_vfio_noiommu_is_enabled(void);
* an error on BSD.
*
* @param vfio_group_fd
- * VFIO Grouup FD.
+ * VFIO Group FD.
*
* @return
* 0 on success.
diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index 3193525..416dad8 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -1443,7 +1443,7 @@ eal_legacy_hugepage_init(void)
if (mcfg->dma_maskbits &&
rte_mem_check_dma_mask_thread_unsafe(mcfg->dma_maskbits)) {
RTE_LOG(ERR, EAL,
- "%s(): couldnt allocate memory due to IOVA exceeding limits of current DMA mask.\n",
+ "%s(): couldn't allocate memory due to IOVA exceeding limits of current DMA mask.\n",
__func__);
if (rte_eal_iova_mode() == RTE_IOVA_VA &&
rte_eal_using_phys_addrs())
diff --git a/lib/librte_efd/rte_efd.h b/lib/librte_efd/rte_efd.h
index 2ace008..c2be4c0 100644
--- a/lib/librte_efd/rte_efd.h
+++ b/lib/librte_efd/rte_efd.h
@@ -191,7 +191,7 @@ rte_efd_find_existing(const char *name);
* This operation was still successful, and entry contains a valid update
* RTE_EFD_UPDATE_FAILED
* Either the EFD failed to find a suitable perfect hash or the group was full
- * This is a fatal error, and the table is now in an indeterminite state
+ * This is a fatal error, and the table is now in an indeterminate state
* RTE_EFD_UPDATE_NO_CHANGE
* Operation resulted in no change to the table (same value already exists)
* 0 - success
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 9fb0657..1ef4ed9 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -540,7 +540,7 @@ struct rte_eth_fdir_masks {
uint16_t vlan_tci_mask; /**< Bit mask for vlan_tci in big endian */
/** Bit mask for ipv4 flow in big endian. */
struct rte_eth_ipv4_flow ipv4_mask;
- /** Bit maks for ipv6 flow in big endian. */
+ /** Bit mask for ipv6 flow in big endian. */
struct rte_eth_ipv6_flow ipv6_mask;
/** Bit mask for L4 source port in big endian. */
uint16_t src_port_mask;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index b8d19c6..1f35e1d 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -448,7 +448,7 @@ struct rte_eth_rss_conf {
/*
* A packet can be identified by hardware as different flow types. Different
- * NIC hardwares may support different flow types.
+ * NIC hardware may support different flow types.
* Basically, the NIC hardware identifies the flow type as deep protocol as
* possible, and exclusively. For example, if a packet is identified as
* 'RTE_ETH_FLOW_NONFRAG_IPV4_TCP', it will not be any of other flow types,
@@ -483,7 +483,7 @@ struct rte_eth_rss_conf {
/*
* The RSS offload types are defined based on flow types.
- * Different NIC hardwares may support different RSS offload
+ * Different NIC hardware may support different RSS offload
* types. The supported flow types or RSS offload types can be queried by
* rte_eth_dev_info_get().
*/
@@ -2220,7 +2220,7 @@ rte_eth_xstats_get_names_by_id(uint16_t port_id,
* A pointer to an ids array passed by application. This tells which
* statistics values function should retrieve. This parameter
* can be set to NULL if size is 0. In this case function will retrieve
- * all avalible statistics.
+ * all available statistics.
* @param values
* A pointer to a table to be filled with device statistics values.
* @param size
@@ -2690,7 +2690,7 @@ rte_eth_tx_buffer_count_callback(struct rte_mbuf **pkts, uint16_t unsent,
/**
* Request the driver to free mbufs currently cached by the driver. The
* driver will only free the mbuf if it is no longer in use. It is the
- * application's responsibity to ensure rte_eth_tx_buffer_flush(..) is
+ * application's responsibility to ensure rte_eth_tx_buffer_flush(..) is
* called if needed.
*
* @param port_id
diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
index 8f03f83..16300b1 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -105,7 +105,7 @@ typedef int (*eth_queue_stats_mapping_set_t)(struct rte_eth_dev *dev,
typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
-/**< @internal Get specific informations of an Ethernet device. */
+/**< @internal Get specific information of an Ethernet device. */
typedef const uint32_t *(*eth_dev_supported_ptypes_get_t)(struct rte_eth_dev *dev);
/**< @internal Get supported ptypes of an Ethernet device. */
@@ -367,7 +367,7 @@ typedef int (*eth_tm_ops_get_t)(struct rte_eth_dev *dev, void *ops);
/**< @internal Get Traffic Management (TM) operations on an Ethernet device */
typedef int (*eth_mtr_ops_get_t)(struct rte_eth_dev *dev, void *ops);
-/**< @internal Get Trafffic Metering and Policing (MTR) operations */
+/**< @internal Get Traffic Metering and Policing (MTR) operations */
typedef int (*eth_get_dcb_info)(struct rte_eth_dev *dev,
struct rte_eth_dcb_info *dcb_info);
diff --git a/lib/librte_ethdev/rte_ethdev_driver.h b/lib/librte_ethdev/rte_ethdev_driver.h
index c2ac263..f227480 100644
--- a/lib/librte_ethdev/rte_ethdev_driver.h
+++ b/lib/librte_ethdev/rte_ethdev_driver.h
@@ -317,7 +317,7 @@ typedef int (*ethdev_uninit_t)(struct rte_eth_dev *ethdev);
* @warning
* @b EXPERIMENTAL: this API may change without prior notice.
*
- * PMD helper function for cleaing up the resources of a ethdev port on it's
+ * PMD helper function for cleaning up the resources of a ethdev port on it's
* destruction.
*
* @param ethdev
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index ea54938..03eaa00 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -369,7 +369,7 @@ struct rte_tm_capabilities {
uint32_t sched_wfq_weight_max;
/** WRED packet mode support. When non-zero, this parameter indicates
- * that there is atleast one leaf node that supports the WRED packet
+ * that there is at least one leaf node that supports the WRED packet
* mode, which might not be true for all the leaf nodes. In packet
* mode, the WRED thresholds specify the queue length in packets, as
* opposed to bytes.
@@ -377,7 +377,7 @@ struct rte_tm_capabilities {
int cman_wred_packet_mode_supported;
/** WRED byte mode support. When non-zero, this parameter indicates that
- * there is atleast one leaf node that supports the WRED byte mode,
+ * there is at least one leaf node that supports the WRED byte mode,
* which might not be true for all the leaf nodes. In byte mode, the
* WRED thresholds specify the queue length in bytes, as opposed to
* packets.
@@ -636,7 +636,7 @@ struct rte_tm_level_capabilities {
uint32_t shaper_shared_n_max;
/** WRED packet mode support. When non-zero, this
- * parameter indicates that there is atleast one leaf
+ * parameter indicates that there is at least one leaf
* node on this level that supports the WRED packet
* mode, which might not be true for all the leaf
* nodes. In packet mode, the WRED thresholds specify
@@ -645,7 +645,7 @@ struct rte_tm_level_capabilities {
int cman_wred_packet_mode_supported;
/** WRED byte mode support. When non-zero, this
- * parameter indicates that there is atleast one leaf
+ * parameter indicates that there is at least one leaf
* node on this level that supports the WRED byte mode,
* which might not be true for all the leaf nodes. In
* byte mode, the WRED thresholds specify the queue
diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h b/lib/librte_eventdev/rte_event_crypto_adapter.h
index 528d1d9..60630ef 100644
--- a/lib/librte_eventdev/rte_event_crypto_adapter.h
+++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
@@ -139,7 +139,7 @@
* - rte_event_crypto_adapter_stats_get()
* - rte_event_crypto_adapter_stats_reset()
- * The applicaton creates an instance using rte_event_crypto_adapter_create()
+ * The application creates an instance using rte_event_crypto_adapter_create()
* or rte_event_crypto_adapter_create_ext().
*
* Cryptodev queue pair addition/deletion is done using the
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.h b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
index cf23cde..f1e301f 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
@@ -66,9 +66,9 @@
* 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 buffer packets. The application may also use some other
* criteria to decide which packets should enter the event device even when
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 62edc09..43b1a24 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1155,7 +1155,7 @@ rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t *caps);
*/
#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8
-/**< Flag indicates HW/SW suports a mechanism to store and retrieve
+/**< Flag indicates HW/SW supports a mechanism to store and retrieve
* the private data information along with the crypto session.
*/
@@ -1731,7 +1731,7 @@ rte_event_port_unlink(uint8_t dev_id, uint8_t port_id,
* @see rte_event_port_unlink() to issue unlink requests.
*
* @param dev_id
- * The indentifier of the device.
+ * The identifier of the device.
*
* @param port_id
* Event port identifier to select port to check for unlinks in progress.
diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h b/lib/librte_eventdev/rte_eventdev_pmd.h
index 1a01326..d118b9e 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd.h
@@ -873,7 +873,7 @@ typedef int (*eventdev_eth_tx_adapter_free_t)(uint8_t id,
* Ethernet device pointer
*
* @param tx_queue_id
- * Transmt queue index
+ * Transmit queue index
*
* @return
* - 0: Success.
diff --git a/lib/librte_flow_classify/rte_flow_classify.h b/lib/librte_flow_classify/rte_flow_classify.h
index 56e0635..01e88e5 100644
--- a/lib/librte_flow_classify/rte_flow_classify.h
+++ b/lib/librte_flow_classify/rte_flow_classify.h
@@ -208,7 +208,7 @@ rte_flow_classify_validate(struct rte_flow_classifier *cls,
struct rte_flow_error *error);
/**
- * Add a flow classify rule to the flow_classifer table.
+ * Add a flow classify rule to the flow_classifier table.
*
* @param[in] cls
* Flow classifier handle
@@ -235,7 +235,7 @@ rte_flow_classify_table_entry_add(struct rte_flow_classifier *cls,
struct rte_flow_error *error);
/**
- * Delete a flow classify rule from the flow_classifer table.
+ * Delete a flow classify rule from the flow_classifier table.
*
* @param[in] cls
* Flow classifier handle
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index c93d1a1..e5970b4 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -39,7 +39,7 @@ extern "C" {
/** Flag to support reader writer concurrency */
#define RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY 0x04
-/** Flag to indicate the extendabe bucket table feature should be used */
+/** Flag to indicate the extendable bucket table feature should be used */
#define RTE_HASH_EXTRA_FLAGS_EXT_TABLE 0x08
/** Flag to disable freeing of key index on hash delete.
diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 04fd9df..bc4c100 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag/rte_ip_frag.h
@@ -274,7 +274,7 @@ int32_t rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
/**
* This function implements reassembly of fragmented IPv4 packets.
- * Incoming mbufs should have its l2_len/l3_len fields setup correclty.
+ * Incoming mbufs should have its l2_len/l3_len fields setup correctly.
*
* @param tbl
* Table where to lookup/add the fragmented packet.
diff --git a/lib/librte_ipsec/crypto.h b/lib/librte_ipsec/crypto.h
index 3e9a8f4..45d4ef7 100644
--- a/lib/librte_ipsec/crypto.h
+++ b/lib/librte_ipsec/crypto.h
@@ -95,7 +95,7 @@ gen_iv(uint64_t iv[IPSEC_MAX_IV_QWORD], rte_be64_t sqn)
/*
* Helper routine to copy IV
- * Righ now we support only algorithms with IV length equals 0/8/16 bytes.
+ * Right now we support only algorithms with IV length equals 0/8/16 bytes.
*/
static inline void
copy_iv(uint64_t dst[IPSEC_MAX_IV_QWORD],
diff --git a/lib/librte_ipsec/misc.h b/lib/librte_ipsec/misc.h
index 67a6be2..693a4af 100644
--- a/lib/librte_ipsec/misc.h
+++ b/lib/librte_ipsec/misc.h
@@ -7,7 +7,7 @@
/**
* @file misc.h
- * Contains miscelaneous functions/structures/macros used internally
+ * Contains miscellaneous functions/structures/macros used internally
* by ipsec library.
*/
diff --git a/lib/librte_ipsec/rte_ipsec_group.h b/lib/librte_ipsec/rte_ipsec_group.h
index 696ed27..740fa7c 100644
--- a/lib/librte_ipsec/rte_ipsec_group.h
+++ b/lib/librte_ipsec/rte_ipsec_group.h
@@ -10,7 +10,7 @@
* @b EXPERIMENTAL: this API may change without prior notice
*
* RTE IPsec support.
- * It is not recommended to include this file direclty,
+ * It is not recommended to include this file directly,
* include <rte_ipsec.h> instead.
* Contains helper functions to process completed crypto-ops
* and group related packets by sessions they belong to.
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 7802da3..fd9b3ed 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -134,7 +134,7 @@ rte_ipsec_sa_type(const struct rte_ipsec_sa *sa);
/**
* Calculate required SA size based on provided input parameters.
* @param prm
- * Parameters that wil be used to initialise SA object.
+ * Parameters that will be used to initialise SA object.
* @return
* - Actual size required for SA with given parameters.
* - -EINVAL if the parameters are invalid.
diff --git a/lib/librte_latencystats/rte_latencystats.h b/lib/librte_latencystats/rte_latencystats.h
index efcfa02..6712072 100644
--- a/lib/librte_latencystats/rte_latencystats.h
+++ b/lib/librte_latencystats/rte_latencystats.h
@@ -24,7 +24,7 @@ extern "C" {
* Note: This function pointer is for future flow based latency stats
* implementation.
*
- * Function type used for identifting flow types of a Rx packet.
+ * Function type used for identifying flow types of a Rx packet.
*
* The callback function is called on Rx for each packet.
* This function is used for flow based latency calculations.
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 2155044..b886f54 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -442,7 +442,7 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t *ips,
* @param hop
* Next hop of the most specific rule found for IP (valid on lookup hit only).
* This is an 4 elements array of two byte values.
- * If the lookup was succesfull for the given IP, then least significant byte
+ * If the lookup was successful for the given IP, then least significant byte
* of the corresponding element is the actual next hop and the most
* significant byte is zero.
* If the lookup for the given IP failed, then corresponding element would
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 68415af..e4c2da6 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -210,7 +210,7 @@ extern "C" {
/**
* Outer UDP checksum offload flag. This flag is used for enabling
* outer UDP checksum in PMD. To use outer UDP checksum, the user needs to
- * 1) Enable the following in mbuff,
+ * 1) Enable the following in mbuf,
* a) Fill outer_l2_len and outer_l3_len in mbuf.
* b) Set the PKT_TX_OUTER_UDP_CKSUM flag.
* c) Set the PKT_TX_OUTER_IPV4 or PKT_TX_OUTER_IPV6 flag.
@@ -485,7 +485,7 @@ struct rte_mbuf_sched {
}; /**< Hierarchical scheduler */
/**
- * enum for the tx_offload bit-fields lenghts and offsets.
+ * enum for the tx_offload bit-fields lengths and offsets.
* defines the layout of rte_mbuf tx_offload field.
*/
enum {
@@ -1423,7 +1423,7 @@ static inline void rte_pktmbuf_reset_headroom(struct rte_mbuf *m)
* The given mbuf must have only one segment.
*
* @param m
- * The packet mbuf to be resetted.
+ * The packet mbuf to be reset.
*/
#define MBUF_INVALID_PORT UINT16_MAX
@@ -1596,7 +1596,7 @@ rte_pktmbuf_ext_shinfo_init_helper(void *buf_addr, uint16_t *buf_len,
* ``rte_pktmbuf_detach()``.
*
* Memory for shared data must be provided and user must initialize all of
- * the content properly, escpecially free callback and refcnt. The pointer
+ * the content properly, especially free callback and refcnt. The pointer
* of shared data will be stored in m->shinfo.
* ``rte_pktmbuf_ext_shinfo_init_helper`` can help to simply spare a few
* bytes at the end of buffer for the shared data, store free callback and
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 23bc635..17a2dd3 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -426,7 +426,7 @@ extern "C" {
*/
#define RTE_PTYPE_TUNNEL_ESP 0x00009000
/**
- * L2TP (Layer 2 Tunneling Protocol) tunnleing packet type.
+ * L2TP (Layer 2 Tunneling Protocol) tunneling packet type.
*
* Packet format:
* <'ether type'=0x0800
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index fd19470..8053f7a 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -427,7 +427,7 @@ typedef int (*rte_mempool_dequeue_t)(struct rte_mempool *mp,
* @warning
* @b EXPERIMENTAL: this API may change without prior notice.
*
- * Dequeue a number of contiquous object blocks from the external pool.
+ * Dequeue a number of contiguous object blocks from the external pool.
*/
typedef int (*rte_mempool_dequeue_contig_blocks_t)(struct rte_mempool *mp,
void **first_obj_table, unsigned int n);
@@ -1363,7 +1363,7 @@ __mempool_generic_get(struct rte_mempool *mp, void **obj_table,
&cache->objs[cache->len], req);
if (unlikely(ret < 0)) {
/*
- * In the offchance that we are buffer constrained,
+ * In the off chance that we are buffer constrained,
* where we are not able to allocate cache + n, go to
* the ring directly. If that fails, we are truly out of
* buffers.
diff --git a/lib/librte_pipeline/rte_table_action.h b/lib/librte_pipeline/rte_table_action.h
index e77551c..cf6eeaa 100644
--- a/lib/librte_pipeline/rte_table_action.h
+++ b/lib/librte_pipeline/rte_table_action.h
@@ -532,7 +532,7 @@ struct rte_table_action_encap_config {
};
};
-/** QinQ_PPPoE encap paramaeters. */
+/** QinQ_PPPoE encap parameters. */
struct rte_table_encap_ether_qinq_pppoe {
/** Only valid when *type* is set to QinQ. */
diff --git a/lib/librte_power/rte_power_empty_poll.h b/lib/librte_power/rte_power_empty_poll.h
index c1ad5c2..33f24e0 100644
--- a/lib/librte_power/rte_power_empty_poll.h
+++ b/lib/librte_power/rte_power_empty_poll.h
@@ -59,7 +59,7 @@ struct freq_threshold {
uint32_t cur_train_iter;
};
-/* Each Worder Thread Empty Poll Stats */
+/* Each Worker Thread Empty Poll Stats */
struct priority_worker {
/* Current dequeue and throughput counts */
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index 684bfdb..ed011ca 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -25,7 +25,7 @@ extern "C" {
#include <rte_memory.h>
#include <rte_errno.h>
-/* Rawdevice object - essentially a void to be typecasted by implementation */
+/* Rawdevice object - essentially a void to be typecast by implementation */
typedef void *rte_rawdev_obj_t;
/**
@@ -244,7 +244,7 @@ rte_rawdev_close(uint16_t dev_id);
* @param dev_id
* Raw device identifiers
* @return
- * 0 for sucessful reset,
+ * 0 for successful reset,
* !0 for failure in resetting
*/
int
@@ -373,7 +373,7 @@ rte_rawdev_set_attr(uint16_t dev_id,
* @param dev_id
* The identifier of the device to configure.
* @param buffers
- * Collection of buffers for enqueueing
+ * Collection of buffers for enqueuing
* @param count
* Count of buffers to enqueue
* @param context
diff --git a/lib/librte_rawdev/rte_rawdev_pmd.h b/lib/librte_rawdev/rte_rawdev_pmd.h
index 811e51d..5e6cf1d 100644
--- a/lib/librte_rawdev/rte_rawdev_pmd.h
+++ b/lib/librte_rawdev/rte_rawdev_pmd.h
@@ -282,7 +282,7 @@ typedef uint16_t (*rawdev_queue_count_t)(struct rte_rawdev *dev);
* an opaque object representing context of the call; for example, an
* application can pass information about the queues on which enqueue needs
* to be done. Or, the enqueue operation might be passed reference to an
- * object containing a callback (agreed upon between applicatio and driver).
+ * object containing a callback (agreed upon between application and driver).
*
* @return
* >=0 Count of buffers successfully enqueued (0: no buffers enqueued)
@@ -463,7 +463,7 @@ typedef int (*rawdev_firmware_version_get_t)(struct rte_rawdev *dev,
rte_rawdev_obj_t version_info);
/**
- * Load firwmare from a buffer (DMA'able)
+ * Load firmware from a buffer (DMA'able)
*
* @param dev
* Raw device pointer
@@ -480,7 +480,7 @@ typedef int (*rawdev_firmware_load_t)(struct rte_rawdev *dev,
rte_rawdev_obj_t firmware_buf);
/**
- * Unload firwmare
+ * Unload firmware
*
* @param dev
* Raw device pointer
@@ -548,7 +548,7 @@ struct rte_rawdev_ops {
/**< Reset the statistics values in xstats. */
rawdev_xstats_reset_t xstats_reset;
- /**< Obtainer firmware status */
+ /**< Obtain firmware status */
rawdev_firmware_status_get_t firmware_status_get;
/**< Obtain firmware version information */
rawdev_firmware_version_get_t firmware_version_get;
diff --git a/lib/librte_reorder/rte_reorder.h b/lib/librte_reorder/rte_reorder.h
index 1bcc2e3..6d39710 100644
--- a/lib/librte_reorder/rte_reorder.h
+++ b/lib/librte_reorder/rte_reorder.h
@@ -70,7 +70,7 @@ rte_reorder_init(struct rte_reorder_buffer *b, unsigned int bufsize,
* and return a pointer to it.
*
* @param name
- * Name of the reorder buffer instacne as passed to rte_reorder_create()
+ * Name of the reorder buffer instance as passed to rte_reorder_create()
* @return
* Pointer to reorder buffer instance or NULL if object not found with rte_errno
* set appropriately. Possible rte_errno values include:
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 83d0f6f..e265e94 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -302,7 +302,7 @@ void rte_ring_dump(FILE *f, const struct rte_ring *r);
* (powerpc/arm).
* There are 2 choices for the users
* 1.use rmb() memory barrier
- * 2.use one-direcion load_acquire/store_release barrier,defined by
+ * 2.use one-direction load_acquire/store_release barrier,defined by
* CONFIG_RTE_USE_C11_MEM_MODEL=y
* It depends on performance test results.
* By default, move common functions to rte_ring_generic.h
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 904d09d..9c55a78 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -33,7 +33,7 @@ extern "C" {
* classes of the same subport;
* - When any subport traffic class is oversubscribed
* (configuration time event), the usage of subport member
- * pipes with high demand for thattraffic class pipes is
+ * pipes with high demand for that traffic class pipes is
* truncated to a dynamically adjusted value with no
* impact to low demand pipes;
* 3. Pipe:
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index c8e438f..76f54e0 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -536,7 +536,7 @@ struct rte_security_capability {
enum rte_security_pdcp_domain domain;
/**< PDCP mode of operation: Control or data */
uint32_t capa_flags;
- /**< Capabilitity flags, see RTE_SECURITY_PDCP_* */
+ /**< Capability flags, see RTE_SECURITY_PDCP_* */
} pdcp;
/**< PDCP capability */
};
@@ -568,7 +568,7 @@ struct rte_security_capability {
#define RTE_SECURITY_TX_HW_TRAILER_OFFLOAD 0x00000002
/**< HW constructs trailer of packets
* Transmitted packets will have the trailer added to them
- * by hardawre. The next protocol field will be based on
+ * by hardware. The next protocol field will be based on
* the mbuf->inner_esp_next_proto field.
*/
#define RTE_SECURITY_RX_HW_TRAILER_OFFLOAD 0x00010000
diff --git a/lib/librte_table/rte_table_hash.h b/lib/librte_table/rte_table_hash.h
index 6f55bd5..61a0eed 100644
--- a/lib/librte_table/rte_table_hash.h
+++ b/lib/librte_table/rte_table_hash.h
@@ -29,7 +29,7 @@ extern "C" {
* be picked and dropped, the most likely candidate for drop, i.e. the
* current LRU key, is always picked. The LRU logic requires maintaining
* specific data structures per each bucket. Use-cases: flow cache, etc.
- * b. Extendible bucket (ext): The bucket is extended with space for 4 more
+ * b. Extendable bucket (ext): The bucket is extended with space for 4 more
* keys. This is done by allocating additional memory at table init time,
* which is used to create a pool of free keys (the size of this pool is
* configurable and always a multiple of 4). On key add operation, the
@@ -41,7 +41,7 @@ extern "C" {
* current bucket is in extended state and a match is not found in the
* first group of 4 keys, the search continues beyond the first group of
* 4 keys, potentially until all keys in this bucket are examined. The
- * extendible bucket logic requires maintaining specific data structures
+ * extendable bucket logic requires maintaining specific data structures
* per table and per each bucket. Use-cases: flow table, etc.
* 2. Key size:
* a. Configurable key size
@@ -86,7 +86,7 @@ struct rte_table_hash_params {
uint64_t seed;
};
-/** Extendible bucket hash table operations */
+/** Extendable bucket hash table operations */
extern struct rte_table_ops rte_table_hash_ext_ops;
extern struct rte_table_ops rte_table_hash_key8_ext_ops;
extern struct rte_table_ops rte_table_hash_key16_ext_ops;
diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
index d2c0c93..0226b3e 100644
--- a/lib/librte_vhost/rte_vhost.h
+++ b/lib/librte_vhost/rte_vhost.h
@@ -542,7 +542,7 @@ int rte_vhost_get_ifname(int vid, char *buf, size_t len);
* virtio queue index
*
* @return
- * num of avail entires left
+ * num of avail entries left
*/
uint16_t rte_vhost_avail_entries(int vid, uint16_t queue_id);
@@ -590,7 +590,7 @@ uint16_t rte_vhost_dequeue_burst(int vid, uint16_t queue_id,
/**
* Get guest mem table: a list of memory regions.
*
- * An rte_vhost_vhost_memory object will be allocated internaly, to hold the
+ * An rte_vhost_vhost_memory object will be allocated internally, to hold the
* guest memory regions. Application should free it at destroy_device()
* callback.
*
--
2.7.5
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
2019-04-26 15:14 ` John McNamara
2019-04-26 15:14 ` [dpdk-dev] [PATCH v2 2/2] " John McNamara
@ 2019-04-27 18:53 ` Rami Rosen
2019-04-27 18:53 ` Rami Rosen
2019-04-30 11:26 ` Mcnamara, John
2 siblings, 2 replies; 10+ messages in thread
From: Rami Rosen @ 2019-04-27 18:53 UTC (permalink / raw)
To: John McNamara; +Cc: dev
Hi John,
Thanks for this patch set, it really makes DPDK documentation more refined.
> -(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.
I am not sure about this change to "CollectD". Actually from what I know,
in official
collectd/service assurance documenration, it always appear as "collectd
plugin" or "Collectd plugin" (this is the usual semantics for unix/linux
daemons).
For example,
https://blog.dbrgn.ch/2017/3/10/write-a-collectd-python-plugin/
https://wiki.opnfv.org/display/fastpath/Collectd+how+to+implement+a+simple+plugin
https://collectd.org/documentation/manpages/collectd.conf.5.shtml
If it agreed that change to CollectD should be reverted, not sure that a
new V3 should be sent, this is a huge patch; if reverting can be done via
merge, it will be better.
Other than that,
Acked-by: Rami Rosen <ramirose@gmail.com>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-27 18:53 ` [dpdk-dev] [PATCH v2 1/2] " Rami Rosen
@ 2019-04-27 18:53 ` Rami Rosen
2019-04-30 11:26 ` Mcnamara, John
1 sibling, 0 replies; 10+ messages in thread
From: Rami Rosen @ 2019-04-27 18:53 UTC (permalink / raw)
To: John McNamara; +Cc: dev
Hi John,
Thanks for this patch set, it really makes DPDK documentation more refined.
> -(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.
I am not sure about this change to "CollectD". Actually from what I know,
in official
collectd/service assurance documenration, it always appear as "collectd
plugin" or "Collectd plugin" (this is the usual semantics for unix/linux
daemons).
For example,
https://blog.dbrgn.ch/2017/3/10/write-a-collectd-python-plugin/
https://wiki.opnfv.org/display/fastpath/Collectd+how+to+implement+a+simple+plugin
https://collectd.org/documentation/manpages/collectd.conf.5.shtml
If it agreed that change to CollectD should be reverted, not sure that a
new V3 should be sent, this is a huge patch; if reverting can be done via
merge, it will be better.
Other than that,
Acked-by: Rami Rosen <ramirose@gmail.com>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-27 18:53 ` [dpdk-dev] [PATCH v2 1/2] " Rami Rosen
2019-04-27 18:53 ` Rami Rosen
@ 2019-04-30 11:26 ` Mcnamara, John
2019-04-30 11:26 ` Mcnamara, John
2019-05-02 22:36 ` Thomas Monjalon
1 sibling, 2 replies; 10+ messages in thread
From: Mcnamara, John @ 2019-04-30 11:26 UTC (permalink / raw)
To: Rami Rosen; +Cc: dev
> If it agreed that change to CollectD should be reverted, not sure that a new V3 should be sent, this is a huge patch; if reverting can be done via merge, it will be better.
Agreed. Also the following change is incorrect:
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
The fix should be uint8_t
John
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-30 11:26 ` Mcnamara, John
@ 2019-04-30 11:26 ` Mcnamara, John
2019-05-02 22:36 ` Thomas Monjalon
1 sibling, 0 replies; 10+ messages in thread
From: Mcnamara, John @ 2019-04-30 11:26 UTC (permalink / raw)
To: Rami Rosen; +Cc: dev
> If it agreed that change to CollectD should be reverted, not sure that a new V3 should be sent, this is a huge patch; if reverting can be done via merge, it will be better.
Agreed. Also the following change is incorrect:
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
The fix should be uint8_t
John
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-30 11:26 ` Mcnamara, John
2019-04-30 11:26 ` Mcnamara, John
@ 2019-05-02 22:36 ` Thomas Monjalon
2019-05-02 22:36 ` Thomas Monjalon
1 sibling, 1 reply; 10+ messages in thread
From: Thomas Monjalon @ 2019-05-02 22:36 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev, Rami Rosen
30/04/2019 13:26, Mcnamara, John:
>
> > If it agreed that change to CollectD should be reverted, not sure that a new V3 should be sent, this is a huge patch; if reverting can be done via merge, it will be better.
>
> Agreed. Also the following change is incorrect:
>
> - uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
> + uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
>
> The fix should be uint8_t
Applied with suggested changes, thanks
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-05-02 22:36 ` Thomas Monjalon
@ 2019-05-02 22:36 ` Thomas Monjalon
0 siblings, 0 replies; 10+ messages in thread
From: Thomas Monjalon @ 2019-05-02 22:36 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev, Rami Rosen
30/04/2019 13:26, Mcnamara, John:
>
> > If it agreed that change to CollectD should be reverted, not sure that a new V3 should be sent, this is a huge patch; if reverting can be done via merge, it will be better.
>
> Agreed. Also the following change is incorrect:
>
> - uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
> + uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
>
> The fix should be uint8_t
Applied with suggested changes, thanks
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-05-02 22:36 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-26 15:14 [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
2019-04-26 15:14 ` John McNamara
2019-04-26 15:14 ` [dpdk-dev] [PATCH v2 2/2] " John McNamara
2019-04-26 15:14 ` John McNamara
2019-04-27 18:53 ` [dpdk-dev] [PATCH v2 1/2] " Rami Rosen
2019-04-27 18:53 ` Rami Rosen
2019-04-30 11:26 ` Mcnamara, John
2019-04-30 11:26 ` Mcnamara, John
2019-05-02 22:36 ` Thomas Monjalon
2019-05-02 22:36 ` Thomas Monjalon
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).