net/memif: optimize with one-way barrier
[dpdk.git] / doc / guides / prog_guide / qos_framework.rst
index c4e390c..a7527b2 100644 (file)
@@ -1,32 +1,5 @@
-..  BSD LICENSE
-    Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-    All rights reserved.
-
-    Redistribution and use in source and binary forms, with or without
-    modification, are permitted provided that the following conditions
-    are met:
-
-    * Redistributions of source code must retain the above copyright
-    notice, this list of conditions and the following disclaimer.
-    * Redistributions in binary form must reproduce the above copyright
-    notice, this list of conditions and the following disclaimer in
-    the documentation and/or other materials provided with the
-    distribution.
-    * Neither the name of Intel Corporation nor the names of its
-    contributors may be used to endorse or promote products derived
-    from this software without specific prior written permission.
-
-    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-    "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-    LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-    A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-    OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-    LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-    DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-    THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright(c) 2010-2014 Intel Corporation.
 
 Quality of Service (QoS) Framework
 ==================================
 
 Quality of Service (QoS) Framework
 ==================================
@@ -147,7 +120,7 @@ these packets are later on removed and handed over to the NIC TX with the packet
 
 The hierarchical scheduler is optimized for a large number of packet queues.
 When only a small number of queues are needed, message passing queues should be used instead of this block.
 
 The hierarchical scheduler is optimized for a large number of packet queues.
 When only a small number of queues are needed, message passing queues should be used instead of this block.
-See Section 26.2.5 "Worst Case Scenarios for Performance" for a more detailed discussion.
+See `Worst Case Scenarios for Performance`_ for a more detailed discussion.
 
 Scheduling Hierarchy
 ~~~~~~~~~~~~~~~~~~~~
 
 Scheduling Hierarchy
 ~~~~~~~~~~~~~~~~~~~~
@@ -612,7 +585,7 @@ The token bucket generic parameters and operations are presented in :numref:`tab
 
 .. _table_qos_6:
 
 
 .. _table_qos_6:
 
-.. table:: Token Bucket Generic Operations
+.. table:: Token Bucket Generic Parameters
 
    +---+------------------------+--------------------+---------------------------------------------------------+
    | # | Token Bucket Parameter | Unit               | Description                                             |
 
    +---+------------------------+--------------------+---------------------------------------------------------+
    | # | Token Bucket Parameter | Unit               | Description                                             |
@@ -627,7 +600,7 @@ The token bucket generic parameters and operations are presented in :numref:`tab
 
 .. _table_qos_7:
 
 
 .. _table_qos_7:
 
-.. table:: Token Bucket Generic Parameters
+.. table:: Token Bucket Generic Operations
 
    +---+------------------------+------------------------------------------------------------------------------+
    | # | Token Bucket Operation | Description                                                                  |
 
    +---+------------------------+------------------------------------------------------------------------------+
    | # | Token Bucket Operation | Description                                                                  |
@@ -712,7 +685,7 @@ where, r = port line rate (in bytes per second).
    |   |                         |     of the grinders), update the credits for the pipe and its subport.      |
    |   |                         |                                                                             |
    |   |                         | The current implementation is using option 3.  According to Section         |
    |   |                         |     of the grinders), update the credits for the pipe and its subport.      |
    |   |                         |                                                                             |
    |   |                         | The current implementation is using option 3.  According to Section         |
-   |   |                         | 26.2.4.4 "Dequeue State Machine", the pipe and subport credits are          |
+   |   |                         | `Dequeue State Machine`_, the pipe and subport credits are                  |
    |   |                         | updated every time a pipe is selected by the dequeue process before the     |
    |   |                         | pipe and subport credits are actually used.                                 |
    |   |                         |                                                                             |
    |   |                         | updated every time a pipe is selected by the dequeue process before the     |
    |   |                         | pipe and subport credits are actually used.                                 |
    |   |                         |                                                                             |
@@ -783,7 +756,7 @@ as described in :numref:`table_qos_10` and :numref:`table_qos_11`.
    | 1 | tc_time               | Bytes | Time of the next update (upper limit refill) for the 4 TCs of the     |
    |   |                       |       | current subport / pipe.                                               |
    |   |                       |       |                                                                       |
    | 1 | tc_time               | Bytes | Time of the next update (upper limit refill) for the 4 TCs of the     |
    |   |                       |       | current subport / pipe.                                               |
    |   |                       |       |                                                                       |
-   |   |                       |       | See  Section 26.2.4.5.1, "Internal Time Reference" for the            |
+   |   |                       |       | See  Section `Internal Time Reference`_ for the                       |
    |   |                       |       | explanation of why the time is maintained in byte units.              |
    |   |                       |       |                                                                       |
    +---+-----------------------+-------+-----------------------------------------------------------------------+
    |   |                       |       | explanation of why the time is maintained in byte units.              |
    |   |                       |       |                                                                       |
    +---+-----------------------+-------+-----------------------------------------------------------------------+
@@ -1334,7 +1307,7 @@ Where:
 
 The time reference is in units of bytes,
 where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium
 
 The time reference is in units of bytes,
 where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium
-(see Section 26.2.4.5.1 "Internal Time Reference").
+(see Section `Internal Time Reference`_).
 The parameter s is defined in the dropper module as a constant with the value: s=2^22.
 This corresponds to the time required by every leaf node in a hierarchy with 64K leaf nodes
 to transmit one 64-byte packet onto the wire and represents the worst case scenario.
 The parameter s is defined in the dropper module as a constant with the value: s=2^22.
 This corresponds to the time required by every leaf node in a hierarchy with 64K leaf nodes
 to transmit one 64-byte packet onto the wire and represents the worst case scenario.
@@ -1538,7 +1511,7 @@ To enable it, use the DPDK configuration parameter:
 
 This parameter must be set to y.
 The parameter is found in the build configuration files in the DPDK/config directory,
 
 This parameter must be set to y.
 The parameter is found in the build configuration files in the DPDK/config directory,
-for example, DPDK/config/common_linuxapp.
+for example, DPDK/config/common_linux.
 RED configuration parameters are specified in the rte_red_params structure within the rte_sched_port_params structure
 that is passed to the scheduler on initialization.
 RED parameters are specified separately for four traffic classes and three packet colors (green, yellow and red)
 RED configuration parameters are specified in the rte_red_params structure within the rte_sched_port_params structure
 that is passed to the scheduler on initialization.
 RED parameters are specified separately for four traffic classes and three packet colors (green, yellow and red)