[dpdk-dev] [PATCH] doc: fixed spellings and typos
John McNamara
john.mcnamara at intel.com
Fri Apr 24 14:58:11 CEST 2015
Fixed several typos and spelling errors in guide docs.
Signed-off-by: John McNamara <john.mcnamara at intel.com>
---
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_dpdk.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/quick_start.rst | 4 +--
doc/guides/linux_gsg/sys_reqs.rst | 8 +++---
doc/guides/nics/intel_vf.rst | 4 +--
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/pcap_ring.rst | 4 +--
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/dev_kit_root_make_help.rst | 17 ++++++++++--
doc/guides/prog_guide/env_abstraction_layer.rst | 8 +++---
doc/guides/prog_guide/index.rst | 4 +--
.../prog_guide/ip_fragment_reassembly_lib.rst | 16 ++++++------
doc/guides/prog_guide/ivshmem_lib.rst | 6 ++---
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
.../prog_guide/link_bonding_poll_mode_drv_lib.rst | 6 ++---
doc/guides/prog_guide/mbuf_lib.rst | 6 ++---
.../prog_guide/packet_classif_access_ctrl.rst | 12 ++++-----
doc/guides/prog_guide/packet_framework.rst | 22 ++++++++--------
doc/guides/prog_guide/qos_framework.rst | 4 +--
doc/guides/prog_guide/source_org.rst | 2 +-
doc/guides/prog_guide/timer_lib.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 6 ++---
doc/guides/prog_guide/writing_efficient_code.rst | 2 +-
doc/guides/rel_notes/abi.rst | 4 +--
doc/guides/rel_notes/faq.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 16 ++++++------
doc/guides/rel_notes/resolved_issues.rst | 30 +++++++++++-----------
doc/guides/rel_notes/supported_features.rst | 28 ++++++++++----------
doc/guides/rel_notes/updating_apps.rst | 4 +--
doc/guides/sample_app_ug/dist_app.rst | 2 +-
doc/guides/sample_app_ug/ip_frag.rst | 2 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 2 +-
doc/guides/sample_app_ug/ipv4_multicast.rst | 4 +--
doc/guides/sample_app_ug/l2_forward_job_stats.rst | 8 +++---
doc/guides/sample_app_ug/l3_forward_power_man.rst | 2 +-
doc/guides/sample_app_ug/load_balancer.rst | 2 +-
doc/guides/sample_app_ug/multi_process.rst | 4 +--
doc/guides/sample_app_ug/netmap_compatibility.rst | 2 +-
doc/guides/sample_app_ug/packet_ordering.rst | 4 +--
doc/guides/sample_app_ug/quota_watermark.rst | 4 +--
doc/guides/sample_app_ug/test_pipeline.rst | 8 +++---
doc/guides/sample_app_ug/timer.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 12 ++++-----
doc/guides/sample_app_ug/vm_power_management.rst | 6 ++---
doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 4 +--
doc/guides/testpmd_app_ug/intro.rst | 4 +--
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +--
48 files changed, 159 insertions(+), 146 deletions(-)
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index e198c6a..acd0311 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -136,7 +136,7 @@ The EAL options for FreeBSD* are as follows:
(multiple -b options are allowed).
* --use-device
- : use the specified ethernet device(s) only. Use comma-separate
+ : use the specified Ethernet device(s) only. Use comma-separate
<[domain:]bus:devid.func> values. Cannot be used with -b option.
* -r NUM
diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst
index 5f0f3ae..e3a0b46 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -166,7 +166,7 @@ Loading Modules to Enable Userspace IO for DPDK
-----------------------------------------------
To run any DPDK application, a suitable uio module can be loaded into the running kernel.
-In many cases, the standard uio_pci_generic module included in the linux kernel
+In many cases, the standard uio_pci_generic module included in the Linux kernel
can provide the uio capability. This module can be loaded using the command
.. code-block:: console
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 1abe99c..e0de2f5 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -119,7 +119,7 @@ The EAL options are as follows:
* -b <domain:bus:devid.func>: blacklisting of ports; prevent EAL from using specified PCI device (multiple -b options are allowed)
-* --use-device: use the specified ethernet device(s) only. Use comma-separate <[domain:]bus:devid.func> values. Cannot be used with -b option
+* --use-device: use the specified Ethernet device(s) only. Use comma-separate <[domain:]bus:devid.func> values. Cannot be used with -b option
* --socket-mem: Memory to allocate from hugepages on specific sockets
diff --git a/doc/guides/linux_gsg/quick_start.rst b/doc/guides/linux_gsg/quick_start.rst
index a1dd3ee..b07fc87 100644
--- a/doc/guides/linux_gsg/quick_start.rst
+++ b/doc/guides/linux_gsg/quick_start.rst
@@ -226,7 +226,7 @@ The following selection demonstrates the starting of the DPDK UIO driver.
Loading DPDK UIO module
The following selection demonstrates the creation of hugepages in a NUMA system.
-1024 2 Mbyte pages are assigned to each node.
+1024 2 MByte pages are assigned to each node.
The result is that the application should use -m 4096 for starting the application to access both memory areas
(this is done automatically if the -m option is not provided).
@@ -239,7 +239,7 @@ The result is that the application should use -m 4096 for starting the applicati
Option: 15
Removing currently reserved hugepages
- nmounting /mnt/huge and removing directory
+ mounting /mnt/huge and removing directory
Input the number of 2MB pages for each node
Example: to have 128MB of hugepages available per node,
enter '64' to reserve 64 * 2MB pages on each node
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index 7cc214f..ebed418 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -61,7 +61,7 @@ Compilation of the DPDK
* coreutils: cmp, sed, grep, arch
-* gcc: versions 4.5.x or later is recommended for i686/x86_64. versions 4.8.x or later is recommanded
+* gcc: versions 4.5.x or later is recommended for i686/x86_64. versions 4.8.x or later is recommended
for ppc_64 and x86_x32 ABI. On some distributions, some specific compiler flags and linker flags are enabled by
default and affect performance (- fstack-protector, for example). Please refer to the documentation
of your distribution and to gcc -dumpspecs.
@@ -81,7 +81,7 @@ Compilation of the DPDK
.. note::
x86_x32 ABI is currently supported with distribution packages only on Ubuntu
- higher than 13.10 or recent debian distribution. The only supported compiler is gcc 4.8+.
+ higher than 13.10 or recent Debian distribution. The only supported compiler is gcc 4.8+.
.. note::
@@ -121,7 +121,7 @@ System Software
For details of the patches needed to use the DPDK with earlier kernel versions,
see the DPDK FAQ included in the *DPDK Release Notes*.
-Note also that Redhat* Linux* 6.2 and 6.3 uses a 2.6.32 kernel that already has all the necessary patches applied.
+Note also that Red hat* Linux* 6.2 and 6.3 uses a 2.6.32 kernel that already has all the necessary patches applied.
* glibc >= 2.7 (for features related to cpuset)
@@ -139,7 +139,7 @@ Note also that Redhat* Linux* 6.2 and 6.3 uses a 2.6.32 kernel that already has
* Kernel configuration
- In the Fedora* OS and other common distributions, such as Ubuntu*, or RedHat Enterprise Linux*,
+ In the Fedora* OS and other common distributions, such as Ubuntu*, or Red Hat Enterprise Linux*,
the vendor supplied kernel configurations can be used to run most DPDK applications.
For other kernel builds, options which should be enabled for DPDK include:
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
index e773627..eeca973 100644
--- a/doc/guides/nics/intel_vf.rst
+++ b/doc/guides/nics/intel_vf.rst
@@ -55,7 +55,7 @@ Therefore, a NIC is logically distributed among multiple virtual machines (as sh
while still having global data in common to share with the Physical Function and other Virtual Functions.
The DPDK fm10kvf, i40evf, igbvf or ixgbevf as a Poll Mode Driver (PMD) serves for the Intel® 82576 Gigabit Ethernet Controller,
Intel® Ethernet Controller I350 family, Intel® 82599 10 Gigabit Ethernet Controller NIC,
-Intel® Fortville 10/40 Gigabit Ethernet Controller NIC's virtual PCI function,or PCIE host-interface of the Intel Ethernet Switch
+Intel® Fortville 10/40 Gigabit Ethernet Controller NIC's virtual PCI function, or PCIe host-interface of the Intel Ethernet Switch
FM10000 Series.
Meanwhile the DPDK Poll Mode Driver (PMD) also supports "Physical Function" of such NIC's on the host.
@@ -536,7 +536,7 @@ The setup procedure is as follows:
Run the DPDK l2fwd sample application in the Guest OS with Hugepages enabled.
For the expected benchmark performance, you must pin the cores from the Guest OS to the Host OS (taskset can be used to do this) and
- you must also look at the PCI Bus layout on the board to ensure you are not running the traffic over the QPI Inteface.
+ you must also look at the PCI Bus layout on the board to ensure you are not running the traffic over the QPI Interface.
.. note::
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 1216d95..ac2dd56 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -239,7 +239,7 @@ Getting Mellanox OFED
~~~~~~~~~~~~~~~~~~~~~
While these libraries and kernel modules are available on OpenFabrics
-Aliance's `website <https://www.openfabrics.org/>`_ and provided by package
+Alliance's `website <https://www.openfabrics.org/>`_ and provided by package
managers on most distributions, this PMD requires Ethernet extensions that
may not be supported at the moment (this is a work in progress).
diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst
index 702da89..5d65dc6 100644
--- a/doc/guides/nics/pcap_ring.rst
+++ b/doc/guides/nics/pcap_ring.rst
@@ -50,7 +50,7 @@ the DPDK also includes two pure-software PMDs. These two drivers are:
Using the Drivers from the EAL Command Line
-------------------------------------------
-For ease of use, the DPDK EAL also has been extended to allow pseudo-ethernet devices,
+For ease of use, the DPDK EAL also has been extended to allow pseudo-Ethernet devices,
using one or more of these drivers,
to be created at application startup time during EAL initialization.
@@ -226,7 +226,7 @@ and use these as a source of packet input to the application.
Usage Examples
^^^^^^^^^^^^^^
-To create two pseudo-ethernet ports where all traffic sent to a port is looped back
+To create two pseudo-Ethernet ports where all traffic sent to a port is looped back
for reception on the same port (error handling omitted for clarity):
.. code-block:: c
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index cf5c96f..5bfef58 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -317,7 +317,7 @@ Useful Variables Provided by the Build System
When compiling an external application, the variable points to the root of external application sources.
* RTE_OUTPUT: The path to which output files are written.
- Typically, it is $(RTE_SRCDIR)/build, but it can be overriden by the O= option in the make command line.
+ Typically, it is $(RTE_SRCDIR)/build, but it can be overridden by the O= option in the make command line.
* RTE_TARGET: A string identifying the target for which we are building.
The format is arch-machine-execenv-toolchain.
diff --git a/doc/guides/prog_guide/dev_kit_root_make_help.rst b/doc/guides/prog_guide/dev_kit_root_make_help.rst
index 4f30192..333b007 100644
--- a/doc/guides/prog_guide/dev_kit_root_make_help.rst
+++ b/doc/guides/prog_guide/dev_kit_root_make_help.rst
@@ -154,9 +154,22 @@ Test Targets
Documentation Targets
---------------------
-* doxydoc
+* doc
+
+ Generate the Doxygen documentation (API, html and pdf).
+
+* doc-api-html
+
+ Generate the Doxygen API documentation in html.
+
+* doc-guides-html
+
+ Generate the guides documentation in html.
+
+* doc-guides-pdf
+
+ Generate the guides documentation in pdf.
- Generate the Doxygen documentation (pdf only).
Deps Targets
------------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index 06289ed..4ecbe6a 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -224,7 +224,7 @@ However, alternately it is possible to utilize the idle cycles available to take
the full capability of the CPU.
By taking advantage of cgroup, the CPU utilization quota can be simply assigned.
-This gives another way to improve the CPU efficienct, however, there is a prerequisite;
+This gives another way to improve the CPU efficiency, however, there is a prerequisite;
DPDK must handle the context switching between multiple pthreads per core.
For further flexibility, it is useful to set pthread affinity not only to a CPU but to a CPU set.
@@ -284,7 +284,7 @@ Those TLS include *_cpuset* and *_socket_id*:
* *_cpuset* stores the CPUs bitmap to which the pthread is affinitized.
-* *_socket_id* stores the NUMA node of the CPU set. If the CPUs in CPU set belong to different NUMA node, the *_socket_id* will be set to SOCKTE_ID_ANY.
+* *_socket_id* stores the NUMA node of the CPU set. If the CPUs in CPU set belong to different NUMA node, the *_socket_id* will be set to SOCKET_ID_ANY.
.. _known_issue_label:
@@ -302,7 +302,7 @@ Known Issues
+ rte_ring
rte_ring supports multi-producer enqueue and multi-consumer dequeue.
- However, it is non-preemptive, this has a knock on effect of making rte_mempool non-preemtable.
+ However, it is non-preemptive, this has a knock on effect of making rte_mempool non-preemptable.
.. note::
@@ -329,7 +329,7 @@ Known Issues
``RTE_RING_PAUSE_REP_COUNT`` is defined for rte_ring to reduce contention. It's mainly for case 2, a yield is issued after number of times pause repeat.
It adds a sched_yield() syscall if the thread spins for too long while waiting on the other thread to finish its operations on the ring.
- This gives the pre-empted thread a chance to proceed and finish with the ring enqueue/dequeue operation.
+ This gives the preempted thread a chance to proceed and finish with the ring enqueue/dequeue operation.
+ rte_timer
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index a9966a0..57d516a 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -98,7 +98,7 @@ Programmer's Guide
:ref:`Figure 9. An mbuf with Three Segments <pg_figure_9>`
-:ref:`Figure 16. Memory Sharing inthe Intel® DPDK Multi-process Sample Application <pg_figure_16>`
+:ref:`Figure 16. Memory Sharing in the Intel® DPDK Multi-process Sample Application <pg_figure_16>`
:ref:`Figure 17. Components of an Intel® DPDK KNI Application <pg_figure_17>`
@@ -194,7 +194,7 @@ Programmer's Guide
:ref:`Table 22. Configuration parameters common for all hash table types <pg_table_22>`
-:ref:`Table 23. Configuration parameters specific to extendible bucket hash table <pg_table_23>`
+:ref:`Table 23. Configuration parameters specific to extendable bucket hash table <pg_table_23>`
:ref:`Table 24. Configuration parameters specific to pre-computed key signature hash table <pg_table_24>`
diff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
index 7d6bdaa..1d3d4ac 100644
--- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
+++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
@@ -36,10 +36,10 @@ The IP Fragmentation and Reassembly Library implements IPv4 and IPv6 packet frag
Packet fragmentation
--------------------
-Packet fragmentation routines devide input packet into number of fragments.
+Packet fragmentation routines divide input packet into number of fragments.
Both rte_ipv4_fragment_packet() and rte_ipv6_fragment_packet() functions assume that input mbuf data
points to the start of the IP header of the packet (i.e. L2 header is already stripped out).
-To avoid copying fo the actual packet's data zero-copy technique is used (rte_pktmbuf_attach).
+To avoid copying of the actual packet's data zero-copy technique is used (rte_pktmbuf_attach).
For each fragment two new mbufs are created:
* Direct mbuf -- mbuf that will contain L3 header of the new fragment.
@@ -50,7 +50,7 @@ For each fragment two new mbufs are created:
Then L3 header is copied from the original mbuf into the 'direct' mbuf and updated to reflect new fragmented status.
Note that for IPv4, header checksum is not recalculated and is set to zero.
-Finally 'direct' and 'indirect' mbufs for each fragnemt are linked together via mbuf's next filed to compose a packet for the new fragment.
+Finally 'direct' and 'indirect' mbufs for each fragment are linked together via mbuf's next filed to compose a packet for the new fragment.
The caller has an ability to explicitly specify which mempools should be used to allocate 'direct' and 'indirect' mbufs from.
@@ -66,9 +66,9 @@ Fragment table maintains information about already received fragments of the pac
Each IP packet is uniquely identified by triple <Source IP address>, <Destination IP address>, <ID>.
-Note that all update/lookup operations on Fragmen Table are not thread safe.
+Note that all update/lookup operations on Fragment Table are not thread safe.
So if different execution contexts (threads/processes) will access the same table simultaneously,
-then some exernal syncing mechanism have to be provided.
+then some external syncing mechanism have to be provided.
Each table entry can hold information about packets consisting of up to RTE_LIBRTE_IP_FRAG_MAX (by default: 4) fragments.
@@ -80,11 +80,11 @@ Code example, that demonstrates creation of a new Fragment table:
bucket_num = max_flow_num + max_flow_num / 4;
frag_tbl = rte_ip_frag_table_create(max_flow_num, bucket_entries, max_flow_num, frag_cycles, socket_id);
-Internally Fragmen table is a simple hash table.
+Internally Fragment table is a simple hash table.
The basic idea is to use two hash functions and <bucket_entries> \* associativity.
This provides 2 \* <bucket_entries> possible locations in the hash table for each key.
When the collision occurs and all 2 \* <bucket_entries> are occupied,
-instead of resinserting existing keys into alternative locations, ip_frag_tbl_add() just returns a faiure.
+instead of reinserting existing keys into alternative locations, ip_frag_tbl_add() just returns a failure.
Also, entries that resides in the table longer then <max_cycles> are considered as invalid,
and could be removed/replaced by the new ones.
@@ -120,7 +120,7 @@ These functions are responsible for:
b) If no, then return a NULL to the caller.
-If at any stage of packet processing an error is envountered
+If at any stage of packet processing an error is encountered
(e.g: can't insert new entry into the Fragment Table, or invalid/timed-out fragment),
then the function will free all associated with the packet fragments,
mark the table entry as invalid and return NULL to the caller.
diff --git a/doc/guides/prog_guide/ivshmem_lib.rst b/doc/guides/prog_guide/ivshmem_lib.rst
index c76d2b3..75175fa 100644
--- a/doc/guides/prog_guide/ivshmem_lib.rst
+++ b/doc/guides/prog_guide/ivshmem_lib.rst
@@ -32,7 +32,7 @@ IVSHMEM Library
===============
The DPDK IVSHMEM library facilitates fast zero-copy data sharing among virtual machines
-(host-to-guest or guest-to-guest) by means of QEUMU's IVSHMEM mechanism.
+(host-to-guest or guest-to-guest) by means of QEMU's IVSHMEM mechanism.
The library works by providing a command line for QEMU to map several hugepages into a single IVSHMEM device.
For the guest to know what is inside any given IVSHMEM device
@@ -107,7 +107,7 @@ Best Practices for Writing IVSHMEM Applications
-----------------------------------------------
When considering the use of IVSHMEM for sharing memory, security implications need to be carefully evaluated.
-IVSHMEM is not suitable for untrusted guests, as IVSHMEM is essentially a window into the host processs memory.
+IVSHMEM is not suitable for untrusted guests, as IVSHMEM is essentially a window into the host process memory.
This also has implications for the multiple VM scenarios.
While the IVSHMEM library tries to share as little memory as possible,
it is quite probable that data designated for one VM might also be present in an IVSMHMEM device designated for another VM.
@@ -137,7 +137,7 @@ For performance reasons,
it is best to pin host processes and QEMU processes to different cores so that they do not interfere with each other.
If NUMA support is enabled, it is also desirable to keep host process' hugepage memory and QEMU process on the same NUMA node.
-For the best performance across all NUMA nodes, each QUEMU core should be pinned to host CPU core on the appropriate NUMA node.
+For the best performance across all NUMA nodes, each QEMU core should be pinned to host CPU core on the appropriate NUMA node.
QEMU's virtual NUMA nodes should also be set up to correspond to physical NUMA nodes.
More on how to set up DPDK and QEMU NUMA support can be found in *DPDK Getting Started Guide* and
`QEMU documentation <http://qemu.weilnetz.de/qemu-doc.html>`_ respectively.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index bac2215..bab376a 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -267,7 +267,7 @@ Then, using the qemu-kvm command with the -netdev option to assign such raw sock
.. note::
- The key word tap must exist as qemu-kvm now only supports vhost with a tap beckend, so here we cheat qemu-kvm by an existing fd.
+ The key word tap must exist as qemu-kvm now only supports vhost with a tap backend, so here we cheat qemu-kvm by an existing fd.
Compatibility Configure Option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
index 24a1a36..ae9b516 100644
--- a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
+++ b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
@@ -1,5 +1,5 @@
.. BSD LICENSE
- Copyright(c) 2010-2014 ntel Corporation. All rights reserved.
+ Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
All rights reserved.
Redistribution and use in source and binary forms, with or without
@@ -87,7 +87,7 @@ Currently the Link Bonding PMD library supports 4 modes of operation:
This mode provides transmit load balancing (based on the selected
transmission policy) and fault tolerance. The default policy (layer2) uses
a simple calculation based on the packet flow source and destination MAC
- addresses aswell as the number of active slaves available to the bonded
+ addresses as well as the number of active slaves available to the bonded
device to classify the packet to a specific slave to transmit on. Alternate
transmission policies supported are layer 2+3, this takes the IP source and
destination addresses into the calculation of the transmit slave port and
@@ -95,7 +95,7 @@ Currently the Link Bonding PMD library supports 4 modes of operation:
destination addresses as well as the TCP/UDP source and destination port.
.. note::
- The colouring differences of the packets are used to identify different flow
+ The coloring differences of the packets are used to identify different flow
classification calculated by the selected transmit policy
diff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst
index 8f546e0..338f7da 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -167,7 +167,7 @@ a vxlan-encapsulated tcp packet:
mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM
set out_ip checksum to 0 in the packet
- This is supported on hardwares advertising DEV_TX_OFFLOAD_IPV4_CKSUM.
+ This is supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM.
- calculate checksum of out_ip and out_udp::
@@ -177,7 +177,7 @@ a vxlan-encapsulated tcp packet:
set out_ip checksum to 0 in the packet
set out_udp checksum to pseudo header using rte_ipv4_phdr_cksum()
- This is supported on hardwares advertising DEV_TX_OFFLOAD_IPV4_CKSUM
+ This is supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM
and DEV_TX_OFFLOAD_UDP_CKSUM.
- calculate checksum of in_ip::
@@ -188,7 +188,7 @@ a vxlan-encapsulated tcp packet:
set in_ip checksum to 0 in the packet
This is similar to case 1), but l2_len is different. It is supported
- on hardwares advertising DEV_TX_OFFLOAD_IPV4_CKSUM.
+ on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM.
Note that it can only work if outer L4 checksum is 0.
- calculate checksum of in_ip and in_tcp::
diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
index 210b020..a9a5815 100644
--- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
+++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
@@ -281,14 +281,14 @@ for each of them.
Depending on the rule-set, it might reduce RT memory requirements but might
increase classification time.
There is a possibility at build-time to specify maximum memory limit for internal RT structures for given AC context.
-It could be done via **max_size** field of the **rte_acl_config** strucure.
+It could be done via **max_size** field of the **rte_acl_config** structure.
Setting it to the value greater than zero, instructs rte_acl_build() to:
-* attempt to minimise number of tries in the RT table, but
+* attempt to minimize number of tries in the RT table, but
* make sure that size of RT table wouldn't exceed given value.
-Setting it to zero makes rte_acl_build() to use the default behaviour:
-try to minimise size of the RT structures, but doesn't expose any hard limit on it.
+Setting it to zero makes rte_acl_build() to use the default behavior:
+try to minimize size of the RT structures, but doesn't expose any hard limit on it.
That gives the user the ability to decisions about performance/space trade-off.
For example:
@@ -304,12 +304,12 @@ For example:
* populated with rules AC context and cfg filled properly.
*/
- /* try to build AC context, with RT strcutures less then 8MB. */
+ /* try to build AC context, with RT structures less then 8MB. */
cfg.max_size = 0x800000;
ret = rte_acl_build(acx, &cfg);
/*
- * RT strcutures can't fit into 8MB for given context.
+ * RT structures can't fit into 8MB for given context.
* Try to build without exposing any hard limit.
*/
if (ret == -ERANGE) {
diff --git a/doc/guides/prog_guide/packet_framework.rst b/doc/guides/prog_guide/packet_framework.rst
index 8e8e32f..2056c4f 100644
--- a/doc/guides/prog_guide/packet_framework.rst
+++ b/doc/guides/prog_guide/packet_framework.rst
@@ -330,7 +330,7 @@ so the key search can be narrowed down from the full set of keys currently in th
to just the set of keys currently in the identified table bucket.
The performance of the hash table lookup operation is greatly improved,
-provided that the table keys are evenly distributed amongst the hash table buckets,
+provided that the table keys are evenly distributed among the hash table buckets,
which can be achieved by using a hash function with uniform distribution.
The rule to map a key to its bucket can simply be to use the key signature (modulo the number of table buckets) as the table bucket ID:
@@ -439,7 +439,7 @@ The possible options are:
When a key needs to be picked and dropped, the first candidate for drop, i.e. the current LRU key, is always picked.
The LRU logic requires maintaining specific data structures per each bucket.
-#. **Extendible Bucket Hash Table.**
+#. **Extendable Bucket Hash Table.**
The bucket is extended with space for 4 more keys.
This is done by allocating additional memory at table initialization time,
which is used to create a pool of free keys (the size of this pool is configurable and always a multiple of 4).
@@ -449,11 +449,11 @@ The possible options are:
when the key to be deleted is the only key that was used within its group of 4 keys at that time.
On key lookup operation, if the current bucket is in extended state and a match is not found in the first group of 4 keys,
the search continues beyond the first group of 4 keys, potentially until all keys in this bucket are examined.
- The extendible bucket logic requires maintaining specific data structures per table and per each bucket.
+ The extendable bucket logic requires maintaining specific data structures per table and per each bucket.
.. _pg_table_23:
-**Table 23 Configuration Parameters Specific to Extendible Bucket Hash Table**
+**Table 23 Configuration Parameters Specific to Extendable Bucket Hash Table**
+---+---------------------------+--------------------------------------------------+
| # | Parameter | Details |
@@ -576,7 +576,7 @@ either with pre-computed signature or "do-sig").
| | | | | |
+---+-------------------------+------------------------------+---------------------------+-------------------------------+
| 2 | Bucket extensions array | n_buckets_ext (configurable) | 32 | This array is only created |
-| | | | | for extendible bucket tables. |
+| | | | | for extendable bucket tables. |
| | | | | |
+---+-------------------------+------------------------------+---------------------------+-------------------------------+
| 3 | Key array | n_keys | key_size (configurable) | Keys added to the hash table. |
@@ -601,7 +601,7 @@ either with pre-computed signature or "do-sig").
| | | | Entry 0 stores the index (0 .. 3) of the MRU key, while entry 3 |
| | | | stores the index of the LRU key. |
| | | | |
-| | | | For extendible bucket tables, this field represents the next |
+| | | | For extendable bucket tables, this field represents the next |
| | | | pointer (i.e. the pointer to the next group of 4 keys linked to |
| | | | the current bucket). The next pointer is not NULL if the bucket |
| | | | is currently extended or NULL otherwise. |
@@ -867,7 +867,7 @@ Figure 37, Figure 38, Table 30 and 31 detail the main data structures used to im
| | | | | |
+---+-------------------------+------------------------------+----------------------+------------------------------------+
| 2 | Bucket extensions array | n_buckets_ext (configurable) | *8-byte key size:* | This array is only created for |
-| | | | | extendible bucket tables. |
+| | | | | extendable bucket tables. |
| | | | | |
| | | | 64 + 4 x entry_size | |
| | | | | |
@@ -888,7 +888,7 @@ Figure 37, Figure 38, Table 30 and 31 detail the main data structures used to im
+===+===============+====================+===============================================================================+
| 1 | Valid | 8 | Bit X (X = 0 .. 3) is set to 1 if key X is valid or to 0 otherwise. |
| | | | |
-| | | | Bit 4 is only used for extendible bucket tables to help with the |
+| | | | Bit 4 is only used for extendable bucket tables to help with the |
| | | | implementation of the branchless logic. In this case, bit 4 is set to 1 if |
| | | | next pointer is valid (not NULL) or to 0 otherwise. |
| | | | |
@@ -897,7 +897,7 @@ Figure 37, Figure 38, Table 30 and 31 detail the main data structures used to im
| | | | stored as array of 4 entries of 2 bytes each. Entry 0 stores the index |
| | | | (0 .. 3) of the MRU key, while entry 3 stores the index of the LRU key. |
| | | | |
-| | | | For extendible bucket tables, this field represents the next pointer (i.e. |
+| | | | For extendable bucket tables, this field represents the next pointer (i.e. |
| | | | the pointer to the next group of 4 keys linked to the current bucket). The |
| | | | next pointer is not NULL if the bucket is currently extended or NULL |
| | | | otherwise. |
@@ -962,7 +962,7 @@ Additional notes:
#. The pipelined version of the bucket search algorithm is executed only if there are at least 5 packets in the burst of input packets.
If there are less than 5 packets in the burst of input packets, a non-optimized implementation of the bucket search algorithm is executed.
-#. For extendible bucket hash tables only,
+#. For extendable bucket hash tables only,
once the pipelined version of the bucket search algorithm has been executed for all the packets in the burst of input packets,
the non-optimized implementation of the bucket search algorithm is also executed for any packets that did not produce a lookup hit,
but have the bucket in extended state.
@@ -1148,7 +1148,7 @@ Mechanisms to share the same table between multiple threads:
The threads performing table entry add/delete operations send table update requests to the reader (typically through message passing queues),
which does the actual table updates and then sends the response back to the request initiator.
-#. **Single writer thread performing table entry add/delete operations and multiple reader threads that performtable lookup operations with read-only access to the table entries.**
+#. **Single writer thread performing table entry add/delete operations and multiple reader threads that perform table lookup operations with read-only access to the table entries.**
The reader threads use the main table copy while the writer is updating the mirror copy.
Once the writer update is done, the writer can signal to the readers and busy wait until all readers swaps between the mirror copy (which now becomes the main copy) and
the mirror copy (which now becomes the main copy).
diff --git a/doc/guides/prog_guide/qos_framework.rst b/doc/guides/prog_guide/qos_framework.rst
index b609841..98d8714 100644
--- a/doc/guides/prog_guide/qos_framework.rst
+++ b/doc/guides/prog_guide/qos_framework.rst
@@ -881,7 +881,7 @@ The evolution of the WRR design solution from simple to complex is shown in Tabl
| | | | | introducing a cost per byte that is different for each |
| | | | | queue. Queues with lower weights have a higher cost per |
| | | | | byte. This way, it is still meaningful to compare the |
-| | | | | consumption amongst different queues in order to select |
+| | | | | consumption among different queues in order to select |
| | | | | the next queue. |
| | | | | |
| | | | | w(i) = Weight of queue #i |
@@ -984,7 +984,7 @@ with the third approach selected for implementation.
+=====+===========================+=========================================================================+
| 1 | Don't care | First come, first served. |
| | | |
-| | | This approach is not fair amongst subport member pipes, as pipes that |
+| | | This approach is not fair among subport member pipes, as pipes that |
| | | are served first will use up as much bandwidth for TC X as they need, |
| | | while pipes that are served later will receive poor service due to |
| | | bandwidth for TC X at the subport level being scarce. |
diff --git a/doc/guides/prog_guide/source_org.rst b/doc/guides/prog_guide/source_org.rst
index 061f107..1bce0b8 100644
--- a/doc/guides/prog_guide/source_org.rst
+++ b/doc/guides/prog_guide/source_org.rst
@@ -114,7 +114,7 @@ The examples directory contains sample applications that show how libraries can
examples
+-- cmdline # Example of using cmdline library
+-- dpdk_qat # Example showing integration with Intel QuickAssist
- +-- exception_path # Sending packets to and from Linux ethernet device (TAP)
+ +-- exception_path # Sending packets to and from Linux Ethernet device (TAP)
+-- helloworld # Helloworld basic example
+-- ip_reassembly # Example showing IP Reassembly
+-- ip_fragmentation # Example showing IPv4 Fragmentation
diff --git a/doc/guides/prog_guide/timer_lib.rst b/doc/guides/prog_guide/timer_lib.rst
index 7baf034..f437417 100644
--- a/doc/guides/prog_guide/timer_lib.rst
+++ b/doc/guides/prog_guide/timer_lib.rst
@@ -85,7 +85,7 @@ the expiry time of the first list entry is maintained within the per-core timer
On 64-bit platforms, this value can be checked without the need to take a lock on the overall structure.
(Since expiry times are maintained as 64-bit values,
a check on the value cannot be done on 32-bit platforms without using either a compare-and-swap (CAS) instruction or using a lock,
-so this additional check is skipped in favour of checking as normal once the lock has been taken.)
+so this additional check is skipped in favor of checking as normal once the lock has been taken.)
On both 64-bit and 32-bit platforms,
a call to rte_timer_manage() returns without taking a lock in the case where the timer list for the calling core is empty.
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a52fa50..48e1fff 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -46,7 +46,7 @@ Vhost API Overview
rte_vhost_driver_register registers the vhost driver into the system.
For vhost-cuse, character device file will be created under the /dev directory.
Character device name is specified as the parameter.
- For vhost-user, a unix domain socket server will be created with the parameter as
+ For vhost-user, a Unix domain socket server will be created with the parameter as
the local socket path.
* Vhost session start
@@ -102,7 +102,7 @@ When the release call is released, vhost will destroy the device.
Vhost user implementation
~~~~~~~~~~~~~~~~~~~~~~~~~
-When vSwitch registers a vhost driver, it will create a unix domain socket server
+When vSwitch registers a vhost driver, it will create a Unix domain socket server
into the system. This server will listen for a connection and process the vhost message from
QEMU simulator.
@@ -110,7 +110,7 @@ When there is a new socket connection, it means a new virtio device has been cre
the guest virtual machine, and the vhost driver will create a vhost device for this virtio device.
For messages with a file descriptor, the file descriptor could be directly used in the vhost
-process as it is already installed by unix domain socket.
+process as it is already installed by Unix domain socket.
* VHOST_SET_MEM_TABLE
* VHOST_SET_VRING_KICK
diff --git a/doc/guides/prog_guide/writing_efficient_code.rst b/doc/guides/prog_guide/writing_efficient_code.rst
index 9a7b31b..613db88 100644
--- a/doc/guides/prog_guide/writing_efficient_code.rst
+++ b/doc/guides/prog_guide/writing_efficient_code.rst
@@ -215,7 +215,7 @@ Setting the Target CPU Type
The DPDK supports CPU microarchitecture-specific optimizations by means of CONFIG_RTE_MACHINE option
in the DPDK configuration file.
-The degree of optimization depends on the compiler's ability to optimize for a specitic microarchitecture,
+The degree of optimization depends on the compiler's ability to optimize for a specific microarchitecture,
therefore it is preferable to use the latest compiler versions whenever possible.
If the compiler version does not support the specific feature set (for example, the Intel® AVX instruction set),
diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst
index bd25485..f00a6ee 100644
--- a/doc/guides/rel_notes/abi.rst
+++ b/doc/guides/rel_notes/abi.rst
@@ -17,7 +17,7 @@ Some ABI changes may be too significant to reasonably maintain multiple
versions of. In those events ABI's may be updated without backward
compatibility provided. The requirements for doing so are:
-#. At least 3 acknoweldgements of the need on the dpdk.org
+#. At least 3 acknowledgments of the need on the dpdk.org
#. A full deprecation cycle must be made to offer downstream consumers sufficient warning of the change. E.g. if dpdk 2.0 is under development when the change is proposed, a deprecation notice must be added to this file, and released with dpdk 2.0. Then the change may be incorporated for dpdk 2.1
#. The LIBABIVER variable in the makefile(s) where the ABI changes are incorporated must be incremented in parallel with the ABI changes themselves
@@ -25,7 +25,7 @@ Note that the above process for ABI deprecation should not be undertaken
lightly. ABI stability is extremely important for downstream consumers of the
DPDK, especially when distributed in shared object form. Every effort should be
made to preserve ABI whenever possible. For instance, reorganizing public
-structure field for astetic or readability purposes should be avoided as it will
+structure field for aesthetic or readability purposes should be avoided as it will
cause ABI breakage. Only significant (e.g. performance) reasons should be seen
as cause to alter ABI.
diff --git a/doc/guides/rel_notes/faq.rst b/doc/guides/rel_notes/faq.rst
index 14b1167..d87230a 100644
--- a/doc/guides/rel_notes/faq.rst
+++ b/doc/guides/rel_notes/faq.rst
@@ -201,7 +201,7 @@ What is the purpose of setting iommu=pt?
----------------------------------------
DPDK uses a 1:1 mapping and does not support IOMMU. IOMMU allows for simpler VM physical address translation.
The second role of IOMMU is to allow protection from unwanted memory access by an unsafe device that has DMA privileges.
-Unfortunately, the protection comes with an extremely high perfomance cost for high speed NICs.
+Unfortunately, the protection comes with an extremely high performance cost for high speed NICs.
iommu=pt disables IOMMU support for the hypervisor.
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index a94b6aa..7b62085 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -432,7 +432,7 @@ Some hardware off-load functions are not supported by the VF Driver
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| Implication | Any configuration for these items in the VF register will be ignored. The behavior |
-| | is dependant on the current PF setting. |
+| | is dependent on the current PF setting. |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| Resolution/ Workaround | For the PF (Physical Function) status on which the VF driver depends, there is an |
@@ -683,8 +683,8 @@ Binding PCI devices to igb_uio fails on Linux* kernel 3.9 when more than one dev
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-GCC might generate Intel® AVX instructions forprocessors without Intel® AVX support
------------------------------------------------------------------------------------
+GCC might generate Intel® AVX instructions for processors without Intel® AVX support
+------------------------------------------------------------------------------------
+--------------------------------+--------------------------------------------------------------------------------------+
| Title | Gcc might generate Intel® AVX instructions for processors without Intel® AVX support |
@@ -749,11 +749,11 @@ Ethertype filter could receive other packets (non-assigned) in Niantic
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-Cannot set link speed on Intel® 40G ethernet controller
+Cannot set link speed on Intel® 40G Ethernet controller
-------------------------------------------------------
+--------------------------------+--------------------------------------------------------------------------------------+
-| Title | Cannot set link speed on Intel® 40G ethernet controller |
+| Title | Cannot set link speed on Intel® 40G Ethernet controller |
| | |
+================================+======================================================================================+
| Reference # | IXA00386379 |
@@ -764,7 +764,7 @@ Cannot set link speed on Intel® 40G ethernet controller
| | It cannot set the link to specific speed. |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-| Implication | The link speed cannot be changed forcedly, though it can be configured by |
+| Implication | The link speed cannot be changed forcibly, though it can be configured by |
| | application. |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
@@ -778,11 +778,11 @@ Cannot set link speed on Intel® 40G ethernet controller
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-Stopping the port does not down the link on Intel® 40G ethernet controller
+Stopping the port does not down the link on Intel® 40G Ethernet controller
--------------------------------------------------------------------------
+--------------------------------+--------------------------------------------------------------------------------------+
-| Title | Stopping the port does not down the link on Intel® 40G ethernet controller |
+| Title | Stopping the port does not down the link on Intel® 40G Ethernet controller |
| | |
+================================+======================================================================================+
| Reference # | IXA00386380 |
diff --git a/doc/guides/rel_notes/resolved_issues.rst b/doc/guides/rel_notes/resolved_issues.rst
index 5fb973f..8d6bbfa 100644
--- a/doc/guides/rel_notes/resolved_issues.rst
+++ b/doc/guides/rel_notes/resolved_issues.rst
@@ -84,7 +84,7 @@ Vhost-xen cannot detect Domain U application exit on Xen version 4.0.1
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| Description | When using DPDK applications on Xen 4.0.1, e.g. TestPMD Sample Application, |
-| | on killing the application (e.g. killall testmd) vhost-switch cannot detect |
+| | on killing the application (e.g. killall testpmd) vhost-switch cannot detect |
| | the domain U exited and does not free the Virtio device. |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
@@ -211,11 +211,11 @@ KNI does not provide Ethtool support for all NICs supported by the Poll-Mode Dri
| Title | KNI does not provide ethtool support for all NICs supported by the Poll Mode Drivers |
| | |
+=================================+=======================================================================================+
-| Refererence # | IXA00383835 |
+| Reference # | IXA00383835 |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-| Description | To support ethtool functionality using the KNI, the KNI libray includes seperate |
-| | driver code based off the Linux kernel drivers, because this driver code is seperate |
+| Description | To support ethtool functionality using the KNI, the KNI library includes separate |
+| | driver code based off the Linux kernel drivers, because this driver code is separate |
| | from the poll-mode drivers, the set of supported NICs for these two components may |
| | differ. |
| | |
@@ -247,7 +247,7 @@ Linux IPv4 forwarding is not stable with vhost-switch on high packet rate
| Title | Linux IPv4 forwarding is not stable with vhost-switch on high packet rate. |
| | |
+=================================+=======================================================================================+
-| Refererence # | IXA00384430 |
+| Reference # | IXA00384430 |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| Description | Linux IPv4 forwarding is not stable in Guest when Tx traffic is high from traffic |
@@ -261,7 +261,7 @@ Linux IPv4 forwarding is not stable with vhost-switch on high packet rate
| Resolution/Workaround | N/A |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-| AffectedEnvironment/Platform | All |
+| Affected Environment/Platform | All |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| Driver/Module | Sample application |
@@ -431,7 +431,7 @@ Initialization failure with Intel® Ethernet Controller X540-T2
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| Description | This device causes a failure during initialization when the software tries to read |
-| | the part number from the device EEPROM. |
+| | the part number from the device EPROM. |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| Implication | Device cannot be used. |
@@ -998,7 +998,7 @@ No traffic through bridge when using exception_path sample application
| | not forwarded by the bridge. |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-| Implication | The sample application does not work as described in its sample application quide. |
+| Implication | The sample application does not work as described in its sample application guide. |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| Resolution/Workaround | If you cannot get packets though the bridge, it might be because IP packet filtering |
@@ -1105,8 +1105,8 @@ When running multi-process applications, “rte_malloc” functions cannot be us
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-Configuring maximum packet length for IGB with VLAN enabled may not take intoaccount the length of VLAN tag
------------------------------------------------------------------------------------------------------------
+Configuring maximum packet length for IGB with VLAN enabled may not take into account the length of VLAN tag
+------------------------------------------------------------------------------------------------------------
+---------------------------------+---------------------------------------------------------------------------------------+
| Title | Configuring maximum packet length for IGB with VLAN enabled may not take into account |
@@ -1177,7 +1177,7 @@ EAL can silently reserve less memory than requested
| Implication | The application fails to start. |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-| Resolution | EAL will detect if this condition occurs and will give anappropriate error message |
+| Resolution | EAL will detect if this condition occurs and will give an appropriate error message |
| | describing steps to fix the problem. |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
@@ -1366,17 +1366,17 @@ Packet reception issues when virtualization is enabled
-Double VLAN does not work on Intel® 40GbE ethernet contoller
-------------------------------------------------------------
+Double VLAN does not work on Intel® 40GbE Ethernet controller
+-------------------------------------------------------------
+---------------------------------+---------------------------------------------------------------------------------------+
-| Title | Double VLAN does not work on Intel® 40GbE ethernet controller |
+| Title | Double VLAN does not work on Intel® 40GbE Ethernet controller |
| | |
+=================================+=======================================================================================+
| Reference # | IXA00369908 |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-| Description | On Intel® 40 GbE ethernet controller double VLAN does not work. |
+| Description | On Intel® 40 GbE Ethernet controller double VLAN does not work. |
| | This was confirmed as a Firmware issue which will be fixed in later versions of |
| | firmware. |
+---------------------------------+---------------------------------------------------------------------------------------+
diff --git a/doc/guides/rel_notes/supported_features.rst b/doc/guides/rel_notes/supported_features.rst
index c908877..1102b66 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -170,14 +170,14 @@ Supported Features
* Support for multiple instances of the Intel® DPDK
* Support for Intel® 82574L Gigabit Ethernet Controller - Intel® Gigabit CT Desktop Adapter
- (previously code named “Hartwell”)
+ (previously code named "Hartwell")
-* Support for Intel® Ethernet Controller I210 (previously code named “Springville”)
+* Support for Intel® Ethernet Controller I210 (previously code named "Springville")
* Early access support for the Quad-port Intel® Ethernet Server Adapter X520-4 and X520-DA2
- (code named “Spring Fountain”)
+ (code named "Spring Fountain")
-* Support for Intel® X710/XL710 40 Gigabit Ethernet Controller (code named “Fortville”)
+* Support for Intel® X710/XL710 40 Gigabit Ethernet Controller (code named "Fortville")
* Core components:
@@ -223,16 +223,16 @@ Supported Features
* IGB Poll Mode Driver - 1 GbE Controllers (librte_pmd_e1000)
- * Support for Intel® 82576 Gigabit Ethernet Controller (previously code named “Kawela”)
+ * Support for Intel® 82576 Gigabit Ethernet Controller (previously code named "Kawela")
- * Support for Intel® 82580 Gigabit Ethernet Controller (previously code named “Barton Hills”)
+ * Support for Intel® 82580 Gigabit Ethernet Controller (previously code named "Barton Hills")
- * Support for Intel® I350 Gigabit Ethernet Controller (previously code named “Powerville”)
+ * Support for Intel® I350 Gigabit Ethernet Controller (previously code named "Powerville")
* Support for Intel® 82574L Gigabit Ethernet Controller - Intel® Gigabit CT Desktop Adapter
- (previously code named “Hartwell”)
+ (previously code named "Hartwell")
- * Support for Intel® Ethernet Controller I210 (previously code named “Springville”)
+ * Support for Intel® Ethernet Controller I210 (previously code named "Springville")
* Support for L2 Ethertype filters, SYN filters, 2-tuple filters and Flex filters for 82580 and i350
@@ -240,11 +240,11 @@ Supported Features
* Poll Mode Driver - 10 GbE Controllers (librte_pmd_ixgbe)
- * Support for Intel® 82599 10 Gigabit Ethernet Controller (previously code named “Niantic”)
+ * Support for Intel® 82599 10 Gigabit Ethernet Controller (previously code named "Niantic")
- * Support for Intel® Ethernet Server Adapter X520-T2 (previously code named “Iron Pond”)
+ * Support for Intel® Ethernet Server Adapter X520-T2 (previously code named "Iron Pond")
- * Support for Intel® Ethernet Controller X540-T2 (previously code named “Twin Pond”)
+ * Support for Intel® Ethernet Controller X540-T2 (previously code named "Twin Pond")
* Support for Virtual Machine Device Queues (VMDq) and Data Center Bridging (DCB) to divide
incoming traffic into 128 RX queues. DCB is also supported for transmitting packets.
@@ -351,7 +351,7 @@ Supported Features
* Improvements to SR-IOV switch configurability on the Intel® 82599 Ethernet Controllers in
a virtualized environment.
-* An API for L2 Ethernet Address “whitelist” filtering
+* An API for L2 Ethernet Address "whitelist" filtering
* An API for resetting statistics counters
@@ -363,7 +363,7 @@ Supported Features
* Support for zero-copy Multicast
-* New APIs to allow the “blacklisting” of specific NIC ports.
+* New APIs to allow the "blacklisting" of specific NIC ports.
* Header files for common protocols (IP, SCTP, TCP, UDP)
diff --git a/doc/guides/rel_notes/updating_apps.rst b/doc/guides/rel_notes/updating_apps.rst
index 4dbf268..9467c4d 100644
--- a/doc/guides/rel_notes/updating_apps.rst
+++ b/doc/guides/rel_notes/updating_apps.rst
@@ -71,7 +71,7 @@ Intel® DPDK 1.2 to Intel® DPDK 1.3
Note the following difference between releases 1.2 and 1.3:
-* In release 1.3, the Intel® DPDK supports two different 1 GBe drivers: igb and em.
+* In release 1.3, the Intel® DPDK supports two different 1 GbE drivers: igb and em.
Both of them are located in the same library: lib_pmd_e1000.a.
Therefore, the name of the library to link with for the igb PMD has changed from librte_pmd_igb.a to librte_pmd_e1000.a.
@@ -109,7 +109,7 @@ Note the following difference between release 1.1 and release 1.2:
* The method used for managing mbufs on the NIC TX rings for the 10 GbE driver has been modified to improve performance.
As a result, different parameter values should be passed to the rte_eth_tx_queue_setup() function.
- The recommended default values are to have tx_thresh.tx_wt hresh, tx_free_thresh,
+ The recommended default values are to have tx_thresh.tx_wthresh, tx_free_thresh,
as well as the new parameter tx_rs_thresh (all in the struct rte_eth_txconf datatype) set to zero.
See the "Configuration of Transmit and Receive Queues" section in the *Intel® DPDK Programmer's Guide* for more details.
diff --git a/doc/guides/sample_app_ug/dist_app.rst b/doc/guides/sample_app_ug/dist_app.rst
index bcff0dd..56195bb 100644
--- a/doc/guides/sample_app_ug/dist_app.rst
+++ b/doc/guides/sample_app_ug/dist_app.rst
@@ -104,7 +104,7 @@ Explanation
-----------
The distributor application consists of three types of threads: a receive
-thread (lcore_rx()), a set of worker threads(locre_worker())
+thread (lcore_rx()), a set of worker threads(lcore_worker())
and a transmit thread(lcore_tx()). How these threads work together is shown
in Fig2 below. The main() function launches threads of these three types.
Each thread has a while loop which will be doing processing and which is
diff --git a/doc/guides/sample_app_ug/ip_frag.rst b/doc/guides/sample_app_ug/ip_frag.rst
index 815cb4a..0c18fff 100644
--- a/doc/guides/sample_app_ug/ip_frag.rst
+++ b/doc/guides/sample_app_ug/ip_frag.rst
@@ -40,7 +40,7 @@ Overview
The application demonstrates the use of zero-copy buffers for packet fragmentation.
The initialization and run-time paths are very similar to those of the L2 forwarding application
-(see Chapter 9 "L2 Forwarding Simple Application (in Real and Virtualised Environments)" for more information).
+(see Chapter 9 "L2 Forwarding Simple Application (in Real and Virtualized Environments)" for more information).
This guide highlights the differences between the two applications.
There are three key differences from the L2 Forwarding sample application:
diff --git a/doc/guides/sample_app_ug/ip_reassembly.rst b/doc/guides/sample_app_ug/ip_reassembly.rst
index 6c500c0..050802a 100644
--- a/doc/guides/sample_app_ug/ip_reassembly.rst
+++ b/doc/guides/sample_app_ug/ip_reassembly.rst
@@ -96,7 +96,7 @@ where:
* --flowttl=TTL[(s|ms)]: determines maximum Time To Live for fragmented packet.
If all fragments of the packet wouldn't appear within given time-out,
- then they are consirdered as invalid and will be dropped.
+ then they are considered as invalid and will be dropped.
Valid range is 1ms - 3600s. Default value: 1s.
To run the example in linuxapp environment with 2 lcores (2,4) over 2 ports(0,2) with 1 RX queue per lcore:
diff --git a/doc/guides/sample_app_ug/ipv4_multicast.rst b/doc/guides/sample_app_ug/ipv4_multicast.rst
index 2020c4b..5e27041 100644
--- a/doc/guides/sample_app_ug/ipv4_multicast.rst
+++ b/doc/guides/sample_app_ug/ipv4_multicast.rst
@@ -232,12 +232,12 @@ Thereafter, a destination Ethernet address is constructed:
.. code-block:: c
- /* construct destination ethernet address */
+ /* construct destination Ethernet address */
dst_eth_addr = ETHER_ADDR_FOR_IPV4_MCAST(dest_addr);
Since Ethernet addresses are also part of the multicast process, each outgoing packet carries the same destination Ethernet address.
-The destination Ethernet address is constructed from the lower 23 bits of the multicast group ORed
+The destination Ethernet address is constructed from the lower 23 bits of the multicast group OR-ed
with the Ethernet address 01:00:5e:00:00:00, as per RFC 1112:
.. code-block:: c
diff --git a/doc/guides/sample_app_ug/l2_forward_job_stats.rst b/doc/guides/sample_app_ug/l2_forward_job_stats.rst
index 54d25cb..10dfecb 100644
--- a/doc/guides/sample_app_ug/l2_forward_job_stats.rst
+++ b/doc/guides/sample_app_ug/l2_forward_job_stats.rst
@@ -459,15 +459,15 @@ In the l2fwd_main_loop() function three loops are placed.
rte_pause();
}
-First inifnite for loop is to minimize impact of stats reading. Lock is only locked/unlocked when asked.
+First infinite for loop is to minimize impact of stats reading. Lock is only locked/unlocked when asked.
Second inner while loop do the whole jobs management. When any job is ready, the use rte_timer_manage() is used to call the job handler.
In this place functions l2fwd_fwd_job() and l2fwd_flush_job() are called when needed.
Then rte_jobstats_context_finish() is called to mark loop end - no other jobs are ready to execute. By this time stats are ready to be read
and if stats_read_pending is set, loop breaks allowing stats to be read.
-Third do-while loop is the idle job (idle stats counter). Its only purpose is moniting if any job is ready or stats job read is pending
-for this lcore. Statistics from this part of code is considered as the headroom available fo additional processing.
+Third do-while loop is the idle job (idle stats counter). Its only purpose is monitoring if any job is ready or stats job read is pending
+for this lcore. Statistics from this part of code is considered as the headroom available for additional processing.
Receive, Process and Transmit Packets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -595,7 +595,7 @@ If the table is full, the whole packets table is transmitted using the l2fwd_sen
}
To ensure that no packets remain in the tables, the flush job exists. The l2fwd_flush_job()
-is called periodicaly to for each lcore draining TX queue of each port.
+is called periodically to for each lcore draining TX queue of each port.
This technique introduces some latency when there are not many packets to send,
however it improves performance:
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index 20e4be7..39c2ea5 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -341,7 +341,7 @@ to generate hints based on recent network load trends.
*/
rte_delay_us(lcore_idle_hint);
else
- /* long sleep force runing thread to suspend */
+ /* long sleep force ruining thread to suspend */
usleep(lcore_idle_hint);
stats[lcore_id].sleep_time += lcore_idle_hint;
diff --git a/doc/guides/sample_app_ug/load_balancer.rst b/doc/guides/sample_app_ug/load_balancer.rst
index 6237633..3b32bdc 100644
--- a/doc/guides/sample_app_ug/load_balancer.rst
+++ b/doc/guides/sample_app_ug/load_balancer.rst
@@ -220,7 +220,7 @@ The application has built-in performance enhancements for the NUMA case:
#. Memory for the NIC RX or TX rings is allocated on the same socket with the lcore handling the respective ring.
In the case where multiple CPU sockets are used in the system,
-it is recommended to enable at least one lcore to fulfil the I/O role for the NIC ports that
+it is recommended to enable at least one lcore to fulfill the I/O role for the NIC ports that
are directly attached to that CPU socket through the PCI Express* bus.
It is always recommended to handle the packet I/O with lcores from the same CPU socket as the NICs.
diff --git a/doc/guides/sample_app_ug/multi_process.rst b/doc/guides/sample_app_ug/multi_process.rst
index 7ca71ca..9ed450b 100644
--- a/doc/guides/sample_app_ug/multi_process.rst
+++ b/doc/guides/sample_app_ug/multi_process.rst
@@ -269,7 +269,7 @@ therefore will be accessible by the secondary process as it initializes.
for(i = 0; i < num_ports; i++){
if(proc_type == RTE_PROC_PRIMARY)
if (smp_port_init(ports[i], mp, (uint16_t)num_procs) < 0)
- rte_exit(EXIT_FAILURE, "Error initialising ports\n");
+ rte_exit(EXIT_FAILURE, "Error initializing ports\n");
}
In the secondary instance, rather than initializing the network ports, the port information exported by the primary process is used,
@@ -569,7 +569,7 @@ and the master needs to see the update and print them out.
So, it needs to allocate a heap buffer using rte_zmalloc.
In addition, if the -f option is specified,
an array is needed to store the allocated core ID for the floating process so that the master can return it
-after a slave has exited accidently.
+after a slave has exited accidentally.
.. code-block:: c
diff --git a/doc/guides/sample_app_ug/netmap_compatibility.rst b/doc/guides/sample_app_ug/netmap_compatibility.rst
index f333f25..d86b3e3 100644
--- a/doc/guides/sample_app_ug/netmap_compatibility.rst
+++ b/doc/guides/sample_app_ug/netmap_compatibility.rst
@@ -114,7 +114,7 @@ namely rte_netmap_init() and rte_netmap_init_port().
These two initialization functions take compat_netmap specific data structures as parameters:
struct rte_netmap_conf and struct rte_netmap_port_conf.
Those structures' fields are Netmap related and are self-explanatory for developers familiar with Netmap.
-They are definedin $RTE_SDK/examples/netmap_compat/ lib/compat_netmap.h.
+They are defined in $RTE_SDK/examples/netmap_compat/ lib/compat_netmap.h.
The bridge application is an example largely based on the bridge example shipped with the Netmap distribution.
It shows how a minimal Netmap application with minimal and straightforward source code changes can be run on top of the DPDK.
diff --git a/doc/guides/sample_app_ug/packet_ordering.rst b/doc/guides/sample_app_ug/packet_ordering.rst
index 481f1b7..ef85150 100644
--- a/doc/guides/sample_app_ug/packet_ordering.rst
+++ b/doc/guides/sample_app_ug/packet_ordering.rst
@@ -46,7 +46,7 @@ The application uses at least three CPU cores:
Currently it modifies the output port of the packet for configurations with
more than one port enabled.
-* TX Core (slave core) receives traffic from Woker cores through software queues,
+* TX Core (slave core) receives traffic from Worker cores through software queues,
inserts out-of-order packets into reorder buffer, extracts ordered packets
from the reorder buffer and sends them to the NIC ports for transmission.
@@ -94,7 +94,7 @@ The first CPU core in the core mask is the master core and would be assigned to
RX core, the last to TX core and the rest to Worker cores.
The PORTMASK parameter must contain either 1 or even enabled port numbers.
-When setting more than 1 port, traffic would be forwarderd in pairs.
+When setting more than 1 port, traffic would be forwarded in pairs.
For example, if we enable 4 ports, traffic from port 0 to 1 and from 1 to 0,
then the other pair from 2 to 3 and from 3 to 2, having [0,1] and [2,3] pairs.
diff --git a/doc/guides/sample_app_ug/quota_watermark.rst b/doc/guides/sample_app_ug/quota_watermark.rst
index e091ad9..4274223 100644
--- a/doc/guides/sample_app_ug/quota_watermark.rst
+++ b/doc/guides/sample_app_ug/quota_watermark.rst
@@ -209,7 +209,7 @@ Then, a call to init_dpdk(), defined in init.c, is made to initialize the poll m
rte_exit(EXIT_FAILURE, "rte_eal_pci_probe(): error %d\n", ret);
if (rte_eth_dev_count() < 2)
- rte_exit(EXIT_FAILURE, "Not enough ethernet port available\n");
+ rte_exit(EXIT_FAILURE, "Not enough Ethernet port available\n");
}
To fully understand this code, it is recommended to study the chapters that relate to the *Poll Mode Driver*
@@ -492,7 +492,7 @@ low_watermark from the rte_memzone previously created by qw.
qw_memzone = rte_memzone_lookup(QUOTA_WATERMARK_MEMZONE_NAME);
if (qw_memzone == NULL)
- rte_exit(EXIT_FAILURE, "Could't find memzone\n");
+ rte_exit(EXIT_FAILURE, "Couldn't find memzone\n");
quota = qw_memzone->addr;
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 0432942..46aa6d5 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -112,7 +112,7 @@ For hash tables, the following parameters can be selected:
The available options are 8, 16 and 32 bytes;
* **Table type (e.g. hash-spec-16-ext or hash-spec-16-lru).**
- The available options are ext (extendible bucket) or lru (least recently used).
+ The available options are ext (extendable bucket) or lru (least recently used).
.. _table_3:
@@ -152,7 +152,7 @@ For hash tables, the following parameters can be selected:
| | | | [destination IPv4 address, 4 bytes of 0] |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
-| 4 | hash-[spec]-8-ext | Extendible bucket hash table with 8-byte key size | Same as hash-[spec]-8-lru table entries, above. |
+| 4 | hash-[spec]-8-ext | Extendable bucket hash table with 8-byte key size | Same as hash-[spec]-8-lru table entries, above. |
| | | and 16 million entries. | |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
@@ -175,7 +175,7 @@ For hash tables, the following parameters can be selected:
| | | | [destination IPv4 address, 12 bytes of 0] |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
-| 6 | hash-[spec]-16-ext | Extendible bucket hash table with 16-byte key size | Same as hash-[spec]-16-lru table entries, above. |
+| 6 | hash-[spec]-16-ext | Extendable bucket hash table with 16-byte key size | Same as hash-[spec]-16-lru table entries, above. |
| | | and 16 million entries. | |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
@@ -198,7 +198,7 @@ For hash tables, the following parameters can be selected:
| | | | [destination IPv4 address, 28 bytes of 0] |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
-| 8 | hash-[spec]-32-ext | Extendible bucket hash table with 32-byte key size | Same as hash-[spec]-32-lru table entries, above. |
+| 8 | hash-[spec]-32-ext | Extendable bucket hash table with 32-byte key size | Same as hash-[spec]-32-lru table entries, above. |
| | | and 16 million entries. | |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
diff --git a/doc/guides/sample_app_ug/timer.rst b/doc/guides/sample_app_ug/timer.rst
index d7f17f5..ee0a732 100644
--- a/doc/guides/sample_app_ug/timer.rst
+++ b/doc/guides/sample_app_ug/timer.rst
@@ -114,7 +114,7 @@ The main loop is very simple in this example:
/*
* Call the timer handler on each core: as we don't
* need a very precise timer, so only call
- * rte_timer_manage() every ~10ms (at 2 Ghz). In a real
+ * rte_timer_manage() every ~10ms (at 2 GHz). In a real
* application, this will enhance performances as
* reading the HPET timer is not efficient.
*/
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df8cd8c..ca9390d 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -37,7 +37,7 @@ The vhost sample application demonstrates integration of the Data Plane Developm
with the Linux* KVM hypervisor by implementing the vhost-net offload API.
The sample application performs simple packet switching between virtual machines based on Media Access Control
(MAC) address or Virtual Local Area Network (VLAN) tag.
-The splitting of ethernet traffic from an external switch is performed in hardware by the Virtual Machine Device Queues
+The splitting of Ethernet traffic from an external switch is performed in hardware by the Virtual Machine Device Queues
(VMDQ) and Data Center Bridging (DCB) features of the Intel® 82599 10 Gigabit Ethernet Controller.
Background
@@ -90,7 +90,7 @@ Sample Code Overview
The DPDK vhost-net sample code demonstrates KVM (QEMU) offloading the servicing of a Virtual Machine's (VM's)
virtio-net devices to a DPDK-based application in place of the kernel's vhost-net module.
-The DPDK vhost-net sample code is based on vhost library. Vhost library is developed for user space ethernet switch to
+The DPDK vhost-net sample code is based on vhost library. Vhost library is developed for user space Ethernet switch to
easily integrate with vhost functionality.
The vhost library implements the following features:
@@ -110,7 +110,7 @@ socket messages. Most of the messages share the same handler routine.
.. note::
**Any vhost cuse specific requirement in the following sections will be emphasized**.
-Two impelmentations are turned on and off statically through configure file. Only one implementation could be turned on. They don't co-exist in current implementation.
+Two implementations are turned on and off statically through configure file. Only one implementation could be turned on. They don't co-exist in current implementation.
The vhost sample code application is a simple packet switching application with the following feature:
@@ -158,7 +158,7 @@ Installing Packages on the Host(vhost cuse required)
The vhost cuse code uses the following packages; fuse, fuse-devel, and kernel-modules-extra.
The vhost user code don't rely on those modules as eventfds are already installed into vhost process through
-unix domain socket.
+Unix domain socket.
#. Install Fuse Development Libraries and headers:
@@ -491,7 +491,7 @@ This option is disabled by default.
**RX descriptor number.**
The RX descriptor number option specify the Ethernet RX descriptor number,
-Linux legacy virtio-net has different behaviour in how to use the vring descriptor from DPDK based virtio-net PMD,
+Linux legacy virtio-net has different behavior in how to use the vring descriptor from DPDK based virtio-net PMD,
the former likely allocate half for virtio header, another half for frame buffer,
while the latter allocate all for frame buffer,
this lead to different number for available frame buffer in vring,
@@ -502,7 +502,7 @@ So it is valid only in zero copy mode is enabled. The value is 32 by default.
user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir /mnt/huge -- --zero-copy 1 --rx-desc-num [0, n]
-**TX descriptornumber.**
+**TX descriptor number.**
The TX descriptor number option specify the Ethernet TX descriptor number, it is valid only in zero copy mode is enabled.
The value is 64 by default.
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 2a923d8..dd6e1e8 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -139,7 +139,7 @@ Host Operating System
The Host OS must also have the *apci_cpufreq* module installed, in some cases
the *intel_pstate* driver may be the default Power Management environment.
To enable *acpi_cpufreq* and disable *intel_pstate*, add the following
-to the grub linux command line:
+to the grub Linux command line:
.. code-block:: console
@@ -220,7 +220,7 @@ on cores 0 & 1 on a system with 4 memory channels:
./build/vm_power_mgr -c 0x3 -n 4
-After successful initialisation the user is presented with VM Power Manager CLI:
+After successful initialization the user is presented with VM Power Manager CLI:
.. code-block:: console
@@ -343,7 +343,7 @@ for example to run on cores 0,1,2,3 on a system with 4 memory channels:
./build/guest_vm_power_mgr -c 0xf -n 4
-After successful initialisation the user is presented with VM Power Manager Guest CLI:
+After successful initialization the user is presented with VM Power Manager Guest CLI:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
index e5d34e1..9fc1fd5 100644
--- a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
+++ b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
@@ -142,7 +142,7 @@ a default structure is provided for VMDQ and DCB configuration to be filled in l
.. code-block:: c
- /* empty vmdq+dcb configuration structure. Filled in programatically */
+ /* empty vmdq+dcb configuration structure. Filled in programmatically */
static const struct rte_eth_conf vmdq_dcb_conf_default = {
.rxmode = {
@@ -228,7 +228,7 @@ so the pools parameter in the rte_eth_vmdq_dcb_conf structure is specified as a
Once the network port has been initialized using the correct VMDQ and DCB values,
the initialization of the port's RX and TX hardware rings is performed similarly to that
in the L2 Forwarding sample application.
-See Chapter 9, "L2 Forwarding Sample Aplication (in Real and Virtualized Environments)" for more information.
+See Chapter 9, "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information.
Statistics Display
~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/testpmd_app_ug/intro.rst b/doc/guides/testpmd_app_ug/intro.rst
index d9d17dc..ccf57ed 100644
--- a/doc/guides/testpmd_app_ug/intro.rst
+++ b/doc/guides/testpmd_app_ug/intro.rst
@@ -37,8 +37,8 @@ The testpmd application can be used to test the DPDK in a packet forwarding mode
and also to access NIC hardware features such as Flow Director.
It also serves as a example of how to build a more fully-featured application using the DPDK SDK.
-DocumentationRoadmap
---------------------
+Documentation Roadmap
+---------------------
The following is a list of DPDK documents in the suggested reading order:
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a08327b..761172e 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -510,7 +510,7 @@ tx_vlan set (vlan_id) (port_id)
tx_vlan set pvid
~~~~~~~~~~~~~~~~
-Set port based hardware insertion of VLAN ID in pacekts sent on a port:
+Set port based hardware insertion of VLAN ID in packets sent on a port:
tx_vlan set pvid (port_id) (vlan_id) (on|off)
@@ -1214,7 +1214,7 @@ For example, set a Link Bonding device (port 10) to use a balance policy of laye
set bonding mon_period
~~~~~~~~~~~~~~~~~~~~~~
-Set the link status monitoring polling period in milliseconds for a bonding devicie.
+Set the link status monitoring polling period in milliseconds for a bonding device.
This adds support for PMD slave devices which do not support link status interrupts.
When the mon_period is set to a value greater than 0 then all PMD's which do not support
--
1.8.1.4
More information about the dev
mailing list