diff options
Diffstat (limited to 'doc/guides/sample_app_ug')
| -rw-r--r-- | doc/guides/sample_app_ug/bbdev_app.rst | 4 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/intro.rst | 2 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/ip_pipeline.rst | 4 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/ipsec_secgw.rst | 4 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/performance_thread.rst | 4 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/qos_metering.rst | 2 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/test_pipeline.rst | 2 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/vhost.rst | 4 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/vhost_scsi.rst | 2 | ||||
| -rw-r--r-- | doc/guides/sample_app_ug/vm_power_management.rst | 15 |
11 files changed, 23 insertions, 22 deletions
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst index 653f972f..6ade9c6e 100644 --- a/doc/guides/sample_app_ug/bbdev_app.rst +++ b/doc/guides/sample_app_ug/bbdev_app.rst @@ -68,7 +68,7 @@ The application accepts a number of command line options: where: -* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2) +* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2) * ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4) * ``p ETH_PORT_ID``: ethernet port ID (default = 0) * ``b BBDEV_ID``: BBDev ID (default = 0) @@ -87,7 +87,7 @@ issue the command: $ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \ --file-prefix=bbdev -- -e 0x10 -d 0x20 -where, NIC0PCIADDR is the PCI addresse of the Rx port +where, NIC0PCIADDR is the PCI address of the Rx port This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the device gets linked to a corresponding ethernet port as whitelisted by diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst index 0ec02907..dc7972aa 100644 --- a/doc/guides/sample_app_ug/eventdev_pipeline.rst +++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst @@ -49,7 +49,7 @@ these settings is shown below: ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D The application has some sanity checking built-in, so if there is a function -(eg; the RX core) which doesn't have a cpu core mask assigned, the application +(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application will print an error message: .. code-block:: console diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 159bcf73..90704194 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -106,7 +106,7 @@ examples are highlighted below. (packet arrival) and TX (packet transmission) by adding callbacks to the RX and TX packet processing functions. -* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security +* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security Gateway application is minimal example of something closer to a real world example. This is also a good example of an application using the DPDK Cryptodev framework. diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst index 447a544d..4da0fcf8 100644 --- a/doc/guides/sample_app_ug/ip_pipeline.rst +++ b/doc/guides/sample_app_ug/ip_pipeline.rst @@ -113,7 +113,7 @@ Application stages Initialization ~~~~~~~~~~~~~~ -During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures +During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures (i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message is displayed and the application is terminated. @@ -185,7 +185,7 @@ Examples +-----------------------+----------------------+----------------+------------------------------------+ | IP routing | LPM (IPv4) | Forward | 1. Mempool Create | | | | | 2. Link create | - | | * Key = IP dest addr | | 3. Pipeline creat | + | | * Key = IP dest addr | | 3. Pipeline create | | | * Offset = 286 | | 4. Pipeline port in/out | | | * Table size = 4K | | 5. Pipeline table | | | | | 6. Pipeline port in table | diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst index 4869a011..5f7d3973 100644 --- a/doc/guides/sample_app_ug/ipsec_secgw.rst +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst @@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*. Thus, traffic received on an Unprotected or Protected port is consider Inbound or Outbound respectively. -The application also supports complete IPSec protocol offload to hardware -(Look aside crypto accelarator or using ethernet device). It also support +The application also supports complete IPsec protocol offload to hardware +(Look aside crypto accelerator or using ethernet device). It also support inline ipsec processing by the supported ethernet device during transmission. These modes can be selected during the SA creation configuration. diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst index fbd30a5e..96f0fc6f 100644 --- a/doc/guides/sample_app_ug/performance_thread.rst +++ b/doc/guides/sample_app_ug/performance_thread.rst @@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in the L-thread struct. For legacy and backward compatibility reasons two alternative methods are also -offered, the first is modelled directly on the pthread get/set specific APIs, -the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby +offered, the first is modeled directly on the pthread get/set specific APIs, +the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby ``PER_LTHREAD`` macros are introduced, in both cases the storage is local to the L-thread. diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst index 2e8e0175..d75f7da5 100644 --- a/doc/guides/sample_app_ug/qos_metering.rst +++ b/doc/guides/sample_app_ug/qos_metering.rst @@ -151,5 +151,5 @@ In this particular case: * For the rest of the cases, the color is changed to red. .. note:: - * In color blind mode, first row GREEN colour is only valid. + * In color blind mode, first row GREEN color is only valid. * To drop the packet, policer_table action has to be set to DROP. diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst index a9370c80..af9665b2 100644 --- a/doc/guides/sample_app_ug/test_pipeline.rst +++ b/doc/guides/sample_app_ug/test_pipeline.rst @@ -32,7 +32,7 @@ Compiling the Application ------------------------- To compile the sample application see :doc:`compiling` -The application is located in the ``$RTE_SDK/test/test-pipline`` directory. +The application is located in the ``$RTE_SDK/test/test-pipeline`` directory. Running the Application diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index df4d6f9a..a71ada65 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file. The vm2vm parameter sets the mode of packet switching between guests in the host. -- 0 disables vm2vm, impling that VM's packets will always go to the NIC port. +- 0 disables vm2vm, implying that VM's packets will always go to the NIC port. - 1 means a normal mac lookup packet routing. - 2 means hardware mode packet forwarding between guests, it allows packets go to the NIC port, hardware L2 switch will determine which guest the @@ -148,7 +148,7 @@ default value is 15. **--dequeue-zero-copy** Dequeue zero copy will be enabled when this option is given. it is worth to -note that if NIC is binded to driver with iommu enabled, dequeue zero copy +note that if NIC is bound to driver with iommu enabled, dequeue zero copy cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu dma mapping for guest memory. diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst index 7ab7d0d5..6b9bf62e 100644 --- a/doc/guides/sample_app_ug/vhost_scsi.rst +++ b/doc/guides/sample_app_ug/vhost_scsi.rst @@ -63,7 +63,7 @@ Vhost_scsi Common Issues * vhost_scsi can not start with block size 512 Bytes: - Currently DPDK vhost library was designed for NET device(althrough the APIs + Currently DPDK vhost library was designed for NET device(although the APIs are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced Disk Device) will enumerate all block device and do some IOs to those block devices with 512 Bytes sector size. DPDK vhost library can not process such diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst index 5be9f24d..a7b7a2c7 100644 --- a/doc/guides/sample_app_ug/vm_power_management.rst +++ b/doc/guides/sample_app_ug/vm_power_management.rst @@ -339,7 +339,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs. When this parameter is used, the list of cores specified will monitor the ratio between branch hits and branch misses. A tightly polling PMD thread will have a - very low branch ratio, so the core frequency will be scaled down to the minimim + very low branch ratio, so the core frequency will be scaled down to the minimum allowed value. When packets are received, the code path will alter, causing the branch ratio to increase. When the ratio goes above the ratio threshold, the core frequency will be scaled up to the maximum allowed value. @@ -379,7 +379,7 @@ the file. The fifo is at /tmp/powermonitor/fifo -The jason string can be a policy or instruction, and takes the following +The JSON string can be a policy or instruction, and takes the following format: .. code-block:: javascript @@ -592,7 +592,7 @@ Profile destroy example: .. code-block:: javascript - {"profile": { + {"policy": { "name": "ubuntu", "command": "destroy", }} @@ -601,8 +601,9 @@ Power command example: .. code-block:: javascript - {"command": { + {"instruction": { "name": "ubuntu", + "command": "power", "unit": "SCALE_MAX", "resource_id": 10 }} @@ -729,7 +730,7 @@ policy down to the host application. These parameters are as follows: A comma-separated list of cores in the VM that the user wants the host application to monitor. The list of cores in any vm starts at zero, and these are mapped to the physical cores by the host application once the policy is passed down. - Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a + Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a combination of both '1,3,5-7' .. code-block:: console @@ -737,7 +738,7 @@ policy down to the host application. These parameters are as follows: --busy-hours {list of busy hours} A comma-separated list of hours within which to set the core frequency to maximum. - Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a + Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a combination of both '1,3,5-7'. Valid hours are 0 to 23. .. code-block:: console @@ -745,7 +746,7 @@ policy down to the host application. These parameters are as follows: --quiet-hours {list of quiet hours} A comma-separated list of hours within which to set the core frequency to minimum. - Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a + Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a combination of both '1,3,5-7'. Valid hours are 0 to 23. .. code-block:: console |