doc/guides/sample_app_ug/qos_scheduler.rst

   1 ..  SPDX-License-Identifier: BSD-3-Clause
   2     Copyright(c) 2010-2014 Intel Corporation.
   3
   4 QoS Scheduler Sample Application
   5 ================================
   6
   7 The QoS sample application demonstrates the use of the DPDK to provide QoS scheduling.
   8
   9 Overview
  10 --------
  11
  12 The architecture of the QoS scheduler application is shown in the following figure.
  13
  14 .. _figure_qos_sched_app_arch:
  15
  16 .. figure:: img/qos_sched_app_arch.*
  17
  18    QoS Scheduler Application Architecture
  19
  20
  21 There are two flavors of the runtime execution for this application,
  22 with two or three threads per each packet flow configuration being used.
  23 The RX thread reads packets from the RX port,
  24 classifies the packets based on the double VLAN (outer and inner) and
  25 the lower byte of the IP destination address and puts them into the ring queue.
  26 The worker thread dequeues the packets from the ring and calls the QoS scheduler enqueue/dequeue functions.
  27 If a separate TX core is used, these are sent to the TX ring.
  28 Otherwise, they are sent directly to the TX port.
  29 The TX thread, if present, reads from the TX ring and write the packets to the TX port.
  30
  31 Compiling the Application
  32 -------------------------
  33
  34 To compile the sample application see :doc:`compiling`.
  35
  36 The application is located in the ``qos_sched`` sub-directory.
  37
  38     .. note::
  39
  40         This application is intended as a linux only.
  41
  42 .. note::
  43
  44     To get statistics on the sample app using the command line interface as described in the next section,
  45     DPDK must be compiled defining *RTE_SCHED_COLLECT_STATS*, which can be done by changing the relevant
  46     entry in the ``config/rte_config.h`` file.
  47
  48 .. note::
  49
  50     Number of grinders is currently set to 8.
  51     This can be modified by specifying RTE_SCHED_PORT_N_GRINDERS=N
  52     in CFLAGS, where N is number of grinders.
  53
  54 Running the Application
  55 -----------------------
  56
  57 .. note::
  58
  59     In order to run the application, a total of at least 4
  60     G of huge pages must be set up for each of the used sockets (depending on the cores in use).
  61
  62 The application has a number of command line options:
  63
  64 .. code-block:: console
  65
  66     ./<build_dir>/examples/dpdk-qos_sched [EAL options] -- <APP PARAMS>
  67
  68 Mandatory application parameters include:
  69
  70 *   --pfc "RX PORT, TX PORT, RX LCORE, WT LCORE, TX CORE": Packet flow configuration.
  71     Multiple pfc entities can be configured in the command line,
  72     having 4 or 5 items (if TX core defined or not).
  73
  74 Optional application parameters include:
  75
  76 *   -i: It makes the application to start in the interactive mode.
  77     In this mode, the application shows a command line that can be used for obtaining statistics while
  78     scheduling is taking place (see interactive mode below for more information).
  79
  80 *   --mnc n: Main core index (the default value is 1).
  81
  82 *   --rsz "A, B, C": Ring sizes:
  83
  84 *   A = Size (in number of buffer descriptors) of each of the NIC RX rings read
  85     by the I/O RX lcores (the default value is 128).
  86
  87 *   B = Size (in number of elements) of each of the software rings used
  88     by the I/O RX lcores to send packets to worker lcores (the default value is 8192).
  89
  90 *   C = Size (in number of buffer descriptors) of each of the NIC TX rings written
  91     by worker lcores (the default value is 256)
  92
  93 *   --bsz "A, B, C, D": Burst sizes
  94
  95 *   A = I/O RX lcore read burst size from the NIC RX (the default value is 64)
  96
  97 *   B = I/O RX lcore write burst size to the output software rings,
  98     worker lcore read burst size from input software rings,QoS enqueue size (the default value is 64)
  99
 100 *   C = QoS dequeue size (the default value is 32)
 101
 102 *   D = Worker lcore write burst size to the NIC TX (the default value is 64)
 103
 104 *   --msz M: Mempool size (in number of mbufs) for each pfc (default 2097152)
 105
 106 *   --rth "A, B, C": The RX queue threshold parameters
 107
 108 *   A = RX prefetch threshold (the default value is 8)
 109
 110 *   B = RX host threshold (the default value is 8)
 111
 112 *   C = RX write-back threshold (the default value is 4)
 113
 114 *   --tth "A, B, C": TX queue threshold parameters
 115
 116 *   A = TX prefetch threshold (the default value is 36)
 117
 118 *   B = TX host threshold (the default value is 0)
 119
 120 *   C = TX write-back threshold (the default value is 0)
 121
 122 *   --cfg FILE: Profile configuration to load
 123
 124 Refer to *DPDK Getting Started Guide* for general information on running applications and
 125 the Environment Abstraction Layer (EAL) options.
 126
 127 The profile configuration file defines all the port/subport/pipe/traffic class/queue parameters
 128 needed for the QoS scheduler configuration.
 129
 130 The profile file has the following format:
 131
 132 .. literalinclude:: ../../../examples/qos_sched/profile.cfg
 133     :start-after: Data Plane Development Kit (DPDK) Programmer's Guide
 134
 135 Interactive mode
 136 ~~~~~~~~~~~~~~~~
 137
 138 These are the commands that are currently working under the command line interface:
 139
 140 *   Control Commands
 141
 142 *   --quit: Quits the application.
 143
 144 *   General Statistics
 145
 146     *   stats app: Shows a table with in-app calculated statistics.
 147
 148     *   stats port X subport Y: For a specific subport, it shows the number of packets that
 149         went through the scheduler properly and the number of packets that were dropped.
 150         The same information is shown in bytes.
 151         The information is displayed in a table separating it in different traffic classes.
 152
 153     *   stats port X subport Y pipe Z: For a specific pipe, it shows the number of packets that
 154         went through the scheduler properly and the number of packets that were dropped.
 155         The same information is shown in bytes.
 156         This information is displayed in a table separating it in individual queues.
 157
 158 *   Average queue size
 159
 160 All of these commands work the same way, averaging the number of packets throughout a specific subset of queues.
 161
 162 Two parameters can be configured for this prior to calling any of these commands:
 163
 164     *   qavg n X: n is the number of times that the calculation will take place.
 165         Bigger numbers provide higher accuracy. The default value is 10.
 166
 167     *   qavg period X: period is the number of microseconds that will be allowed between each calculation.
 168         The default value is 100.
 169
 170 The commands that can be used for measuring average queue size are:
 171
 172 *   qavg port X subport Y: Show average queue size per subport.
 173
 174 *   qavg port X subport Y tc Z: Show average queue size per subport for a specific traffic class.
 175
 176 *   qavg port X subport Y pipe Z: Show average queue size per pipe.
 177
 178 *   qavg port X subport Y pipe Z tc A: Show average queue size per pipe for a specific traffic class.
 179
 180 *   qavg port X subport Y pipe Z tc A q B: Show average queue size of a specific queue.
 181
 182 Example
 183 ~~~~~~~
 184
 185 The following is an example command with a single packet flow configuration:
 186
 187 .. code-block:: console
 188
 189     ./<build_dir>/examples/dpdk-qos_sched -l 1,5,7 -n 4 -- --pfc "3,2,5,7" --cfg ./profile.cfg
 190
 191 This example uses a single packet flow configuration which creates one RX thread on lcore 5 reading
 192 from port 3 and a worker thread on lcore 7 writing to port 2.
 193
 194 Another example with 2 packet flow configurations using different ports but sharing the same core for QoS scheduler is given below:
 195
 196 .. code-block:: console
 197
 198    ./<build_dir>/examples/dpdk-qos_sched -l 1,2,6,7 -n 4 -- --pfc "3,2,2,6,7" --pfc "1,0,2,6,7" --cfg ./profile.cfg
 199
 200 Note that independent cores for the packet flow configurations for each of the RX, WT and TX thread are also supported,
 201 providing flexibility to balance the work.
 202
 203 The EAL coremask/corelist is constrained to contain the default main core 1 and the RX, WT and TX cores only.
 204
 205 Explanation
 206 -----------
 207
 208 The Port/Subport/Pipe/Traffic Class/Queue are the hierarchical entities in a typical QoS application:
 209
 210 *   A subport represents a predefined group of users.
 211
 212 *   A pipe represents an individual user/subscriber.
 213
 214 *   A traffic class is the representation of a different traffic type with a specific loss rate,
 215     delay and jitter requirements; such as data voice, video or data transfers.
 216
 217 *   A queue hosts packets from one or multiple connections of the same type belonging to the same user.
 218
 219 The traffic flows that need to be configured are application dependent.
 220 This application classifies based on the QinQ double VLAN tags and the IP destination address as indicated in the following table.
 221
 222 .. _table_qos_scheduler_1:
 223
 224 .. table:: Entity Types
 225
 226    +----------------+-------------------------+--------------------------------------------------+----------------------------------+
 227    | **Level Name** | **Siblings per Parent** | **QoS Functional Description**                   | **Selected By**                  |
 228    |                |                         |                                                  |                                  |
 229    +================+=========================+==================================================+==================================+
 230    | Port           | -                       | Ethernet port                                    | Physical port                    |
 231    |                |                         |                                                  |                                  |
 232    +----------------+-------------------------+--------------------------------------------------+----------------------------------+
 233    | Subport        | Config (8)              | Traffic shaped (token bucket)                    | Outer VLAN tag                   |
 234    |                |                         |                                                  |                                  |
 235    +----------------+-------------------------+--------------------------------------------------+----------------------------------+
 236    | Pipe           | Config (4k)             | Traffic shaped (token bucket)                    | Inner VLAN tag                   |
 237    |                |                         |                                                  |                                  |
 238    +----------------+-------------------------+--------------------------------------------------+----------------------------------+
 239    | Traffic Class  | 13                      | TCs of the same pipe services in strict priority | Destination IP address (0.0.0.X) |
 240    |                |                         |                                                  |                                  |
 241    +----------------+-------------------------+--------------------------------------------------+----------------------------------+
 242    | Queue          | High Priority TC: 1,    | Queue of lowest priority traffic                 | Destination IP address (0.0.0.X) |
 243    |                | Lowest Priority TC: 4   | class (Best effort) serviced in WRR              |                                  |
 244    +----------------+-------------------------+--------------------------------------------------+----------------------------------+
 245
 246 Please refer to the "QoS Scheduler" chapter in the *DPDK Programmer's Guide* for more information about these parameters.