Re: [dpdk-stable] [PATCH 19.11] doc: spell check Backporting spell check patch to previous version of DPDK. All changes should be correct, but if not please reach out so I can submit a new version.

[Christian Ehrhardt <christian.ehrhardt@canonical.com>]

On Thu, Aug 12, 2021 at 6:00 PM Henry Nadeau <hnadeau@iol.unh.edu> wrote:
>
> [ upstream commit <9c30a6f3c9> ]


Thanks, applied with an update to the commit message to match the correct form

> Signed-off-by: Henry Nadeau <hnadeau@iol.unh.edu>
> ---
>  doc/guides/bbdevs/fpga_lte_fec.rst              | 2 +-
>  doc/guides/contributing/stable.rst              | 2 +-
>  doc/guides/cryptodevs/scheduler.rst             | 2 +-
>  doc/guides/howto/pvp_reference_benchmark.rst    | 2 +-
>  doc/guides/nics/bnxt.rst                        | 6 +++---
>  doc/guides/nics/mlx5.rst                        | 2 +-
>  doc/guides/nics/octeontx2.rst                   | 2 +-
>  doc/guides/nics/virtio.rst                      | 2 +-
>  doc/guides/prog_guide/bbdev.rst                 | 2 +-
>  doc/guides/prog_guide/dev_kit_build_system.rst  | 2 +-
>  doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
>  doc/guides/prog_guide/eventdev.rst              | 2 +-
>  doc/guides/prog_guide/multi_proc_support.rst    | 2 +-
>  doc/guides/prog_guide/qos_framework.rst         | 2 +-
>  doc/guides/rawdevs/ntb.rst                      | 2 +-
>  doc/guides/rel_notes/release_16_11.rst          | 2 +-
>  doc/guides/rel_notes/release_19_08.rst          | 2 +-
>  doc/guides/rel_notes/release_2_2.rst            | 2 +-
>  doc/guides/sample_app_ug/l2_forward_cat.rst     | 2 +-
>  doc/guides/sample_app_ug/performance_thread.rst | 2 +-
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst     | 2 +-
>  21 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst b/doc/guides/bbdevs/fpga_lte_fec.rst
> index 206b6f4f9b..8509de934f 100644
> --- a/doc/guides/bbdevs/fpga_lte_fec.rst
> +++ b/doc/guides/bbdevs/fpga_lte_fec.rst
> @@ -50,7 +50,7 @@ FPGA LTE FEC does not support the following:
>  Installation
>  --------------
>
> -Section 3 of the DPDK manual provides instuctions on installing and compiling DPDK. The
> +Section 3 of the DPDK manual provides instructions on installing and compiling DPDK. The
>  default set of bbdev compile flags may be found in config/common_base, where for example
>  the flag to build the FPGA LTE FEC device, ``CONFIG_RTE_LIBRTE_PMD_BBDEV_FPGA_LTE_FEC``, is already
>  set. It is assumed DPDK has been compiled using for instance:
> diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
> index 4d38bb8606..0a76a9173f 100644
> --- a/doc/guides/contributing/stable.rst
> +++ b/doc/guides/contributing/stable.rst
> @@ -95,7 +95,7 @@ Features should not be backported to stable releases. It may be acceptable, in
>  limited cases, to back port features for the LTS release where:
>
>  * There is a justifiable use case (for example a new PMD).
> -* The change is non-invasive.
> +* The change is noninvasive.
>  * The work of preparing the backport is done by the proposer.
>  * There is support within the community.
>
> diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
> index 7004ca431a..dd3de7f4d7 100644
> --- a/doc/guides/cryptodevs/scheduler.rst
> +++ b/doc/guides/cryptodevs/scheduler.rst
> @@ -126,7 +126,7 @@ operation:
>     than the designated threshold, otherwise it will be handled by the secondary
>     slave.
>
> -   A typical usecase in this mode is with the QAT cryptodev as the primary and
> +   A typical use case in this mode is with the QAT cryptodev as the primary and
>     a software cryptodev as the secondary slave. This may help applications to
>     process additional crypto workload than what the QAT cryptodev can handle on
>     its own, by making use of the available CPU cycles to deal with smaller
> diff --git a/doc/guides/howto/pvp_reference_benchmark.rst b/doc/guides/howto/pvp_reference_benchmark.rst
> index 64b1f4d8ec..971cb25d03 100644
> --- a/doc/guides/howto/pvp_reference_benchmark.rst
> +++ b/doc/guides/howto/pvp_reference_benchmark.rst
> @@ -26,7 +26,7 @@ Setup overview
>
>     PVP setup using 2 NICs
>
> -In this diagram, each red arrow represents one logical core. This use-case
> +In this diagram, each red arrow represents one logical core. This use case
>  requires 6 dedicated logical cores. A forwarding configuration with a single
>  NIC is also possible, requiring 3 logical cores.
>
> diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
> index 434ba9d6cc..60ad3127e8 100644
> --- a/doc/guides/nics/bnxt.rst
> +++ b/doc/guides/nics/bnxt.rst
> @@ -54,14 +54,14 @@ automatically when the port is started if allowed by the current configuration.
>  RX Requirements for Vector Mode
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> -Vector mode receive will be enabled if the following constrainsts are met:
> +Vector mode receive will be enabled if the following constraints are met:
>     * Packets must fit within a single mbuf (no scatter RX).
>     * LRO offload must be disabled.
>
>  TX Requirements for Vector Mode
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> -Vector mode transmit will be enabled if the following constrainsts are met:
> +Vector mode transmit will be enabled if the following constraints are met:
>     * Packets must be contained within a single mbuf (no gather TX).
>     * All transmit offloads other than VLAN insertion must be disabled.
>
> @@ -123,7 +123,7 @@ Chipsets and adapters supported by the bnxt PMD include:
>      <https://www.broadcom.com/products/ethernet-connectivity/smartnic/>`_
>      of the `Broadcom website <http://www.broadcom.com/>`_.
>
> -  * **Broadcom StrataGX® BCM5871X Series of Communucations Processors**
> +  * **Broadcom StrataGX® BCM5871X Series of Communications Processors**
>
>      These ARM based processors target a broad range of networking applications
>      including virtual CPE (vCPE) and NFV appliances, 10G service routers and
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index 18573cf6a0..c542cc974b 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -1027,7 +1027,7 @@ the DPDK application.
>
>          echo -n "<device pci address" > /sys/bus/pci/drivers/mlx5_core/unbind
>
> -5. Enbale switchdev mode::
> +5. Enable switchdev mode::
>
>          echo switchdev > /sys/class/net/<net device>/compat/devlink/mode
>
> diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
> index db62a4523f..cad4a7592a 100644
> --- a/doc/guides/nics/octeontx2.rst
> +++ b/doc/guides/nics/octeontx2.rst
> @@ -162,7 +162,7 @@ Runtime Config Options
>
>        -w 0002:02:00.0,max_sqb_count=64
>
> -   With the above configuration, each send queue's decscriptor buffer count is
> +   With the above configuration, each send queue's descriptor buffer count is
>     limited to a maximum of 64 buffers.
>
>  - ``switch header enable`` (default ``none``)
> diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
> index d1f5fb8986..7301a8fed1 100644
> --- a/doc/guides/nics/virtio.rst
> +++ b/doc/guides/nics/virtio.rst
> @@ -473,7 +473,7 @@ are shown in below table:
>     Split virtqueue in-order non-mergeable path  virtio_recv_pkts_inorder          virtio_xmit_pkts_inorder
>     Split virtqueue vectorized Rx path           virtio_recv_pkts_vec              virtio_xmit_pkts
>     Packed virtqueue mergeable path              virtio_recv_mergeable_pkts_packed virtio_xmit_pkts_packed
> -   Packed virtqueue non-meregable path          virtio_recv_pkts_packed           virtio_xmit_pkts_packed
> +   Packed virtqueue non-mergeable path          virtio_recv_pkts_packed           virtio_xmit_pkts_packed
>     Packed virtqueue in-order mergeable path     virtio_recv_mergeable_pkts_packed virtio_xmit_pkts_packed
>     Packed virtqueue in-order non-mergeable path virtio_recv_pkts_packed           virtio_xmit_pkts_packed
>     ============================================ ================================= ========================
> diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
> index d39167af1f..27e6848b94 100644
> --- a/doc/guides/prog_guide/bbdev.rst
> +++ b/doc/guides/prog_guide/bbdev.rst
> @@ -639,7 +639,7 @@ optionally the ``soft_output`` mbuf data pointers.
>     "soft output","soft LLR output buffer (optional)"
>     "op_flags","bitmask of all active operation capabilities"
>     "rv_index","redundancy version index [0..3]"
> -   "iter_max","maximum number of iterations to perofrm in decode all CBs"
> +   "iter_max","maximum number of iterations to perform in decode all CBs"
>     "iter_min","minimum number of iterations to perform in decoding all CBs"
>     "iter_count","number of iterations to performed in decoding all CBs"
>     "ext_scale","scale factor on extrinsic info (5 bits)"
> diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
> index 74dba4dd16..5e36e382ba 100644
> --- a/doc/guides/prog_guide/dev_kit_build_system.rst
> +++ b/doc/guides/prog_guide/dev_kit_build_system.rst
> @@ -9,7 +9,7 @@ Development Kit Build System
>  The DPDK requires a build system for compilation activities and so on.
>  This section describes the constraints and the mechanisms used in the DPDK framework.
>
> -There are two use-cases for the framework:
> +There are two use cases for the framework:
>
>  *   Compilation of the DPDK libraries and sample applications;
>      the framework generates specific binary libraries,
> diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
> index 48a2fec066..6c84566596 100644
> --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> @@ -465,7 +465,7 @@ devices would fail anyway.
>      - By default, the mempool, first asks for IOVA-contiguous memory using
>        ``RTE_MEMZONE_IOVA_CONTIG``. This is slow in RTE_IOVA_PA mode and it may
>        affect the application boot time.
> -    - It is easy to enable large amount of IOVA-contiguous memory use-cases
> +    - It is easy to enable large amount of IOVA-contiguous memory use cases
>        with IOVA in VA mode.
>
>      It is expected that all PCI drivers work in both RTE_IOVA_PA and
> diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
> index 7bcd7603b1..b415d6355f 100644
> --- a/doc/guides/prog_guide/eventdev.rst
> +++ b/doc/guides/prog_guide/eventdev.rst
> @@ -120,7 +120,7 @@ Ports
>  ~~~~~
>
>  Ports are the points of contact between worker cores and the eventdev. The
> -general use-case will see one CPU core using one port to enqueue and dequeue
> +general use case will see one CPU core using one port to enqueue and dequeue
>  events from an eventdev. Ports are linked to queues in order to retrieve events
>  from those queues (more details in `Linking Queues and Ports`_ below).
>
> diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
> index a84083b96c..8cfa4e9a45 100644
> --- a/doc/guides/prog_guide/multi_proc_support.rst
> +++ b/doc/guides/prog_guide/multi_proc_support.rst
> @@ -325,7 +325,7 @@ supported. However, since sending messages (not requests) does not involve an
>  IPC thread, sending messages while processing another message or request is
>  supported.
>
> -Since the memory sybsystem uses IPC internally, memory allocations and IPC must
> +Since the memory subsystem uses IPC internally, memory allocations and IPC must
>  not be mixed: it is not safe to use IPC inside a memory-related callback, nor is
>  it safe to allocate/free memory inside IPC callbacks. Attempting to do so may
>  lead to a deadlock.
> diff --git a/doc/guides/prog_guide/qos_framework.rst b/doc/guides/prog_guide/qos_framework.rst
> index a159709450..f39b099f03 100644
> --- a/doc/guides/prog_guide/qos_framework.rst
> +++ b/doc/guides/prog_guide/qos_framework.rst
> @@ -737,7 +737,7 @@ Strict priority scheduling of traffic classes within the same pipe is implemente
>  which selects the queues in ascending order.
>  Therefore, queue 0 (associated with TC 0, highest priority TC) is handled before
>  queue 1 (TC 1, lower priority than TC 0),
> -which is handled before queue 2 (TC 2, lower priority than TC 1) and it conitnues until queues of all TCs except the
> +which is handled before queue 2 (TC 2, lower priority than TC 1) and it continues until queues of all TCs except the
>  lowest priority TC are handled. At last, queues 12..15 (best effort TC, lowest priority TC) are handled.
>
>  Upper Limit Enforcement
> diff --git a/doc/guides/rawdevs/ntb.rst b/doc/guides/rawdevs/ntb.rst
> index 58472135f5..e86cdc33f9 100644
> --- a/doc/guides/rawdevs/ntb.rst
> +++ b/doc/guides/rawdevs/ntb.rst
> @@ -18,7 +18,7 @@ BIOS setting on Intel Skylake
>  -----------------------------
>
>  Intel Non-transparent Bridge needs special BIOS setting. Since the PMD only
> -supports Intel Skylake platform, introduce BIOS setting here. The referencce
> +supports Intel Skylake platform, introduce BIOS setting here. The reference
>  is https://www.intel.com/content/dam/support/us/en/documents/server-products/Intel_Xeon_Processor_Scalable_Family_BIOS_User_Guide.pdf
>
>  - Set the needed PCIe port as NTB to NTB mode on both hosts.
> diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
> index 92e0ec694e..3cec9143cf 100644
> --- a/doc/guides/rel_notes/release_16_11.rst
> +++ b/doc/guides/rel_notes/release_16_11.rst
> @@ -77,7 +77,7 @@ New Features
>    the current version, even 64 bytes packets take two slots with Virtio PMD on guest
>    side.
>
> -  The main impact is better performance for 0% packet loss use-cases, as it
> +  The main impact is better performance for 0% packet loss use cases, as it
>    behaves as if the virtqueue size was enlarged, so more packets can be buffered
>    in the case of system perturbations. On the downside, small performance degradations
>    were measured when running micro-benchmarks.
> diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
> index cbb27e8dc3..d2baa828b1 100644
> --- a/doc/guides/rel_notes/release_19_08.rst
> +++ b/doc/guides/rel_notes/release_19_08.rst
> @@ -151,7 +151,7 @@ New Features
>    * Added multi-queue support to allow one af_xdp vdev with multiple netdev
>      queues.
>    * Enabled "need_wakeup" feature which can provide efficient support for the
> -    usecase where the application and driver executing on the same core.
> +    use case where the application and driver executing on the same core.
>
>  * **Enabled infinite Rx in the PCAP PMD.**
>
> diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
> index cea5c8746d..8273473ff4 100644
> --- a/doc/guides/rel_notes/release_2_2.rst
> +++ b/doc/guides/rel_notes/release_2_2.rst
> @@ -322,7 +322,7 @@ Drivers
>
>    Several customers have reported a link flap issue on 82579. The symptoms
>    are random and intermittent link losses when 82579 is connected to specific
> -  switches. the Issue was root caused as an inter-operability problem between
> +  switches. the Issue was root caused as an interoperability problem between
>    the NIC and at least some Broadcom PHYs in the Energy Efficient Ethernet
>    wake mechanism.
>
> diff --git a/doc/guides/sample_app_ug/l2_forward_cat.rst b/doc/guides/sample_app_ug/l2_forward_cat.rst
> index 0a813200ba..2b4651e0fe 100644
> --- a/doc/guides/sample_app_ug/l2_forward_cat.rst
> +++ b/doc/guides/sample_app_ug/l2_forward_cat.rst
> @@ -198,7 +198,7 @@ queried for system CPU information and L3CA capabilities via
>  ``pqos_cap_get(...)`` and ``pqos_cap_get_type(..., PQOS_CAP_TYPE_L3CA, ...)``
>  calls. When all capability and topology information is collected, the requested
>  CAT configuration is validated. A check is then performed (on per socket basis)
> -for a sufficient number of un-associated COS. COS are selected and
> +for a sufficient number of unassociated COS. COS are selected and
>  configured via the ``pqos_l3ca_set(...)`` call. Finally, COS are associated to
>  relevant CPUs via ``pqos_l3ca_assoc_set(...)`` calls.
>
> diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
> index 5fed46465f..a2db452c01 100644
> --- a/doc/guides/sample_app_ug/performance_thread.rst
> +++ b/doc/guides/sample_app_ug/performance_thread.rst
> @@ -1194,7 +1194,7 @@ Tracing of events can be individually masked, and the mask may be programmed
>  at run time. An unmasked event results in a callback that provides information
>  about the event. The default callback simply prints trace information. The
>  default mask is 0 (all events off) the mask can be modified by calling the
> -function ``lthread_diagniostic_set_mask()``.
> +function ``lthread_diagnostic_set_mask()``.
>
>  It is possible register a user callback function to implement more
>  sophisticated diagnostic functions.
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 73ef0b41d3..a28f2ede9d 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -4732,7 +4732,7 @@ Sample Raw encapsulation rule
>
>  Raw encapsulation configuration can be set by the following commands
>
> -Eecapsulating VxLAN::
> +Encapsulating VxLAN::
>
>   testpmd> set raw_encap 4 eth src is 10:11:22:33:44:55 / vlan tci is 1
>          inner_type is 0x0800 / ipv4 / udp dst is 4789 / vxlan vni
> --
> 2.25.1
>


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd