New upstream version 18.11.2

Change-Id: Ifc37f95b203b872a3f4b5b5b4755a3bb561aa515
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

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