doc: fix spellings

Fix some spelling errors and typos.

Signed-off-by: John McNamara <john.mcnamara@intel.com>

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 4019b41..934eb02 100644 (file)
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -252,7 +252,7 @@ SR-IOV: Prerequisites and sample Application Notes
       ip link set ens802f0 vf 0 mac a0:b0:c0:d0:e0:f0
 
 #. Assign VF to VM, and bring up the VM.
-   Please see the documenation for the*I40E/IXGBE/IGB Virtual Function Driver*.
+   Please see the documentation for the *I40E/IXGBE/IGB Virtual Function Driver*.
 
 
 Sample Application Notes

diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index a00c3b4..3dc6b00 100644 (file)
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -183,7 +183,7 @@ In addition, for improved performance, use -bsz "(32,32),(64,64),(32,32)" in loa
 Malicious Driver Detection not Supported
 ----------------------------------------
 
-The Intel x550 series NICs support a feature called MDD (Malcicious
+The Intel x550 series NICs support a feature called MDD (Malicious
 Driver Detection) which checks the behavior of the VF driver.
 If this feature is enabled, the VF must use the advanced context descriptor
 correctly and set the CC (Check Context) bit.
@@ -194,7 +194,7 @@ The only reason is the VF doesn't act as MDD required.
 There's significant performance impact to support MDD. DPDK should check if
 the advanced context descriptor should be set and set it. And DPDK has to ask
 the info about the header length from the upper layer, because parsing the
-packet itself is not acceptale. So, it's too expensive to support MDD.
+packet itself is not acceptable. So, it's too expensive to support MDD.
 When using kernel PF + DPDK VF on x550, please make sure using the kernel
 driver that disables MDD or can disable MDD. (Some kernel driver can use
 this CLI 'insmod ixgbe.ko MDD=0,0' to disable MDD. Some kernel driver disables

diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 9bb5bed..c11c7e7 100644 (file)
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -69,7 +69,7 @@ Path for IPsec Outbound traffic:
 *  Read packets from the port
 *  Outbound SP check using ACL of all IPv4 traffic
 *  Outbound SA lookup for packets that need IPsec protection
-*  Add ESP and outter IP header
+*  Add ESP and outer IP header
 *  Encryption/Digest
 *  Routing
 *  Write packet to port
@@ -200,8 +200,8 @@ hardware devices having priority.
 This means that if the application is using a single core and both hardware
 and software crypto devices are detected, hardware devices will be used.
 
-A way to achive the case where you want to force the use of virtual crypto
-devices is to whitelist the ethernet devices needed and therefore implicitely
+A way to achieve the case where you want to force the use of virtual crypto
+devices is to whitelist the Ethernet devices needed and therefore implicitly
 blacklisting all hardware crypto devices.
 
 For example, something like the following command line:

diff --git a/doc/guides/sample_app_ug/l2_forward_cat.rst b/doc/guides/sample_app_ug/l2_forward_cat.rst
index b6ab54d..285c3c7 100644 (file)
--- a/doc/guides/sample_app_ug/l2_forward_cat.rst
+++ b/doc/guides/sample_app_ug/l2_forward_cat.rst
@@ -236,7 +236,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 unassociated COS. COS are selected and
+for a sufficient number of un-associated 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/l2_forward_crypto.rst b/doc/guides/sample_app_ug/l2_forward_crypto.rst
index bffb17b..7cce51b 100644 (file)
--- a/doc/guides/sample_app_ug/l2_forward_crypto.rst
+++ b/doc/guides/sample_app_ug/l2_forward_crypto.rst
@@ -39,7 +39,7 @@ the Data Plane Development Kit (DPDK), in conjunction with the Cryptodev library
 Overview
 --------
 
-The L2 Forwarding with Crypto sample appplication performs a crypto operation (cipher/hash)
+The L2 Forwarding with Crypto sample application performs a crypto operation (cipher/hash)
 specified by the user from command line (or using the default values),
 with a crypto device capable of doing that operation,
 for each packet that is received on a RX_PORT and performs L2 forwarding.
@@ -231,7 +231,7 @@ to make sure that it is supported by the crypto devices.
 Crypto device initialization
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Once the cryption operation is defined, crypto devices are initialized.
+Once the encryption operation is defined, crypto devices are initialized.
 The crypto devices must be either bound to a DPDK driver (if they are physical devices)
 or created using the EAL option --vdev (if they are virtual devices),
 when running the application.
@@ -381,8 +381,8 @@ the mbuf which will be transformed is attached to it::
 Since no destination mbuf is set, the source mbuf will be overwritten
 after the operation is done (in-place).
 
-Crypto operation enqueueing/dequeueing
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Crypto operation enqueuing/dequeuing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Once the operation has been created, it has to be enqueued in one of the crypto devices.
 Before doing so, for performance reasons, the operation stays in a buffer.