doc: fix spelling reported by aspell in guides

[ upstream commit d629b7b ] Fix spelling errors in the guide docs. Signed-off-by: John McNamara <john.mcnamara@intel.com> Acked-by: Rami Rosen <ramirose@gmail.com>
kevintraynor · May 8, 2019 · 8ca6a5b · 8ca6a5b
1 parent 1f78ae5
commit 8ca6a5b
Show file tree

Hide file tree

Showing 64 changed files with 149 additions and 149 deletions.
diff --git 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
@@ -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
@@ -125,7 +125,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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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/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/atlantic.rst b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
 - Port statistics
 - RSS (Receive Side Scaling)
 - Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
 
 Configuration Information
 ^^^^^^^^^^^^^^^^^^^^^^^^^

diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
@@ -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
@@ -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
@@ -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/enetc.rst b/doc/guides/nics/enetc.rst
@@ -69,7 +69,7 @@ Supported ENETC SoCs
 Prerequisites
 ~~~~~~~~~~~~~
 
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
 compatible board:
 
 1. **ARM 64 Tool Chain**

diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
@@ -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
@@ -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
@@ -571,7 +571,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
@@ -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
@@ -64,7 +64,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/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.
 

diff --git 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
@@ -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/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
 
@@ -207,12 +207,12 @@ Supported actions:
 
 Validating flow rules depends on the firmware variant.
 
-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
@@ -346,10 +346,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
@@ -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
@@ -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
@@ -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
@@ -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**