doc: userguide: typo corrections

Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>
Signed-off-by: Josep Puigdemont <josep.puigdemont@linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>

6 files changed, 18 insertions, 18 deletions

diff --git a/doc/users-guide/users-guide-cls.adoc b/doc/users-guide/users-guide-cls.adoc
index a689826c7..359d225d8 100644
--- a/doc/users-guide/users-guide-cls.adoc
+++ b/doc/users-guide/users-guide-cls.adoc
@@ -7,7 +7,7 @@ prioritization, classification and scheduling of each packet, so that the
 software application can run faster, scale better and adhere to QoS
 requirements.
 
-The following API abstraction are not modelled after any existing product
+The following API abstraction are not modeled after any existing product
 implementation, but is instead defined in terms of what a typical data-plane
 application may require from such a platform, without sacrificing simplicity and
 avoiding ambiguity. Certain terms that are being used within the context of
diff --git a/doc/users-guide/users-guide-crypto.adoc b/doc/users-guide/users-guide-crypto.adoc
index 029f47b17..b44402adf 100644
--- a/doc/users-guide/users-guide-crypto.adoc
+++ b/doc/users-guide/users-guide-crypto.adoc
@@ -175,7 +175,7 @@ any software generated pseudo-random data. May not be available on all
 platforms.
 
 These form a hierarchy with BASIC being the lowest kind of random and TRUE
-behing the highest. The main API for accessing random data is:
+being the highest. The main API for accessing random data is:
 
 [source,c]
 -----
diff --git a/doc/users-guide/users-guide-ipsec.adoc b/doc/users-guide/users-guide-ipsec.adoc
index ac4eae85d..6af676620 100644
--- a/doc/users-guide/users-guide-ipsec.adoc
+++ b/doc/users-guide/users-guide-ipsec.adoc
@@ -381,7 +381,7 @@ any further application involvement. Only if a problem arises will the packet
 be returned to the application with an `odp_ipsec_packet_result_t` indicating
 the nature of the problem.
 
-Note that while operating in inline mode, asychronous lookaside operations are
+Note that while operating in inline mode, asynchronous lookaside operations are
 also permitted. This provide the application with additional flexibility if,
 for example, some packets need additional handling that cannot be supported
 directly with inline IPsec processing.
@@ -449,7 +449,7 @@ the application continues to receive and process IPsec events as normal.
 Disable completion is indicated by the application seeing an event of type
 `ODP_EVENT_IPSEC_STATUS` for this SA that contains an `odp_ipsec_status_id_t`
 of `ODP_IPSEC_STATUS_SA_DISABLE`. For inbound SAs, receipt of this event means
-that the application has seen all IPsec packets associatd with this SA that
+that the application has seen all IPsec packets associated with this SA that
 were pending at the time of the disable call. For outbound SAs, receipt of
 this event means that the application has seen all result events associated
 with packets sent via this SA.
