Fixed several typos and spelling errors in guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
(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
-----------------------------------------------
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
* -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
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).
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
* 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.
.. 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::
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)
* 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:
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.
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::
~~~~~~~~~~~~~~~~~~~~~
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).
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.
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
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.
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
------------
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.
* *_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:
+ 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::
``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
: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>`
:ref:`Table 22. Configuration parameters common for all hash table types <pg_table_22>`
-:ref:`Table 23. Configuration parameters specific to extend
ible bucket hash table <pg_table_23>`
+:ref:`Table 23. Configuration parameters specific to extend
able bucket hash table <pg_table_23>`
:ref:`Table 24. Configuration parameters specific to pre-computed key signature hash table <pg_table_24>`
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.
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.
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.
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.
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.
===============
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
-----------------------------------------------
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.
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.
.. 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. 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
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
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
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::
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::
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::
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:
* 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) {
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:
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).
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 |
| | | | | |
+---+-------------------------+------------------------------+---------------------------+-------------------------------+
| 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. |
| | | | 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. |
| | | | | |
+---+-------------------------+------------------------------+----------------------+------------------------------------+
| 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 | |
| | | | | |
+===+===============+====================+===============================================================================+
| 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. |
| | | | |
| | | | 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. |
#. 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.
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).
| | | | | 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 |
+=====+===========================+=========================================================================+
| 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. |
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
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.
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
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.
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
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),
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
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.
----------------------------------------
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.
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| 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 |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-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 |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-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 |
| | 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. |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
-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 |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| 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. |
| | |
+--------------------------------+--------------------------------------------------------------------------------------+
| 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. |
| | |
| 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 |
| Resolution/Workaround | N/A |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-| AffectedEnvironment/Platform | All |
+| Affected Environment/Platform | All |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| Driver/Module | Sample application |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
| 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. |
| | 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 |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-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 |
| 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. |
| | |
+---------------------------------+---------------------------------------------------------------------------------------+
-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. |
+---------------------------------+---------------------------------------------------------------------------------------+
* 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:
* 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
* 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.
* 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
* 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)
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.
* 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.
-----------
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
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:
* --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:
.. 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
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
}
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:
*/
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;
#. 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.
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,
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
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.
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.
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.
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*
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;
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:
| | | | [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. | |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
| | | | [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. | |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
| | | | [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. | |
| | | | |
+-------+------------------------+----------------------------------------------------------+-------------------------------------------------------+
/*
* 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.
*/
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
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:
.. 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:
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:
**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,
user@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.
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
./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
./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
.. 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 = {
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
~~~~~~~~~~~~~~~~~~
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:
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)
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
git.droids-corp.org / dpdk.git / commitdiff