From: John McNamara Date: Thu, 7 Apr 2016 21:14:48 +0000 (+0100) Subject: doc: fix spellings X-Git-Tag: spdx-start~7031 X-Git-Url: http://git.droids-corp.org/?a=commitdiff_plain;h=8d257235696b250a68b65422dfbea0418cc3c5a8;p=dpdk.git doc: fix spellings Fix some spelling errors and typos. Signed-off-by: John McNamara --- diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index 4019b41bd6..934eb02764 100644 --- 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 a00c3b4a07..3dc6b004df 100644 --- 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 9bb5bed618..c11c7e7e3f 100644 --- 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 b6ab54d80d..285c3c74d0 100644 --- 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 bffb17b1c0..7cce51be9e 100644 --- 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.