diff --git a/doc/users-guide/users-guide-pktio.adoc b/doc/users-guide/users-guide-pktio.adoc
index 80a58d2fb..ef5cced66 100644
--- a/doc/users-guide/users-guide-pktio.adoc
+++ b/doc/users-guide/users-guide-pktio.adoc
@@ -114,8 +114,8 @@ typedef struct odp_pktio_param_t {
 ODP defines *"loop"* as a reserved name to indicate that this PktIO represents
 a loopback interface. Loopback interfaces are useful as a means of recycling
 packets back for reclassification after decryption or decapsulation, as well as
-for diagnostic or testing purposes. For example, when receiving IPSEC traffic,
-the classifier is able to recognize that the traffic is IPSEC, however until
+for diagnostic or testing purposes. For example, when receiving IPsec traffic,
+the classifier is able to recognize that the traffic is IPsec, however until
 the traffic is decrypted it is unable to say what that traffic contains.
 So following decryption, sending the decrypted packet back to a loopback
 interface allows the classifier to take a "second look" at the packet and
diff --git a/doc/users-guide/users-guide-tm.adoc b/doc/users-guide/users-guide-tm.adoc
index 251297335..55efb1b21 100644
--- a/doc/users-guide/users-guide-tm.adoc
+++ b/doc/users-guide/users-guide-tm.adoc
@@ -10,7 +10,7 @@ A given platform supporting this TM API could support one or more pure hardware
 based packet scheduling systems, one or more pure software based systems or one
 or more hybrid systems - where because of hardware constraints some of the
 packet scheduling is done in hardware and some is done in software.  In
-addition, there may also be additional API's beyond those described here for:
+addition, there may also be additional APIs beyond those described here for:
 
 - controlling advanced capabilities supported by specific hardware, software
 or hybrid subsystems
@@ -84,7 +84,7 @@ traffic, while allowing for less idle outputs.
 
 ==== Weighted Fair Queuing
 
-Weighted Fair Queuing (WFQ) is used to arbitrate amongst multiple input
+Weighted Fair Queuing (WFQ) is used to arbitrate among multiple input
 packets with the same priority.  Each input can be assigned a weight in the
 range MIN_WFQ_WEIGHT..MAX_WFQ_WEIGHT (nominally 1..255) that affects the way
 the algorithm chooses the next packet.  If all of the weights are equal AND all
@@ -158,7 +158,7 @@ final scheduling decision is controlled by equal priority schedulers,
 strict priority multiplexers, bandwidth shapers - at multiple levels - all
 forming a tree rooted at a single egress object.  In other words, all
 tm_queues and tm_nodes have the property that their logical "output" feeds
-into one fan-in of a subsequent tm_node or egresss object - forming a proper
+into one fan-in of a subsequent tm_node or egress object - forming a proper
 tree.
 
 .Hierarchical Scheduling
@@ -178,7 +178,7 @@ choice" of what packet/tm_queue should next be serviced.
 Tm_nodes are the main "entity"/object that a TM system is composed of. Each
 tm_node is a mini-TM subsystem of its own, but the interconnection and
 interplay of a multi-level "tree" of tm_nodes can allow the user to specify
-some very sophisticated behaviours. Each tm_node can contain a set of scheduler
+some very sophisticated behaviors. Each tm_node can contain a set of scheduler
 (one per strict priority level), a strict priority multiplexer, a bandwidth
 shaper and a WRED component - or a subset of these.
 
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 7f2ad69e2..d0687f97b 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -151,7 +151,7 @@ of the specification or other minor changes that do not affect either the
 syntax or semantics of the specification. Such changes in the API specification
 are expected to be rare. Increments to the minor level
 represent the introduction of new APIs or functional capabilities, or changes
-to he specified syntax or functional behavior of APIs and thus may require
+to the specified syntax or functional behavior of APIs and thus may require
 application source code changes. Such changes are well documented in the
 release notes for each revision of the specification. Finally, increments to
 the major level represent significant structural changes that most likely
@@ -247,14 +247,14 @@ polled by ODP _Threads_, or can pass through the _Classifier_ and sorted into
 Queues that represent individual flows. These queues can then be dispatched
 to application threads via the _Scheduler_.
 
-Threads, in term can invoke various ODP APIs to manipulate packet contents
+Threads, in turn can invoke various ODP APIs to manipulate packet contents
 prior to disposing of them. For output processing, packets make by directly
 queued to a PktIO output queue or else they may be handed to the _Traffic
 Manager_ for programmatic _Quality of Service (QoS)_ processing before winding
 up being transmitted (TX). Note that output interfaces may operate in
 _loopback_ mode, in which case packets sent to them are re-routed back to the
-input lines for "second pass" processing. For example, an incoming IPSec packet
-cannot be properly classified (beyond being IPSec traffic) until it is
+input lines for "second pass" processing. For example, an incoming IPsec packet
+cannot be properly classified (beyond being IPsec traffic) until it is
 decrypted. Once decrypted and its actual contents made visible, it can then
 be classified into its real flow.
 
@@ -576,7 +576,7 @@ values.
 Calling `odp_init_global()` establishes the ODP API framework and MUST be
 called before any other ODP API may be called. Note that it is only called
 once per application. A successful call to `odp_init_global()` returns rc = 0
-and sets the `instance` variable supplied as input to the call to an handle
+and sets the `instance` variable supplied as input to the call to a handle
 representing this unique ODP instance.
 
 The `odp_init_t` parameter is used to specify various customizations to the
@@ -661,7 +661,7 @@ area and how best to use ODP to achieve these goals.
 === Portability and Coexistence
 Because ODP offers a programming _framework_ rather than a programming
 _environment_, it is designed to be able to work alongside APIs offered by
-other frameworks with minimual interference. Therefore when we speak of
+other frameworks with minimal interference. Therefore when we speak of
 portability in an ODP context, we of necessity speak of portability of those
 portions of the application that make use of ODP APIs. If an application uses
 non-ODP APIs then those must be taken into consideration as well when
@@ -756,10 +756,10 @@ Architecture (ISA), such as x86-64 or AArch64. Binaries cannot directly port
 between ISAs--that requires a recompilation.
 
 Each ODP implementation will identify which ABI definition it supports, if any.
-When compiling against an ODP implementation in ABI compabitilty mode, the
+When compiling against an ODP implementation in ABI compatibility mode, the
 resulting binary is automatically binary compatible with all other ODP
 implementations that share this ABI. For example, for the x86-64 ISA, both
-the `odp-linux` and `odp-dpdk` implemtations are a common ABI.
+the `odp-linux` and `odp-dpdk` implementations are a common ABI.
 
 == Shared memory
 === Allocating shared memory