doc/guides: clean repeated words
Shoot repeated words in all our guides. Cc: stable@dpdk.org Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Kevin Traynor <ktraynor@redhat.com>
This commit is contained in:
parent
a0eb7f2be8
commit
f43d3dbbd9
@ -631,10 +631,10 @@ In the DPDK environment, use the logging interface provided:
|
||||
|
||||
/* log in debug level */
|
||||
rte_log_set_global_level(RTE_LOG_DEBUG);
|
||||
RTE_LOG(DEBUG, my_logtype1, "this is is a debug level message\n");
|
||||
RTE_LOG(INFO, my_logtype1, "this is is a info level message\n");
|
||||
RTE_LOG(WARNING, my_logtype1, "this is is a warning level message\n");
|
||||
RTE_LOG(WARNING, my_logtype2, "this is is a debug level message (not displayed)\n");
|
||||
RTE_LOG(DEBUG, my_logtype1, "this is a debug level message\n");
|
||||
RTE_LOG(INFO, my_logtype1, "this is a info level message\n");
|
||||
RTE_LOG(WARNING, my_logtype1, "this is a warning level message\n");
|
||||
RTE_LOG(WARNING, my_logtype2, "this is a debug level message (not displayed)\n");
|
||||
|
||||
/* log in info level */
|
||||
rte_log_set_global_level(RTE_LOG_INFO);
|
||||
|
@ -28,7 +28,7 @@ Limitations
|
||||
* ZUC (EIA3) supported only if hash offset field is byte-aligned.
|
||||
* ZUC (EEA3) supported only if cipher length, cipher offset fields are byte-aligned.
|
||||
* ZUC PMD cannot be built as a shared library, due to limitations in
|
||||
in the underlying library.
|
||||
the underlying library.
|
||||
|
||||
|
||||
Installation
|
||||
|
@ -150,7 +150,7 @@ Configurations before running DPDK
|
||||
# Mount to the specific folder.
|
||||
mount -t hugetlbfs nodev /mnt/huge
|
||||
|
||||
2. Check the CPU layout using using the DPDK ``cpu_layout`` utility:
|
||||
2. Check the CPU layout using the DPDK ``cpu_layout`` utility:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
@ -119,7 +119,7 @@ Switch manager
|
||||
|
||||
The Intel FM10000 family of NICs integrate a hardware switch and multiple host
|
||||
interfaces. The FM10000 PMD driver only manages host interfaces. For the
|
||||
switch component another switch driver has to be loaded prior to to the
|
||||
switch component another switch driver has to be loaded prior to the
|
||||
FM10000 PMD driver. The switch driver can be acquired from Intel support.
|
||||
Only Testpoint is validated with DPDK, the latest version that has been
|
||||
validated with DPDK is 4.1.6.
|
||||
|
@ -1069,7 +1069,7 @@ The mbuf ``length`` is inclusive of CRC24A/B where present and is equal
|
||||
the code block size ``K``.
|
||||
|
||||
The first CB Virtual Circular Buffer (VCB) index is given by ``r`` but the
|
||||
the number of the remaining CB VCBs is calculated automatically by BBDEV
|
||||
number of the remaining CB VCBs is calculated automatically by BBDEV
|
||||
and passed down to the driver.
|
||||
|
||||
The number of remaining CB VCBs should not be confused with ``c``, the
|
||||
|
@ -498,7 +498,7 @@ to specify the details of the Crypto operation. For chaining of symmetric
|
||||
operations such as cipher encrypt and authentication generate, the next pointer
|
||||
allows transform to be chained together. Crypto devices which support chaining
|
||||
must publish the chaining of symmetric Crypto operations feature flag. Allocation of the
|
||||
xform structure is in the the application domain. To allow future API extensions in a
|
||||
xform structure is in the application domain. To allow future API extensions in a
|
||||
backwardly compatible manner, e.g. addition of a new parameter, the application should
|
||||
zero the full xform struct before populating it.
|
||||
|
||||
@ -893,7 +893,7 @@ Asymmetric Crypto transforms (``rte_crypto_asym_xform``) are the mechanism used
|
||||
to specify the details of the asymmetric Crypto operation. Next pointer within
|
||||
xform allows transform to be chained together. Also it is important to note that
|
||||
the order in which the transforms are passed indicates the order of the chaining. Allocation
|
||||
of the xform structure is in the the application domain. To allow future API extensions in a
|
||||
of the xform structure is in the application domain. To allow future API extensions in a
|
||||
backwardly compatible manner, e.g. addition of a new parameter, the application should
|
||||
zero the full xform struct before populating it.
|
||||
|
||||
|
@ -249,7 +249,7 @@ manual memory management.
|
||||
|
||||
+ Using heap API's for externally allocated memory
|
||||
|
||||
Using using a set of malloc heap API's is the recommended way to use externally
|
||||
Using a set of malloc heap API's is the recommended way to use externally
|
||||
allocated memory in DPDK. In this way, support for externally allocated memory
|
||||
is implemented through overloading the socket ID - externally allocated heaps
|
||||
will have socket ID's that would be considered invalid under normal
|
||||
|
@ -206,7 +206,7 @@ To segment an outgoing packet, an application must:
|
||||
2. Set the appropriate ol_flags in the mbuf.
|
||||
|
||||
- The GSO library use the value of an mbuf's ``ol_flags`` attribute to
|
||||
to determine how a packet should be segmented. It is the application's
|
||||
determine how a packet should be segmented. It is the application's
|
||||
responsibility to ensure that these flags are set.
|
||||
|
||||
- For example, in order to segment TCP/IPv4 packets, the application should
|
||||
|
@ -254,7 +254,7 @@ to create a separate thread or secondary process to periodically call
|
||||
|
||||
The KNI interfaces can be deleted by a DPDK application with
|
||||
``rte_kni_release()``. All KNI interfaces not explicitly deleted will be
|
||||
deleted when the the ``/dev/kni`` device is closed, either explicitly with
|
||||
deleted when the ``/dev/kni`` device is closed, either explicitly with
|
||||
``rte_kni_close()`` or when the DPDK application is closed.
|
||||
|
||||
DPDK mbuf Flow
|
||||
|
@ -154,7 +154,7 @@ To define classification for the IPv6 2-tuple: <protocol, IPv6 source address> o
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
struct struct rte_ipv6_hdr {
|
||||
struct rte_ipv6_hdr {
|
||||
uint32_t vtc_flow; /* IP version, traffic class & flow label. */
|
||||
uint16_t payload_len; /* IP packet length - includes sizeof(ip_header). */
|
||||
uint8_t proto; /* Protocol, next header. */
|
||||
@ -167,7 +167,7 @@ The following array of field definitions can be used:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
struct struct rte_acl_field_def ipv6_2tuple_defs[5] = {
|
||||
struct rte_acl_field_def ipv6_2tuple_defs[5] = {
|
||||
{
|
||||
.type = RTE_ACL_FIELD_TYPE_BITMASK,
|
||||
.size = sizeof (uint8_t),
|
||||
|
@ -1650,7 +1650,7 @@ Counters can be retrieved and reset through ``rte_flow_query()``, see
|
||||
The shared flag indicates whether the counter is unique to the flow rule the
|
||||
action is specified with, or whether it is a shared counter.
|
||||
|
||||
For a count action with the shared flag set, then then a global device
|
||||
For a count action with the shared flag set, then a global device
|
||||
namespace is assumed for the counter id, so that any matched flow rules using
|
||||
a count action with the same counter id on the same port will contribute to
|
||||
that counter.
|
||||
|
@ -51,7 +51,7 @@ however all security protocol related headers are still attached to the
|
||||
packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
|
||||
ESP/AH headers will remain in the packet but the received packet
|
||||
contains the decrypted data where the encrypted data was when the packet
|
||||
arrived. The driver Rx path check the descriptors and and based on the
|
||||
arrived. The driver Rx path check the descriptors and based on the
|
||||
crypto status sets additional flags in the rte_mbuf.ol_flags field.
|
||||
|
||||
.. note::
|
||||
@ -65,7 +65,7 @@ Egress Data path - The software prepares the egress packet by adding
|
||||
relevant security protocol headers. Only the data will not be
|
||||
encrypted by the software. The driver will accordingly configure the
|
||||
tx descriptors. The hardware device will encrypt the data before sending the
|
||||
the packet out.
|
||||
packet out.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -475,7 +475,7 @@ API Changes
|
||||
* **Added mbuf flags PKT_RX_VLAN and PKT_RX_QINQ.**
|
||||
|
||||
Two ``mbuf`` flags have been added to indicate that the VLAN
|
||||
identifier has been saved in in the ``mbuf`` structure. For instance:
|
||||
identifier has been saved in the ``mbuf`` structure. For instance:
|
||||
|
||||
- If VLAN is not stripped and TCI is saved: ``PKT_RX_VLAN``
|
||||
- If VLAN is stripped and TCI is saved: ``PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED``
|
||||
|
@ -210,7 +210,7 @@ New Features
|
||||
A set of northbound APIs have been defined which encompass a generic set of
|
||||
operations by allowing applications to interact with device using opaque
|
||||
structures/buffers. Also, southbound APIs provide a means of integrating devices
|
||||
either as as part of a physical bus (PCI, FSLMC etc) or through ``vdev``.
|
||||
either as part of a physical bus (PCI, FSLMC etc) or through ``vdev``.
|
||||
|
||||
See the :doc:`../prog_guide/rawdev` programmer's guide for more details.
|
||||
|
||||
|
@ -265,11 +265,11 @@ ABI Changes
|
||||
* mbuf: The format of the sched field of ``rte_mbuf`` has been changed
|
||||
to include the following fields: ``queue ID``, ``traffic class``, ``color``.
|
||||
|
||||
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
|
||||
* cryptodev: as shown in the 18.11 deprecation notice, the structure
|
||||
``rte_cryptodev_qp_conf`` has added two parameters for symmetric session
|
||||
mempool and symmetric session private data mempool.
|
||||
|
||||
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
|
||||
* cryptodev: as shown in the 18.11 deprecation notice, the structure
|
||||
``rte_cryptodev_sym_session`` has been updated to contain more information
|
||||
to ensure safely accessing the session and session private data.
|
||||
|
||||
|
@ -97,7 +97,7 @@ New Features
|
||||
* **Added ethdev API to set supported packet types**
|
||||
|
||||
* Added new API ``rte_eth_dev_set_ptypes`` that allows an application to
|
||||
inform PMD about about reduced range of packet types to handle.
|
||||
inform PMD about reduced range of packet types to handle.
|
||||
* This scheme will allow PMDs to avoid lookup to internal ptype table on Rx
|
||||
and thereby improve Rx performance if application wishes do so.
|
||||
|
||||
|
@ -40,7 +40,7 @@ The application is console-driven using the cmdline DPDK interface:
|
||||
EthApp>
|
||||
|
||||
From this interface the available commands and descriptions of what
|
||||
they do as as follows:
|
||||
they do as follows:
|
||||
|
||||
* ``drvinfo``: Print driver info
|
||||
* ``eeprom``: Dump EEPROM to file
|
||||
|
@ -158,7 +158,7 @@ Where:
|
||||
If packet is not reassembled within this time, received fragments
|
||||
will be discarded. Fragment lifetime should be decreased when
|
||||
there is a high fragmented traffic loss in high bandwidth networks.
|
||||
Should be lower for for low number of reassembly buckets.
|
||||
Should be lower for low number of reassembly buckets.
|
||||
Valid values: from 1 ns to 10 s. Default value: 10000000 (10 s).
|
||||
|
||||
* ``--reassemble NUM``: max number of entries in reassemble fragment table.
|
||||
|
@ -82,7 +82,7 @@ The application is console-driven using the cmdline DPDK interface:
|
||||
ntb>
|
||||
|
||||
From this interface the available commands and descriptions of what
|
||||
they do as as follows:
|
||||
they do as follows:
|
||||
|
||||
* ``send [filepath]``: Send file to the peer host. Need to be in
|
||||
file-trans forwarding mode first.
|
||||
|
@ -280,7 +280,7 @@ functionality into different threads, and the pairs of RX and TX threads are
|
||||
interconnected via software rings.
|
||||
|
||||
On initialization an L-thread scheduler is started on every EAL thread. On all
|
||||
but the master EAL thread only a a dummy L-thread is initially started.
|
||||
but the master EAL thread only a dummy L-thread is initially started.
|
||||
The L-thread started on the master EAL thread then spawns other L-threads on
|
||||
different L-thread schedulers according the command line parameters.
|
||||
|
||||
|
@ -33,7 +33,7 @@ If you type a partial command and hit ``<TAB>`` you get a list of the available
|
||||
|
||||
.. note::
|
||||
|
||||
Some examples in this document are too long to fit on one line are are shown wrapped at `"\\"` for display purposes::
|
||||
Some examples in this document are too long to fit on one line are shown wrapped at `"\\"` for display purposes::
|
||||
|
||||
testpmd> set flow_ctrl rx (on|off) tx (on|off) (high_water) (low_water) \
|
||||
(pause_time) (send_xon) (port_id)
|
||||
@ -2760,7 +2760,7 @@ Traffic Management
|
||||
------------------
|
||||
|
||||
The following section shows functions for configuring traffic management on
|
||||
on the ethernet device through the use of generic TM API.
|
||||
the ethernet device through the use of generic TM API.
|
||||
|
||||
show port traffic management capability
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -63,7 +63,7 @@ ring. For invalid or no ring name, whole list is dump.
|
||||
**--show-mempool[=name]**
|
||||
The show-mempool parameter display current allocation of all mempool
|
||||
debug information. Specifying the name allows to display details for specific
|
||||
specific mempool. For invalid or no mempool name, whole list is dump.
|
||||
mempool. For invalid or no mempool name, whole list is dump.
|
||||
|
||||
**--iter-mempool=name**
|
||||
The iter-mempool parameter iterates and displays mempool elements specified
|
||||
|
Loading…
x
Reference in New Issue
Block a user