qos_framework.rst revision 97f17497
1..  BSD LICENSE
2    Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
3    All rights reserved.
4
5    Redistribution and use in source and binary forms, with or without
6    modification, are permitted provided that the following conditions
7    are met:
8
9    * Redistributions of source code must retain the above copyright
10    notice, this list of conditions and the following disclaimer.
11    * Redistributions in binary form must reproduce the above copyright
12    notice, this list of conditions and the following disclaimer in
13    the documentation and/or other materials provided with the
14    distribution.
15    * Neither the name of Intel Corporation nor the names of its
16    contributors may be used to endorse or promote products derived
17    from this software without specific prior written permission.
18
19    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
20    "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
21    LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
22    A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
23    OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
24    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
25    LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
26    DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
27    THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
28    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
29    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
30
31Quality of Service (QoS) Framework
32==================================
33
34This chapter describes the DPDK Quality of Service (QoS) framework.
35
36Packet Pipeline with QoS Support
37--------------------------------
38
39An example of a complex packet processing pipeline with QoS support is shown in the following figure.
40
41.. _figure_pkt_proc_pipeline_qos:
42
43.. figure:: img/pkt_proc_pipeline_qos.*
44
45   Complex Packet Processing Pipeline with QoS Support
46
47
48This pipeline can be built using reusable DPDK software libraries.
49The main blocks implementing QoS in this pipeline are: the policer, the dropper and the scheduler.
50A functional description of each block is provided in the following table.
51
52.. _table_qos_1:
53
54.. table:: Packet Processing Pipeline Implementing QoS
55
56   +---+------------------------+--------------------------------------------------------------------------------+
57   | # | Block                  | Functional Description                                                         |
58   |   |                        |                                                                                |
59   +===+========================+================================================================================+
60   | 1 | Packet I/O RX & TX     | Packet reception/ transmission from/to multiple NIC ports. Poll mode drivers   |
61   |   |                        | (PMDs) for Intel 1 GbE/10 GbE NICs.                                            |
62   |   |                        |                                                                                |
63   +---+------------------------+--------------------------------------------------------------------------------+
64   | 2 | Packet parser          | Identify the protocol stack of the input packet. Check the integrity of the    |
65   |   |                        | packet headers.                                                                |
66   |   |                        |                                                                                |
67   +---+------------------------+--------------------------------------------------------------------------------+
68   | 3 | Flow classification    | Map the input packet to one of the known traffic flows. Exact match table      |
69   |   |                        | lookup using configurable hash function (jhash, CRC and so on) and bucket      |
70   |   |                        | logic to handle collisions.                                                    |
71   |   |                        |                                                                                |
72   +---+------------------------+--------------------------------------------------------------------------------+
73   | 4 | Policer                | Packet metering using srTCM (RFC 2697) or trTCM (RFC2698) algorithms.          |
74   |   |                        |                                                                                |
75   +---+------------------------+--------------------------------------------------------------------------------+
76   | 5 | Load Balancer          | Distribute the input packets to the application workers. Provide uniform load  |
77   |   |                        | to each worker. Preserve the affinity of traffic flows to workers and the      |
78   |   |                        | packet order within each flow.                                                 |
79   |   |                        |                                                                                |
80   +---+------------------------+--------------------------------------------------------------------------------+
81   | 6 | Worker threads         | Placeholders for the customer specific application workload (for example, IP   |
82   |   |                        | stack and so on).                                                              |
83   |   |                        |                                                                                |
84   +---+------------------------+--------------------------------------------------------------------------------+
85   | 7 | Dropper                | Congestion management using the Random Early Detection (RED) algorithm         |
86   |   |                        | (specified by the Sally Floyd - Van Jacobson paper) or Weighted RED (WRED).    |
87   |   |                        | Drop packets based on the current scheduler queue load level and packet        |
88   |   |                        | priority. When congestion is experienced, lower priority packets are dropped   |
89   |   |                        | first.                                                                         |
90   |   |                        |                                                                                |
91   +---+------------------------+--------------------------------------------------------------------------------+
92   | 8 | Hierarchical Scheduler | 5-level hierarchical scheduler (levels are: output port, subport, pipe,        |
93   |   |                        | traffic class and queue) with thousands (typically 64K) leaf nodes (queues).   |
94   |   |                        | Implements traffic shaping (for subport and pipe levels), strict priority      |
95   |   |                        | (for traffic class level) and Weighted Round Robin (WRR) (for queues within    |
96   |   |                        | each pipe traffic class).                                                      |
97   |   |                        |                                                                                |
98   +---+------------------------+--------------------------------------------------------------------------------+
99
100The infrastructure blocks used throughout the packet processing pipeline are listed in the following table.
101
102.. _table_qos_2:
103
104.. table:: Infrastructure Blocks Used by the Packet Processing Pipeline
105
106   +---+-----------------------+-----------------------------------------------------------------------+
107   | # | Block                 | Functional Description                                                |
108   |   |                       |                                                                       |
109   +===+=======================+=======================================================================+
110   | 1 | Buffer manager        | Support for global buffer pools and private per-thread buffer caches. |
111   |   |                       |                                                                       |
112   +---+-----------------------+-----------------------------------------------------------------------+
113   | 2 | Queue manager         | Support for message passing between pipeline blocks.                  |
114   |   |                       |                                                                       |
115   +---+-----------------------+-----------------------------------------------------------------------+
116   | 3 | Power saving          | Support for power saving during low activity periods.                 |
117   |   |                       |                                                                       |
118   +---+-----------------------+-----------------------------------------------------------------------+
119
120The mapping of pipeline blocks to CPU cores is configurable based on the performance level required by each specific application
121and the set of features enabled for each block.
122Some blocks might consume more than one CPU core (with each CPU core running a different instance of the same block on different input packets),
123while several other blocks could be mapped to the same CPU core.
124
125Hierarchical Scheduler
126----------------------
127
128The hierarchical scheduler block, when present, usually sits on the TX side just before the transmission stage.
129Its purpose is to prioritize the transmission of packets from different users and different traffic classes
130according to the policy specified by the Service Level Agreements (SLAs) of each network node.
131
132Overview
133~~~~~~~~
134
135The hierarchical scheduler block is similar to the traffic manager block used by network processors
136that typically implement per flow (or per group of flows) packet queuing and scheduling.
137It typically acts like a buffer that is able to temporarily store a large number of packets just before their transmission (enqueue operation);
138as the NIC TX is requesting more packets for transmission,
139these packets are later on removed and handed over to the NIC TX with the packet selection logic observing the predefined SLAs (dequeue operation).
140
141.. _figure_hier_sched_blk:
142
143.. figure:: img/hier_sched_blk.*
144
145   Hierarchical Scheduler Block Internal Diagram
146
147
148The hierarchical scheduler is optimized for a large number of packet queues.
149When only a small number of queues are needed, message passing queues should be used instead of this block.
150See `Worst Case Scenarios for Performance`_ for a more detailed discussion.
151
152Scheduling Hierarchy
153~~~~~~~~~~~~~~~~~~~~
154
155The scheduling hierarchy is shown in :numref:`figure_sched_hier_per_port`.
156The first level of the hierarchy is the Ethernet TX port 1/10/40 GbE,
157with subsequent hierarchy levels defined as subport, pipe, traffic class and queue.
158
159Typically, each subport represents a predefined group of users, while each pipe represents an individual user/subscriber.
160Each traffic class is the representation of a different traffic type with specific loss rate,
161delay and jitter requirements, such as voice, video or data transfers.
162Each queue hosts packets from one or multiple connections of the same type belonging to the same user.
163
164.. _figure_sched_hier_per_port:
165
166.. figure:: img/sched_hier_per_port.*
167
168   Scheduling Hierarchy per Port
169
170
171The functionality of each hierarchical level is detailed in the following table.
172
173.. _table_qos_3:
174
175.. table:: Port Scheduling Hierarchy
176
177   +---+--------------------+----------------------------+---------------------------------------------------------------+
178   | # | Level              | Siblings per Parent        | Functional Description                                        |
179   |   |                    |                            |                                                               |
180   +===+====================+============================+===============================================================+
181   | 1 | Port               | -                          | #.  Output Ethernet port 1/10/40 GbE.                         |
182   |   |                    |                            |                                                               |
183   |   |                    |                            | #.  Multiple ports are scheduled in round robin order with    |
184   |   |                    |                            |     all ports having equal priority.                          |
185   |   |                    |                            |                                                               |
186   +---+--------------------+----------------------------+---------------------------------------------------------------+
187   | 2 | Subport            | Configurable (default: 8)  | #.  Traffic shaping using token bucket algorithm (one token   |
188   |   |                    |                            |     bucket per subport).                                      |
189   |   |                    |                            |                                                               |
190   |   |                    |                            | #.  Upper limit enforced per Traffic Class (TC) at the        |
191   |   |                    |                            |     subport level.                                            |
192   |   |                    |                            |                                                               |
193   |   |                    |                            | #.  Lower priority TCs able to reuse subport bandwidth        |
194   |   |                    |                            |     currently unused by higher priority TCs.                  |
195   |   |                    |                            |                                                               |
196   +---+--------------------+----------------------------+---------------------------------------------------------------+
197   | 3 | Pipe               | Configurable (default: 4K) | #.  Traffic shaping using the token bucket algorithm (one     |
198   |   |                    |                            |     token bucket per pipe.                                    |
199   |   |                    |                            |                                                               |
200   +---+--------------------+----------------------------+---------------------------------------------------------------+
201   | 4 | Traffic Class (TC) | 4                          | #.  TCs of the same pipe handled in strict priority order.    |
202   |   |                    |                            |                                                               |
203   |   |                    |                            | #.  Upper limit enforced per TC at the pipe level.            |
204   |   |                    |                            |                                                               |
205   |   |                    |                            | #.  Lower priority TCs able to reuse pipe bandwidth currently |
206   |   |                    |                            |     unused by higher priority TCs.                            |
207   |   |                    |                            |                                                               |
208   |   |                    |                            | #.  When subport TC is oversubscribed (configuration time     |
209   |   |                    |                            |     event), pipe TC upper limit is capped to a dynamically    |
210   |   |                    |                            |     adjusted value that is shared by all the subport pipes.   |
211   |   |                    |                            |                                                               |
212   +---+--------------------+----------------------------+---------------------------------------------------------------+
213   | 5 | Queue              | 4                          | #.  Queues of the same TC are serviced using Weighted Round   |
214   |   |                    |                            |     Robin (WRR) according to predefined weights.              |
215   |   |                    |                            |                                                               |
216   +---+--------------------+----------------------------+---------------------------------------------------------------+
217
218Application Programming Interface (API)
219~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
220
221Port Scheduler Configuration API
222^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
223
224The rte_sched.h file contains configuration functions for port, subport and pipe.
225
226Port Scheduler Enqueue API
227^^^^^^^^^^^^^^^^^^^^^^^^^^
228
229The port scheduler enqueue API is very similar to the API of the DPDK PMD TX function.
230
231.. code-block:: c
232
233    int rte_sched_port_enqueue(struct rte_sched_port *port, struct rte_mbuf **pkts, uint32_t n_pkts);
234
235Port Scheduler Dequeue API
236^^^^^^^^^^^^^^^^^^^^^^^^^^
237
238The port scheduler dequeue API is very similar to the API of the DPDK PMD RX function.
239
240.. code-block:: c
241
242    int rte_sched_port_dequeue(struct rte_sched_port *port, struct rte_mbuf **pkts, uint32_t n_pkts);
243
244Usage Example
245^^^^^^^^^^^^^
246
247.. code-block:: c
248
249    /* File "application.c" */
250
251    #define N_PKTS_RX   64
252    #define N_PKTS_TX   48
253    #define NIC_RX_PORT 0
254    #define NIC_RX_QUEUE 0
255    #define NIC_TX_PORT 1
256    #define NIC_TX_QUEUE 0
257
258    struct rte_sched_port *port = NULL;
259    struct rte_mbuf *pkts_rx[N_PKTS_RX], *pkts_tx[N_PKTS_TX];
260    uint32_t n_pkts_rx, n_pkts_tx;
261
262    /* Initialization */
263
264    <initialization code>
265
266    /* Runtime */
267    while (1) {
268        /* Read packets from NIC RX queue */
269
270        n_pkts_rx = rte_eth_rx_burst(NIC_RX_PORT, NIC_RX_QUEUE, pkts_rx, N_PKTS_RX);
271
272        /* Hierarchical scheduler enqueue */
273
274        rte_sched_port_enqueue(port, pkts_rx, n_pkts_rx);
275
276        /* Hierarchical scheduler dequeue */
277
278        n_pkts_tx = rte_sched_port_dequeue(port, pkts_tx, N_PKTS_TX);
279
280        /* Write packets to NIC TX queue */
281
282        rte_eth_tx_burst(NIC_TX_PORT, NIC_TX_QUEUE, pkts_tx, n_pkts_tx);
283    }
284
285Implementation
286~~~~~~~~~~~~~~
287
288Internal Data Structures per Port
289^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
290
291A schematic of the internal data structures in shown in with details in.
292
293.. _figure_data_struct_per_port:
294
295.. figure:: img/data_struct_per_port.*
296
297    Internal Data Structures per Port
298
299
300.. _table_qos_4:
301
302.. table:: Scheduler Internal Data Structures per Port
303
304   +---+----------------------+-------------------------+---------------------+------------------------------+---------------------------------------------------+
305   | # | Data structure       | Size (bytes)            | # per port          | Access type                  | Description                                       |
306   |   |                      |                         |                     |                              |                                                   |
307   |   |                      |                         |                     +-------------+----------------+---------------------------------------------------+
308   |   |                      |                         |                     | Enq         | Deq            |                                                   |
309   |   |                      |                         |                     |             |                |                                                   |
310   +===+======================+=========================+=====================+=============+================+===================================================+
311   | 1 | Subport table entry  | 64                      | # subports per port | -           | Rd, Wr         | Persistent subport data (credits, etc).           |
312   |   |                      |                         |                     |             |                |                                                   |
313   +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
314   | 2 | Pipe table entry     | 64                      | # pipes per port    | -           | Rd, Wr         | Persistent data for pipe, its TCs and its queues  |
315   |   |                      |                         |                     |             |                | (credits, etc) that is updated during run-time.   |
316   |   |                      |                         |                     |             |                |                                                   |
317   |   |                      |                         |                     |             |                | The pipe configuration parameters do not change   |
318   |   |                      |                         |                     |             |                | during run-time. The same pipe configuration      |
319   |   |                      |                         |                     |             |                | parameters are shared by multiple pipes,          |
320   |   |                      |                         |                     |             |                | therefore they are not part of pipe table entry.  |
321   |   |                      |                         |                     |             |                |                                                   |
322   +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
323   | 3 | Queue table entry    | 4                       | #queues per port    | Rd, Wr      | Rd, Wr         | Persistent queue data (read and write pointers).  |
324   |   |                      |                         |                     |             |                | The queue size is the same per TC for all queues, |
325   |   |                      |                         |                     |             |                | allowing the queue base address to be computed    |
326   |   |                      |                         |                     |             |                | using a fast formula, so these two parameters are |
327   |   |                      |                         |                     |             |                | not part of queue table entry.                    |
328   |   |                      |                         |                     |             |                |                                                   |
329   |   |                      |                         |                     |             |                | The queue table entries for any given pipe are    |
330   |   |                      |                         |                     |             |                | stored in the same cache line.                    |
331   |   |                      |                         |                     |             |                |                                                   |
332   +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
333   | 4 | Queue storage area   | Config (default: 64 x8) | # queues per port   | Wr          | Rd             | Array of elements per queue; each element is 8    |
334   |   |                      |                         |                     |             |                | byte in size (mbuf pointer).                      |
335   |   |                      |                         |                     |             |                |                                                   |
336   +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
337   | 5 | Active queues bitmap | 1 bit per queue         | 1                   | Wr (Set)    | Rd, Wr (Clear) | The bitmap maintains one status bit per queue:    |
338   |   |                      |                         |                     |             |                | queue not active (queue is empty) or queue active |
339   |   |                      |                         |                     |             |                | (queue is not empty).                             |
340   |   |                      |                         |                     |             |                |                                                   |
341   |   |                      |                         |                     |             |                | Queue bit is set by the scheduler enqueue and     |
342   |   |                      |                         |                     |             |                | cleared by the scheduler dequeue when queue       |
343   |   |                      |                         |                     |             |                | becomes empty.                                    |
344   |   |                      |                         |                     |             |                |                                                   |
345   |   |                      |                         |                     |             |                | Bitmap scan operation returns the next non-empty  |
346   |   |                      |                         |                     |             |                | pipe and its status (16-bit mask of active queue  |
347   |   |                      |                         |                     |             |                | in the pipe).                                     |
348   |   |                      |                         |                     |             |                |                                                   |
349   +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
350   | 6 | Grinder              | ~128                    | Config (default: 8) | -           | Rd, Wr         | Short list of active pipes currently under        |
351   |   |                      |                         |                     |             |                | processing. The grinder contains temporary data   |
352   |   |                      |                         |                     |             |                | during pipe processing.                           |
353   |   |                      |                         |                     |             |                |                                                   |
354   |   |                      |                         |                     |             |                | Once the current pipe exhausts packets or         |
355   |   |                      |                         |                     |             |                | credits, it is replaced with another active pipe  |
356   |   |                      |                         |                     |             |                | from the bitmap.                                  |
357   |   |                      |                         |                     |             |                |                                                   |
358   +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
359
360Multicore Scaling Strategy
361^^^^^^^^^^^^^^^^^^^^^^^^^^
362
363The multicore scaling strategy is:
364
365#.  Running different physical ports on different threads. The enqueue and dequeue of the same port are run by the same thread.
366
367#.  Splitting the same physical port to different threads by running different sets of subports of the same physical port (virtual ports) on different threads.
368    Similarly, a subport can be split into multiple subports that are each run by a different thread.
369    The enqueue and dequeue of the same port are run by the same thread.
370    This is only required if, for performance reasons, it is not possible to handle a full port with a single core.
371
372Enqueue and Dequeue for the Same Output Port
373""""""""""""""""""""""""""""""""""""""""""""
374
375Running enqueue and dequeue operations for the same output port from different cores is likely to cause significant impact on scheduler's performance
376and it is therefore not recommended.
377
378The port enqueue and dequeue operations share access to the following data structures:
379
380#.  Packet descriptors
381
382#.  Queue table
383
384#.  Queue storage area
385
386#.  Bitmap of active queues
387
388The expected drop in performance is due to:
389
390#.  Need to make the queue and bitmap operations thread safe,
391    which requires either using locking primitives for access serialization (for example, spinlocks/ semaphores) or
392    using atomic primitives for lockless access (for example, Test and Set, Compare And Swap, an so on).
393    The impact is much higher in the former case.
394
395#.  Ping-pong of cache lines storing the shared data structures between the cache hierarchies of the two cores
396    (done transparently by the MESI protocol cache coherency CPU hardware).
397
398Therefore, the scheduler enqueue and dequeue operations have to be run from the same thread,
399which allows the queues and the bitmap operations to be non-thread safe and
400keeps the scheduler data structures internal to the same core.
401
402Performance Scaling
403"""""""""""""""""""
404
405Scaling up the number of NIC ports simply requires a proportional increase in the number of CPU cores to be used for traffic scheduling.
406
407Enqueue Pipeline
408^^^^^^^^^^^^^^^^
409
410The sequence of steps per packet:
411
412#.  *Access* the mbuf to read the data fields required to identify the destination queue for the packet.
413    These fields are: port, subport, traffic class and queue within traffic class, and are typically set by the classification stage.
414
415#.  *Access* the queue structure to identify the write location in the queue array.
416    If the queue is full, then the packet is discarded.
417
418#.  *Access* the queue array location to store the packet (i.e. write the mbuf pointer).
419
420It should be noted the strong data dependency between these steps, as steps 2 and 3 cannot start before the result from steps 1 and 2 becomes available,
421which prevents the processor out of order execution engine to provide any significant performance optimizations.
422
423Given the high rate of input packets and the large amount of queues,
424it is expected that the data structures accessed to enqueue the current packet are not present
425in the L1 or L2 data cache of the current core, thus the above 3 memory accesses would result (on average) in L1 and L2 data cache misses.
426A number of 3 L1/L2 cache misses per packet is not acceptable for performance reasons.
427
428The workaround is to prefetch the required data structures in advance. The prefetch operation has an execution latency during which
429the processor should not attempt to access the data structure currently under prefetch, so the processor should execute other work.
430The only other work available is to execute different stages of the enqueue sequence of operations on other input packets,
431thus resulting in a pipelined implementation for the enqueue operation.
432
433:numref:`figure_prefetch_pipeline` illustrates a pipelined implementation for the enqueue operation with 4 pipeline stages and each stage executing 2 different input packets.
434No input packet can be part of more than one pipeline stage at a given time.
435
436.. _figure_prefetch_pipeline:
437
438.. figure:: img/prefetch_pipeline.*
439
440    Prefetch Pipeline for the Hierarchical Scheduler Enqueue Operation
441
442
443The congestion management scheme implemented by the enqueue pipeline described above is very basic:
444packets are enqueued until a specific queue becomes full,
445then all the packets destined to the same queue are dropped until packets are consumed (by the dequeue operation).
446This can be improved by enabling RED/WRED as part of the enqueue pipeline which looks at the queue occupancy and
447packet priority in order to yield the enqueue/drop decision for a specific packet
448(as opposed to enqueuing all packets / dropping all packets indiscriminately).
449
450Dequeue State Machine
451^^^^^^^^^^^^^^^^^^^^^
452
453The sequence of steps to schedule the next packet from the current pipe is:
454
455#.  Identify the next active pipe using the bitmap scan operation, *prefetch* pipe.
456
457#.  *Read* pipe data structure. Update the credits for the current pipe and its subport.
458    Identify the first active traffic class within the current pipe, select the next queue using WRR,
459    *prefetch* queue pointers for all the 16 queues of the current pipe.
460
461#.  *Read* next element from the current WRR queue and *prefetch* its packet descriptor.
462
463#.  *Read* the packet length from the packet descriptor (mbuf structure).
464    Based on the packet length and the available credits (of current pipe, pipe traffic class, subport and subport traffic class),
465    take the go/no go scheduling decision for the current packet.
466
467To avoid the cache misses, the above data structures (pipe, queue, queue array, mbufs) are prefetched in advance of being accessed.
468The strategy of hiding the latency of the prefetch operations is to switch from the current pipe (in grinder A) to another pipe
469(in grinder B) immediately after a prefetch is issued for the current pipe.
470This gives enough time to the prefetch operation to complete before the execution switches back to this pipe (in grinder A).
471
472The dequeue pipe state machine exploits the data presence into the processor cache,
473therefore it tries to send as many packets from the same pipe TC and pipe as possible (up to the available packets and credits) before
474moving to the next active TC from the same pipe (if any) or to another active pipe.
475
476.. _figure_pipe_prefetch_sm:
477
478.. figure:: img/pipe_prefetch_sm.*
479
480   Pipe Prefetch State Machine for the Hierarchical Scheduler Dequeue
481   Operation
482
483
484Timing and Synchronization
485^^^^^^^^^^^^^^^^^^^^^^^^^^
486
487The output port is modeled as a conveyor belt of byte slots that need to be filled by the scheduler with data for transmission.
488For 10 GbE, there are 1.25 billion byte slots that need to be filled by the port scheduler every second.
489If the scheduler is not fast enough to fill the slots, provided that enough packets and credits exist,
490then some slots will be left unused and bandwidth will be wasted.
491
492In principle, the hierarchical scheduler dequeue operation should be triggered by NIC TX.
493Usually, once the occupancy of the NIC TX input queue drops below a predefined threshold,
494the port scheduler is woken up (interrupt based or polling based,
495by continuously monitoring the queue occupancy) to push more packets into the queue.
496
497Internal Time Reference
498"""""""""""""""""""""""
499
500The scheduler needs to keep track of time advancement for the credit logic,
501which requires credit updates based on time (for example, subport and pipe traffic shaping, traffic class upper limit enforcement, and so on).
502
503Every time the scheduler decides to send a packet out to the NIC TX for transmission, the scheduler will increment its internal time reference accordingly.
504Therefore, it is convenient to keep the internal time reference in units of bytes,
505where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium.
506This way, as a packet is scheduled for transmission, the time is incremented with (n + h),
507where n is the packet length in bytes and h is the number of framing overhead bytes per packet.
508
509Internal Time Reference Re-synchronization
510""""""""""""""""""""""""""""""""""""""""""
511
512The scheduler needs to align its internal time reference to the pace of the port conveyor belt.
513The reason is to make sure that the scheduler does not feed the NIC TX with more bytes than the line rate of the physical medium in order to prevent packet drop
514(by the scheduler, due to the NIC TX input queue being full, or later on, internally by the NIC TX).
515
516The scheduler reads the current time on every dequeue invocation.
517The CPU time stamp can be obtained by reading either the Time Stamp Counter (TSC) register or the High Precision Event Timer (HPET) register.
518The current CPU time stamp is converted from number of CPU clocks to number of bytes:
519*time_bytes = time_cycles / cycles_per_byte, where cycles_per_byte*
520is the amount of CPU cycles that is equivalent to the transmission time for one byte on the wire
521(e.g. for a CPU frequency of 2 GHz and a 10GbE port,*cycles_per_byte = 1.6*).
522
523The scheduler maintains an internal time reference of the NIC time.
524Whenever a packet is scheduled, the NIC time is incremented with the packet length (including framing overhead).
525On every dequeue invocation, the scheduler checks its internal reference of the NIC time against the current time:
526
527#. If NIC time is in the future (NIC time >= current time), no adjustment of NIC time is needed.
528   This means that scheduler is able to schedule NIC packets before the NIC actually needs those packets, so the NIC TX is well supplied with packets;
529
530#. If NIC time is in the past (NIC time < current time), then NIC time should be adjusted by setting it to the current time.
531   This means that the scheduler is not able to keep up with the speed of the NIC byte conveyor belt,
532   so NIC bandwidth is wasted due to poor packet supply to the NIC TX.
533
534Scheduler Accuracy and Granularity
535""""""""""""""""""""""""""""""""""
536
537The scheduler round trip delay (SRTD) is the time (number of CPU cycles) between two consecutive examinations of the same pipe by the scheduler.
538
539To keep up with the output port (that is, avoid bandwidth loss),
540the scheduler should be able to schedule n packets faster than the same n packets are transmitted by NIC TX.
541
542The scheduler needs to keep up with the rate of each individual pipe,
543as configured for the pipe token bucket, assuming that no port oversubscription is taking place.
544This means that the size of the pipe token bucket should be set high enough to prevent it from overflowing due to big SRTD,
545as this would result in credit loss (and therefore bandwidth loss) for the pipe.
546
547Credit Logic
548^^^^^^^^^^^^
549
550Scheduling Decision
551"""""""""""""""""""
552
553The scheduling decision to send next packet from (subport S, pipe P, traffic class TC, queue Q) is favorable (packet is sent)
554when all the conditions below are met:
555
556*   Pipe P of subport S is currently selected by one of the port grinders;
557
558*   Traffic class TC is the highest priority active traffic class of pipe P;
559
560*   Queue Q is the next queue selected by WRR within traffic class TC of pipe P;
561
562*   Subport S has enough credits to send the packet;
563
564*   Subport S has enough credits for traffic class TC to send the packet;
565
566*   Pipe P has enough credits to send the packet;
567
568*   Pipe P has enough credits for traffic class TC to send the packet.
569
570If all the above conditions are met,
571then the packet is selected for transmission and the necessary credits are subtracted from subport S,
572subport S traffic class TC, pipe P, pipe P traffic class TC.
573
574Framing Overhead
575""""""""""""""""
576
577As the greatest common divisor for all packet lengths is one byte, the unit of credit is selected as one byte.
578The number of credits required for the transmission of a packet of n bytes is equal to (n+h),
579where h is equal to the number of framing overhead bytes per packet.
580
581.. _table_qos_5:
582
583.. table:: Ethernet Frame Overhead Fields
584
585   +---+--------------------------------+----------------+---------------------------------------------------------------------------+
586   | # | Packet field                   | Length (bytes) | Comments                                                                  |
587   |   |                                |                |                                                                           |
588   +===+================================+================+===========================================================================+
589   | 1 | Preamble                       | 7              |                                                                           |
590   |   |                                |                |                                                                           |
591   +---+--------------------------------+----------------+---------------------------------------------------------------------------+
592   | 2 | Start of Frame Delimiter (SFD) | 1              |                                                                           |
593   |   |                                |                |                                                                           |
594   +---+--------------------------------+----------------+---------------------------------------------------------------------------+
595   | 3 | Frame Check Sequence (FCS)     | 4              | Considered overhead only if not included in the mbuf packet length field. |
596   |   |                                |                |                                                                           |
597   +---+--------------------------------+----------------+---------------------------------------------------------------------------+
598   | 4 | Inter Frame Gap (IFG)          | 12             |                                                                           |
599   |   |                                |                |                                                                           |
600   +---+--------------------------------+----------------+---------------------------------------------------------------------------+
601   | 5 | Total                          | 24             |                                                                           |
602   |   |                                |                |                                                                           |
603   +---+--------------------------------+----------------+---------------------------------------------------------------------------+
604
605Traffic Shaping
606"""""""""""""""
607
608The traffic shaping for subport and pipe is implemented using a token bucket per subport/per pipe.
609Each token bucket is implemented using one saturated counter that keeps track of the number of available credits.
610
611The token bucket generic parameters and operations are presented in :numref:`table_qos_6` and :numref:`table_qos_7`.
612
613.. _table_qos_6:
614
615.. table:: Token Bucket Generic Operations
616
617   +---+------------------------+--------------------+---------------------------------------------------------+
618   | # | Token Bucket Parameter | Unit               | Description                                             |
619   |   |                        |                    |                                                         |
620   +===+========================+====================+=========================================================+
621   | 1 | bucket_rate            | Credits per second | Rate of adding credits to the bucket.                   |
622   |   |                        |                    |                                                         |
623   +---+------------------------+--------------------+---------------------------------------------------------+
624   | 2 | bucket_size            | Credits            | Max number of credits that can be stored in the bucket. |
625   |   |                        |                    |                                                         |
626   +---+------------------------+--------------------+---------------------------------------------------------+
627
628.. _table_qos_7:
629
630.. table:: Token Bucket Generic Parameters
631
632   +---+------------------------+------------------------------------------------------------------------------+
633   | # | Token Bucket Operation | Description                                                                  |
634   |   |                        |                                                                              |
635   +===+========================+==============================================================================+
636   | 1 | Initialization         | Bucket set to a predefined value, e.g. zero or half of the bucket size.      |
637   |   |                        |                                                                              |
638   +---+------------------------+------------------------------------------------------------------------------+
639   | 2 | Credit update          | Credits are added to the bucket on top of existing ones, either periodically |
640   |   |                        | or on demand, based on the bucket_rate. Credits cannot exceed the upper      |
641   |   |                        | limit defined by the bucket_size, so any credits to be added to the bucket   |
642   |   |                        | while the bucket is full are dropped.                                        |
643   |   |                        |                                                                              |
644   +---+------------------------+------------------------------------------------------------------------------+
645   | 3 | Credit consumption     | As result of packet scheduling, the necessary number of credits is removed   |
646   |   |                        | from the bucket. The packet can only be sent if enough credits are in the    |
647   |   |                        | bucket to send the full packet (packet bytes and framing overhead for the    |
648   |   |                        | packet).                                                                     |
649   |   |                        |                                                                              |
650   +---+------------------------+------------------------------------------------------------------------------+
651
652To implement the token bucket generic operations described above,
653the current design uses the persistent data structure presented in :numref:`table_qos_8`,
654while the implementation of the token bucket operations is described in :numref:`table_qos_9`.
655
656.. _table_qos_8:
657
658.. table:: Token Bucket Persistent Data Structure
659
660   +---+------------------------+-------+----------------------------------------------------------------------+
661   | # | Token bucket field     | Unit  | Description                                                          |
662   |   |                        |       |                                                                      |
663   +===+========================+=======+======================================================================+
664   | 1 | tb_time                | Bytes | Time of the last credit update. Measured in bytes instead of seconds |
665   |   |                        |       | or CPU cycles for ease of credit consumption operation               |
666   |   |                        |       | (as the current time is also maintained in bytes).                   |
667   |   |                        |       |                                                                      |
668   |   |                        |       | See  Section 26.2.4.5.1 "Internal Time Reference" for an             |
669   |   |                        |       | explanation of why the time is maintained in byte units.             |
670   |   |                        |       |                                                                      |
671   +---+------------------------+-------+----------------------------------------------------------------------+
672   | 2 | tb_period              | Bytes | Time period that should elapse since the last credit update in order |
673   |   |                        |       | for the bucket to be awarded tb_credits_per_period worth or credits. |
674   |   |                        |       |                                                                      |
675   +---+------------------------+-------+----------------------------------------------------------------------+
676   | 3 | tb_credits_per_period  | Bytes | Credit allowance per tb_period.                                      |
677   |   |                        |       |                                                                      |
678   +---+------------------------+-------+----------------------------------------------------------------------+
679   | 4 | tb_size                | Bytes | Bucket size, i.e. upper limit for the tb_credits.                    |
680   |   |                        |       |                                                                      |
681   +---+------------------------+-------+----------------------------------------------------------------------+
682   | 5 | tb_credits             | Bytes | Number of credits currently in the bucket.                           |
683   |   |                        |       |                                                                      |
684   +---+------------------------+-------+----------------------------------------------------------------------+
685
686The bucket rate (in bytes per second) can be computed with the following formula:
687
688*bucket_rate = (tb_credits_per_period / tb_period) * r*
689
690where, r = port line rate (in bytes per second).
691
692.. _table_qos_9:
693
694.. table:: Token Bucket Operations
695
696   +---+-------------------------+-----------------------------------------------------------------------------+
697   | # | Token bucket operation  | Description                                                                 |
698   |   |                         |                                                                             |
699   +===+=========================+=============================================================================+
700   | 1 | Initialization          | *tb_credits = 0; or tb_credits = tb_size / 2;*                              |
701   |   |                         |                                                                             |
702   +---+-------------------------+-----------------------------------------------------------------------------+
703   | 2 | Credit update           | Credit update options:                                                      |
704   |   |                         |                                                                             |
705   |   |                         | *   Every time a packet is sent for a port, update the credits of all the   |
706   |   |                         |     the subports and pipes of that port. Not feasible.                      |
707   |   |                         |                                                                             |
708   |   |                         | *   Every time a packet is sent, update the credits for the pipe and        |
709   |   |                         |     subport. Very accurate, but not needed (a lot of calculations).         |
710   |   |                         |                                                                             |
711   |   |                         | *   Every time a pipe is selected (that is, picked by one                   |
712   |   |                         |     of the grinders), update the credits for the pipe and its subport.      |
713   |   |                         |                                                                             |
714   |   |                         | The current implementation is using option 3.  According to Section         |
715   |   |                         | `Dequeue State Machine`_, the pipe and subport credits are                  |
716   |   |                         | updated every time a pipe is selected by the dequeue process before the     |
717   |   |                         | pipe and subport credits are actually used.                                 |
718   |   |                         |                                                                             |
719   |   |                         | The implementation uses a tradeoff between accuracy and speed by updating   |
720   |   |                         | the bucket credits only when at least a full *tb_period*  has elapsed since |
721   |   |                         | the last update.                                                            |
722   |   |                         |                                                                             |
723   |   |                         | *   Full accuracy can be achieved by selecting the value for *tb_period*    |
724   |   |                         |     for which  *tb_credits_per_period = 1*.                                 |
725   |   |                         |                                                                             |
726   |   |                         | *   When full accuracy is not required, better performance is achieved by   |
727   |   |                         |     setting *tb_credits* to a larger value.                                 |
728   |   |                         |                                                                             |
729   |   |                         | Update operations:                                                          |
730   |   |                         |                                                                             |
731   |   |                         | *   n_periods = (time - tb_time) / tb_period;                               |
732   |   |                         |                                                                             |
733   |   |                         | *   tb_credits += n_periods * tb_credits_per_period;                        |
734   |   |                         |                                                                             |
735   |   |                         | *   tb_credits = min(tb_credits, tb_size);                                  |
736   |   |                         |                                                                             |
737   |   |                         | *   tb_time += n_periods * tb_period;                                       |
738   |   |                         |                                                                             |
739   +---+-------------------------+-----------------------------------------------------------------------------+
740   | 3 | Credit consumption      | As result of packet scheduling, the necessary number of credits is removed  |
741   |   |  (on packet scheduling) | from the bucket. The packet can only be sent if enough credits are in the   |
742   |   |                         | bucket to send the full packet (packet bytes and framing overhead for the   |
743   |   |                         | packet).                                                                    |
744   |   |                         |                                                                             |
745   |   |                         | Scheduling operations:                                                      |
746   |   |                         |                                                                             |
747   |   |                         | pkt_credits = pkt_len + frame_overhead;                                     |
748   |   |                         | if (tb_credits >= pkt_credits){tb_credits -= pkt_credits;}                  |
749   |   |                         |                                                                             |
750   +---+-------------------------+-----------------------------------------------------------------------------+
751
752Traffic Classes
753"""""""""""""""
754
755Implementation of Strict Priority Scheduling
756''''''''''''''''''''''''''''''''''''''''''''
757
758Strict priority scheduling of traffic classes within the same pipe is implemented by the pipe dequeue state machine,
759which selects the queues in ascending order.
760Therefore, queues 0..3 (associated with TC 0, highest priority TC) are handled before
761queues 4..7 (TC 1, lower priority than TC 0),
762which are handled before queues 8..11 (TC 2),
763which are handled before queues 12..15 (TC 3, lowest priority TC).
764
765Upper Limit Enforcement
766'''''''''''''''''''''''
767
768The traffic classes at the pipe and subport levels are not traffic shaped,
769so there is no token bucket maintained in this context.
770The upper limit for the traffic classes at the subport and
771pipe levels is enforced by periodically refilling the subport / pipe traffic class credit counter,
772out of which credits are consumed every time a packet is scheduled for that subport / pipe,
773as described in :numref:`table_qos_10` and :numref:`table_qos_11`.
774
775.. _table_qos_10:
776
777.. table:: Subport/Pipe Traffic Class Upper Limit Enforcement Persistent Data Structure
778
779   +---+-----------------------+-------+-----------------------------------------------------------------------+
780   | # | Subport or pipe field | Unit  | Description                                                           |
781   |   |                       |       |                                                                       |
782   +===+=======================+=======+=======================================================================+
783   | 1 | tc_time               | Bytes | Time of the next update (upper limit refill) for the 4 TCs of the     |
784   |   |                       |       | current subport / pipe.                                               |
785   |   |                       |       |                                                                       |
786   |   |                       |       | See  Section `Internal Time Reference`_ for the                       |
787   |   |                       |       | explanation of why the time is maintained in byte units.              |
788   |   |                       |       |                                                                       |
789   +---+-----------------------+-------+-----------------------------------------------------------------------+
790   | 2 | tc_period             | Bytes | Time between two consecutive updates for the 4 TCs of the current     |
791   |   |                       |       | subport / pipe. This is expected to be many times bigger than the     |
792   |   |                       |       | typical value of the token bucket tb_period.                          |
793   |   |                       |       |                                                                       |
794   +---+-----------------------+-------+-----------------------------------------------------------------------+
795   | 3 | tc_credits_per_period | Bytes | Upper limit for the number of credits allowed to be consumed by the   |
796   |   |                       |       | current TC during each enforcement period tc_period.                  |
797   |   |                       |       |                                                                       |
798   +---+-----------------------+-------+-----------------------------------------------------------------------+
799   | 4 | tc_credits            | Bytes | Current upper limit for the number of credits that can be consumed by |
800   |   |                       |       | the current traffic class for the remainder of the current            |
801   |   |                       |       | enforcement period.                                                   |
802   |   |                       |       |                                                                       |
803   +---+-----------------------+-------+-----------------------------------------------------------------------+
804
805.. _table_qos_11:
806
807.. table:: Subport/Pipe Traffic Class Upper Limit Enforcement Operations
808
809   +---+--------------------------+----------------------------------------------------------------------------+
810   | # | Traffic Class Operation  | Description                                                                |
811   |   |                          |                                                                            |
812   +===+==========================+============================================================================+
813   | 1 | Initialization           | tc_credits = tc_credits_per_period;                                        |
814   |   |                          |                                                                            |
815   |   |                          | tc_time = tc_period;                                                       |
816   |   |                          |                                                                            |
817   +---+--------------------------+----------------------------------------------------------------------------+
818   | 2 | Credit update            | Update operations:                                                         |
819   |   |                          |                                                                            |
820   |   |                          | if (time >= tc_time) {                                                     |
821   |   |                          |                                                                            |
822   |   |                          | tc_credits = tc_credits_per_period;                                        |
823   |   |                          |                                                                            |
824   |   |                          | tc_time = time + tc_period;                                                |
825   |   |                          |                                                                            |
826   |   |                          | }                                                                          |
827   |   |                          |                                                                            |
828   +---+--------------------------+----------------------------------------------------------------------------+
829   | 3 | Credit consumption       | As result of packet scheduling, the TC limit is decreased with the         |
830   |   | (on packet scheduling)   | necessary number of credits. The packet can only be sent if enough credits |
831   |   |                          | are currently available in the TC limit to send the full packet            |
832   |   |                          | (packet bytes and framing overhead for the packet).                        |
833   |   |                          |                                                                            |
834   |   |                          | Scheduling operations:                                                     |
835   |   |                          |                                                                            |
836   |   |                          | pkt_credits = pk_len + frame_overhead;                                     |
837   |   |                          |                                                                            |
838   |   |                          | if (tc_credits >= pkt_credits) {tc_credits -= pkt_credits;}                |
839   |   |                          |                                                                            |
840   +---+--------------------------+----------------------------------------------------------------------------+
841
842Weighted Round Robin (WRR)
843""""""""""""""""""""""""""
844
845The evolution of the WRR design solution from simple to complex is shown in :numref:`table_qos_12`.
846
847.. _table_qos_12:
848
849.. table:: Weighted Round Robin (WRR)
850
851   +---+------------+-----------------+-------------+----------------------------------------------------------+
852   | # | All Queues | Equal Weights   | All Packets | Strategy                                                 |
853   |   | Active?    | for All Queues? | Equal?      |                                                          |
854   +===+============+=================+=============+==========================================================+
855   | 1 | Yes        | Yes             | Yes         | **Byte level round robin**                               |
856   |   |            |                 |             |                                                          |
857   |   |            |                 |             | *Next queue*  queue #i, i =  *(i + 1) % n*               |
858   |   |            |                 |             |                                                          |
859   +---+------------+-----------------+-------------+----------------------------------------------------------+
860   | 2 | Yes        | Yes             | No          | **Packet level round robin**                             |
861   |   |            |                 |             |                                                          |
862   |   |            |                 |             | Consuming one byte from queue #i requires consuming      |
863   |   |            |                 |             | exactly one token for queue #i.                          |
864   |   |            |                 |             |                                                          |
865   |   |            |                 |             | T(i) = Accumulated number of tokens previously consumed  |
866   |   |            |                 |             | from queue #i. Every time a packet is consumed from      |
867   |   |            |                 |             | queue #i, T(i) is updated as: T(i) += *pkt_len*.         |
868   |   |            |                 |             |                                                          |
869   |   |            |                 |             | *Next queue* : queue with the smallest T.                |
870   |   |            |                 |             |                                                          |
871   |   |            |                 |             |                                                          |
872   +---+------------+-----------------+-------------+----------------------------------------------------------+
873   | 3 | Yes        | No              | No          | **Packet level weighted round robin**                    |
874   |   |            |                 |             |                                                          |
875   |   |            |                 |             | This case can be reduced to the previous case by         |
876   |   |            |                 |             | introducing a cost per byte that is different for each   |
877   |   |            |                 |             | queue. Queues with lower weights have a higher cost per  |
878   |   |            |                 |             | byte. This way, it is still meaningful to compare the    |
879   |   |            |                 |             | consumption amongst different queues in order to select  |
880   |   |            |                 |             | the next queue.                                          |
881   |   |            |                 |             |                                                          |
882   |   |            |                 |             | w(i) = Weight of queue #i                                |
883   |   |            |                 |             |                                                          |
884   |   |            |                 |             | t(i) = Tokens per byte for queue #i, defined as the      |
885   |   |            |                 |             | inverse weight of queue #i.                              |
886   |   |            |                 |             | For example, if w[0..3] = [1:2:4:8],                     |
887   |   |            |                 |             | then t[0..3] = [8:4:2:1]; if w[0..3] = [1:4:15:20],      |
888   |   |            |                 |             | then t[0..3] = [60:15:4:3].                              |
889   |   |            |                 |             | Consuming one byte from queue #i requires consuming t(i) |
890   |   |            |                 |             | tokens for queue #i.                                     |
891   |   |            |                 |             |                                                          |
892   |   |            |                 |             | T(i) = Accumulated number of tokens previously consumed  |
893   |   |            |                 |             | from queue #i. Every time a packet is consumed from      |
894   |   |            |                 |             | queue #i, T(i) is updated as:  *T(i) += pkt_len * t(i)*. |
895   |   |            |                 |             | *Next queue* : queue with the smallest T.                |
896   |   |            |                 |             |                                                          |
897   +---+------------+-----------------+-------------+----------------------------------------------------------+
898   | 4 | No         | No              | No          | **Packet level weighted round robin with variable queue  |
899   |   |            |                 |             | status**                                                 |
900   |   |            |                 |             |                                                          |
901   |   |            |                 |             | Reduce this case to the previous case by setting the     |
902   |   |            |                 |             | consumption of inactive queues to a high number, so that |
903   |   |            |                 |             | the inactive queues will never be selected by the        |
904   |   |            |                 |             | smallest T logic.                                        |
905   |   |            |                 |             |                                                          |
906   |   |            |                 |             | To prevent T from overflowing as result of successive    |
907   |   |            |                 |             | accumulations, T(i) is truncated after each packet       |
908   |   |            |                 |             | consumption for all queues.                              |
909   |   |            |                 |             | For example, T[0..3] = [1000, 1100, 1200, 1300]          |
910   |   |            |                 |             | is truncated to T[0..3] = [0, 100, 200, 300]             |
911   |   |            |                 |             | by subtracting the min T from T(i), i = 0..n.            |
912   |   |            |                 |             |                                                          |
913   |   |            |                 |             | This requires having at least one active queue in the    |
914   |   |            |                 |             | set of input queues, which is guaranteed by the dequeue  |
915   |   |            |                 |             | state machine never selecting an inactive traffic class. |
916   |   |            |                 |             |                                                          |
917   |   |            |                 |             | *mask(i) = Saturation mask for queue #i, defined as:*    |
918   |   |            |                 |             |                                                          |
919   |   |            |                 |             | mask(i) = (queue #i is active)? 0 : 0xFFFFFFFF;          |
920   |   |            |                 |             |                                                          |
921   |   |            |                 |             | w(i) = Weight of queue #i                                |
922   |   |            |                 |             |                                                          |
923   |   |            |                 |             | t(i) = Tokens per byte for queue #i, defined as the      |
924   |   |            |                 |             | inverse weight of queue #i.                              |
925   |   |            |                 |             |                                                          |
926   |   |            |                 |             | T(i) = Accumulated numbers of tokens previously consumed |
927   |   |            |                 |             | from queue #i.                                           |
928   |   |            |                 |             |                                                          |
929   |   |            |                 |             | *Next queue*  : queue with smallest T.                   |
930   |   |            |                 |             |                                                          |
931   |   |            |                 |             | Before packet consumption from queue #i:                 |
932   |   |            |                 |             |                                                          |
933   |   |            |                 |             | *T(i) |= mask(i)*                                        |
934   |   |            |                 |             |                                                          |
935   |   |            |                 |             | After packet consumption from queue #i:                  |
936   |   |            |                 |             |                                                          |
937   |   |            |                 |             | T(j) -= T(i), j != i                                     |
938   |   |            |                 |             |                                                          |
939   |   |            |                 |             | T(i) = pkt_len * t(i)                                    |
940   |   |            |                 |             |                                                          |
941   |   |            |                 |             | Note: T(j) uses the T(i) value before T(i) is updated.   |
942   |   |            |                 |             |                                                          |
943   +---+------------+-----------------+-------------+----------------------------------------------------------+
944
945Subport Traffic Class Oversubscription
946""""""""""""""""""""""""""""""""""""""
947
948Problem Statement
949'''''''''''''''''
950
951Oversubscription for subport traffic class X is a configuration-time event that occurs when
952more bandwidth is allocated for traffic class X at the level of subport member pipes than
953allocated for the same traffic class at the parent subport level.
954
955The existence of the oversubscription for a specific subport and
956traffic class is solely the result of pipe and
957subport-level configuration as opposed to being created due
958to dynamic evolution of the traffic load at run-time (as congestion is).
959
960When the overall demand for traffic class X for the current subport is low,
961the existence of the oversubscription condition does not represent a problem,
962as demand for traffic class X is completely satisfied for all member pipes.
963However, this can no longer be achieved when the aggregated demand for traffic class X
964for all subport member pipes exceeds the limit configured at the subport level.
965
966Solution Space
967''''''''''''''
968
969summarizes some of the possible approaches for handling this problem,
970with the third approach selected for implementation.
971
972.. _table_qos_13:
973
974.. table:: Subport Traffic Class Oversubscription
975
976   +-----+---------------------------+-------------------------------------------------------------------------+
977   | No. | Approach                  | Description                                                             |
978   |     |                           |                                                                         |
979   +=====+===========================+=========================================================================+
980   | 1   | Don't care                | First come, first served.                                               |
981   |     |                           |                                                                         |
982   |     |                           | This approach is not fair amongst subport member pipes, as pipes that   |
983   |     |                           | are served first will use up as much bandwidth for TC X as they need,   |
984   |     |                           | while pipes that are served later will receive poor service due to      |
985   |     |                           | bandwidth for TC X at the subport level being scarce.                   |
986   |     |                           |                                                                         |
987   +-----+---------------------------+-------------------------------------------------------------------------+
988   | 2   | Scale down all pipes      | All pipes within the subport have their bandwidth limit for TC X scaled |
989   |     |                           | down by the same factor.                                                |
990   |     |                           |                                                                         |
991   |     |                           | This approach is not fair among subport member pipes, as the low end    |
992   |     |                           | pipes (that is, pipes configured with low bandwidth) can potentially    |
993   |     |                           | experience severe service degradation that might render their service   |
994   |     |                           | unusable (if available bandwidth for these pipes drops below the        |
995   |     |                           | minimum requirements for a workable service), while the service         |
996   |     |                           | degradation for high end pipes might not be noticeable at all.          |
997   |     |                           |                                                                         |
998   +-----+---------------------------+-------------------------------------------------------------------------+
999   | 3   | Cap the high demand pipes | Each subport member pipe receives an equal share of the bandwidth       |
1000   |     |                           | available at run-time for TC X at the subport level. Any bandwidth left |
1001   |     |                           | unused by the low-demand pipes is redistributed in equal portions to    |
1002   |     |                           | the high-demand pipes. This way, the high-demand pipes are truncated    |
1003   |     |                           | while the low-demand pipes are not impacted.                            |
1004   |     |                           |                                                                         |
1005   +-----+---------------------------+-------------------------------------------------------------------------+
1006
1007Typically, the subport TC oversubscription feature is enabled only for the lowest priority traffic class (TC 3),
1008which is typically used for best effort traffic,
1009with the management plane preventing this condition from occurring for the other (higher priority) traffic classes.
1010
1011To ease implementation, it is also assumed that the upper limit for subport TC 3 is set to 100% of the subport rate,
1012and that the upper limit for pipe TC 3 is set to 100% of pipe rate for all subport member pipes.
1013
1014Implementation Overview
1015'''''''''''''''''''''''
1016
1017The algorithm computes a watermark, which is periodically updated based on the current demand experienced by the subport member pipes,
1018whose purpose is to limit the amount of traffic that each pipe is allowed to send for TC 3.
1019The watermark is computed at the subport level at the beginning of each traffic class upper limit enforcement period and
1020the same value is used by all the subport member pipes throughout the current enforcement period.
1021illustrates how the watermark computed as subport level at the beginning of each period is propagated to all subport member pipes.
1022
1023At the beginning of the current enforcement period (which coincides with the end of the previous enforcement period),
1024the value of the watermark is adjusted based on the amount of bandwidth allocated to TC 3 at the beginning of the previous period that
1025was not left unused by the subport member pipes at the end of the previous period.
1026
1027If there was subport TC 3 bandwidth left unused,
1028the value of the watermark for the current period is increased to encourage the subport member pipes to consume more bandwidth.
1029Otherwise, the value of the watermark is decreased to enforce equality of bandwidth consumption among subport member pipes for TC 3.
1030
1031The increase or decrease in the watermark value is done in small increments,
1032so several enforcement periods might be required to reach the equilibrium state.
1033This state can change at any moment due to variations in the demand experienced by the subport member pipes for TC 3, for example,
1034as a result of demand increase (when the watermark needs to be lowered) or demand decrease (when the watermark needs to be increased).
1035
1036When demand is low, the watermark is set high to prevent it from impeding the subport member pipes from consuming more bandwidth.
1037The highest value for the watermark is picked as the highest rate configured for a subport member pipe.
1038:numref:`table_qos_14` and :numref:`table_qos_15` illustrates the watermark operation.
1039
1040.. _table_qos_14:
1041
1042.. table:: Watermark Propagation from Subport Level to Member Pipes at the Beginning of Each Traffic Class Upper Limit Enforcement Period
1043
1044   +-----+---------------------------------+----------------------------------------------------+
1045   | No. | Subport Traffic Class Operation | Description                                        |
1046   |     |                                 |                                                    |
1047   +=====+=================================+====================================================+
1048   | 1   | Initialization                  | **Subport level**: subport_period_id= 0            |
1049   |     |                                 |                                                    |
1050   |     |                                 | **Pipe level**: pipe_period_id = 0                 |
1051   |     |                                 |                                                    |
1052   +-----+---------------------------------+----------------------------------------------------+
1053   | 2   | Credit update                   | **Subport Level**:                                 |
1054   |     |                                 |                                                    |
1055   |     |                                 | if (time>=subport_tc_time)                         |
1056   |     |                                 |                                                    |
1057   |     |                                 | {                                                  |
1058   |     |                                 |     subport_wm = water_mark_update();              |
1059   |     |                                 |                                                    |
1060   |     |                                 |     subport_tc_time = time + subport_tc_period;    |
1061   |     |                                 |                                                    |
1062   |     |                                 |     subport_period_id++;                           |
1063   |     |                                 |                                                    |
1064   |     |                                 | }                                                  |
1065   |     |                                 |                                                    |
1066   |     |                                 | **Pipelevel:**                                     |
1067   |     |                                 |                                                    |
1068   |     |                                 | if(pipe_period_id != subport_period_id)            |
1069   |     |                                 |                                                    |
1070   |     |                                 | {                                                  |
1071   |     |                                 |                                                    |
1072   |     |                                 |     pipe_ov_credits = subport_wm \* pipe_weight;   |
1073   |     |                                 |                                                    |
1074   |     |                                 |     pipe_period_id = subport_period_id;            |
1075   |     |                                 |                                                    |
1076   |     |                                 | }                                                  |
1077   |     |                                 |                                                    |
1078   +-----+---------------------------------+----------------------------------------------------+
1079   | 3   | Credit consumption              | **Pipe level:**                                    |
1080   |     | (on packet scheduling)          |                                                    |
1081   |     |                                 | pkt_credits = pk_len + frame_overhead;             |
1082   |     |                                 |                                                    |
1083   |     |                                 | if(pipe_ov_credits >= pkt_credits{                 |
1084   |     |                                 |                                                    |
1085   |     |                                 |    pipe_ov_credits -= pkt_credits;                 |
1086   |     |                                 |                                                    |
1087   |     |                                 | }                                                  |
1088   |     |                                 |                                                    |
1089   +-----+---------------------------------+----------------------------------------------------+
1090
1091.. _table_qos_15:
1092
1093.. table:: Watermark Calculation
1094
1095   +-----+------------------+----------------------------------------------------------------------------------+
1096   | No. | Subport Traffic  | Description                                                                      |
1097   |     | Class Operation  |                                                                                  |
1098   +=====+==================+==================================================================================+
1099   | 1   | Initialization   | **Subport level:**                                                               |
1100   |     |                  |                                                                                  |
1101   |     |                  | wm = WM_MAX                                                                      |
1102   |     |                  |                                                                                  |
1103   +-----+------------------+----------------------------------------------------------------------------------+
1104   | 2   | Credit update    | **Subport level (water_mark_update):**                                           |
1105   |     |                  |                                                                                  |
1106   |     |                  | tc0_cons = subport_tc0_credits_per_period - subport_tc0_credits;                 |
1107   |     |                  |                                                                                  |
1108   |     |                  | tc1_cons = subport_tc1_credits_per_period - subport_tc1_credits;                 |
1109   |     |                  |                                                                                  |
1110   |     |                  | tc2_cons = subport_tc2_credits_per_period - subport_tc2_credits;                 |
1111   |     |                  |                                                                                  |
1112   |     |                  | tc3_cons = subport_tc3_credits_per_period - subport_tc3_credits;                 |
1113   |     |                  |                                                                                  |
1114   |     |                  | tc3_cons_max = subport_tc3_credits_per_period - (tc0_cons + tc1_cons +           |
1115   |     |                  | tc2_cons);                                                                       |
1116   |     |                  |                                                                                  |
1117   |     |                  | if(tc3_consumption > (tc3_consumption_max - MTU)){                               |
1118   |     |                  |                                                                                  |
1119   |     |                  |     wm -= wm >> 7;                                                               |
1120   |     |                  |                                                                                  |
1121   |     |                  |     if(wm < WM_MIN) wm =  WM_MIN;                                                |
1122   |     |                  |                                                                                  |
1123   |     |                  | } else {                                                                         |
1124   |     |                  |                                                                                  |
1125   |     |                  |    wm += (wm >> 7) + 1;                                                          |
1126   |     |                  |                                                                                  |
1127   |     |                  |    if(wm > WM_MAX) wm = WM_MAX;                                                  |
1128   |     |                  |                                                                                  |
1129   |     |                  | }                                                                                |
1130   |     |                  |                                                                                  |
1131   +-----+------------------+----------------------------------------------------------------------------------+
1132
1133Worst Case Scenarios for Performance
1134~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1135
1136Lots of Active Queues with Not Enough Credits
1137^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1138
1139The more queues the scheduler has to examine for packets and credits in order to select one packet,
1140the lower the performance of the scheduler is.
1141
1142The scheduler maintains the bitmap of active queues, which skips the non-active queues,
1143but in order to detect whether a specific pipe has enough credits,
1144the pipe has to be drilled down using the pipe dequeue state machine,
1145which consumes cycles regardless of the scheduling result
1146(no packets are produced or at least one packet is produced).
1147
1148This scenario stresses the importance of the policer for the scheduler performance:
1149if the pipe does not have enough credits,
1150its packets should be dropped as soon as possible (before they reach the hierarchical scheduler),
1151thus rendering the pipe queues as not active,
1152which allows the dequeue side to skip that pipe with no cycles being spent on investigating the pipe credits
1153that would result in a "not enough credits" status.
1154
1155Single Queue with 100% Line Rate
1156^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1157
1158The port scheduler performance is optimized for a large number of queues.
1159If the number of queues is small,
1160then the performance of the port scheduler for the same level of active traffic is expected to be worse than
1161the performance of a small set of message passing queues.
1162
1163.. _Dropper:
1164
1165Dropper
1166-------
1167
1168The purpose of the DPDK dropper is to drop packets arriving at a packet scheduler to avoid congestion.
1169The dropper supports the Random Early Detection (RED),
1170Weighted Random Early Detection (WRED) and tail drop algorithms.
1171:numref:`figure_blk_diag_dropper` illustrates how the dropper integrates with the scheduler.
1172The DPDK currently does not support congestion management
1173so the dropper provides the only method for congestion avoidance.
1174
1175.. _figure_blk_diag_dropper:
1176
1177.. figure:: img/blk_diag_dropper.*
1178
1179   High-level Block Diagram of the DPDK Dropper
1180
1181
1182The dropper uses the Random Early Detection (RED) congestion avoidance algorithm as documented in the reference publication.
1183The purpose of the RED algorithm is to monitor a packet queue,
1184determine the current congestion level in the queue and decide whether an arriving packet should be enqueued or dropped.
1185The RED algorithm uses an Exponential Weighted Moving Average (EWMA) filter to compute average queue size which
1186gives an indication of the current congestion level in the queue.
1187
1188For each enqueue operation, the RED algorithm compares the average queue size to minimum and maximum thresholds.
1189Depending on whether the average queue size is below, above or in between these thresholds,
1190the RED algorithm calculates the probability that an arriving packet should be dropped and
1191makes a random decision based on this probability.
1192
1193The dropper also supports Weighted Random Early Detection (WRED) by allowing the scheduler to select
1194different RED configurations for the same packet queue at run-time.
1195In the case of severe congestion, the dropper resorts to tail drop.
1196This occurs when a packet queue has reached maximum capacity and cannot store any more packets.
1197In this situation, all arriving packets are dropped.
1198
1199The flow through the dropper is illustrated in :numref:`figure_flow_tru_droppper`.
1200The RED/WRED algorithm is exercised first and tail drop second.
1201
1202.. _figure_flow_tru_droppper:
1203
1204.. figure:: img/flow_tru_droppper.*
1205
1206   Flow Through the Dropper
1207
1208
1209The use cases supported by the dropper are:
1210
1211*   *    Initialize configuration data
1212
1213*   *    Initialize run-time data
1214
1215*   *    Enqueue (make a decision to enqueue or drop an arriving packet)
1216
1217*   *    Mark empty (record the time at which a packet queue becomes empty)
1218
1219The configuration use case is explained in :ref:`Section2.23.3.1 <Configuration>`,
1220the enqueue operation is explained in  :ref:`Section 2.23.3.2 <Enqueue_Operation>`
1221and the mark empty operation is explained in :ref:`Section 2.23.3.3 <Queue_Empty_Operation>`.
1222
1223.. _Configuration:
1224
1225Configuration
1226~~~~~~~~~~~~~
1227
1228A RED configuration contains the parameters given in :numref:`table_qos_16`.
1229
1230.. _table_qos_16:
1231
1232.. table:: RED Configuration Parameters
1233
1234   +--------------------------+---------+---------+------------------+
1235   | Parameter                | Minimum | Maximum | Typical          |
1236   |                          |         |         |                  |
1237   +==========================+=========+=========+==================+
1238   | Minimum Threshold        | 0       | 1022    | 1/4 x queue size |
1239   |                          |         |         |                  |
1240   +--------------------------+---------+---------+------------------+
1241   | Maximum Threshold        | 1       | 1023    | 1/2 x queue size |
1242   |                          |         |         |                  |
1243   +--------------------------+---------+---------+------------------+
1244   | Inverse Mark Probability | 1       | 255     | 10               |
1245   |                          |         |         |                  |
1246   +--------------------------+---------+---------+------------------+
1247   | EWMA Filter Weight       | 1       | 12      | 9                |
1248   |                          |         |         |                  |
1249   +--------------------------+---------+---------+------------------+
1250
1251The meaning of these parameters is explained in more detail in the following sections.
1252The format of these parameters as specified to the dropper module API
1253corresponds to the format used by Cisco* in their RED implementation.
1254The minimum and maximum threshold parameters are specified to the dropper module in terms of number of packets.
1255The mark probability parameter is specified as an inverse value, for example,
1256an inverse mark probability parameter value of 10 corresponds
1257to a mark probability of 1/10 (that is, 1 in 10 packets will be dropped).
1258The EWMA filter weight parameter is specified as an inverse log value,
1259for example, a filter weight parameter value of 9 corresponds to a filter weight of 1/29.
1260
1261.. _Enqueue_Operation:
1262
1263Enqueue Operation
1264~~~~~~~~~~~~~~~~~
1265
1266In the example shown in :numref:`figure_ex_data_flow_tru_dropper`, q (actual queue size) is the input value,
1267avg (average queue size) and count (number of packets since the last drop) are run-time values,
1268decision is the output value and the remaining values are configuration parameters.
1269
1270.. _figure_ex_data_flow_tru_dropper:
1271
1272.. figure:: img/ex_data_flow_tru_dropper.*
1273
1274   Example Data Flow Through Dropper
1275
1276
1277EWMA Filter Microblock
1278^^^^^^^^^^^^^^^^^^^^^^
1279
1280The purpose of the EWMA Filter microblock is to filter queue size values to smooth out transient changes
1281that result from "bursty" traffic.
1282The output value is the average queue size which gives a more stable view of the current congestion level in the queue.
1283
1284The EWMA filter has one configuration parameter, filter weight, which determines how quickly
1285or slowly the average queue size output responds to changes in the actual queue size input.
1286Higher values of filter weight mean that the average queue size responds more quickly to changes in actual queue size.
1287
1288Average Queue Size Calculation when the Queue is not Empty
1289""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
1290
1291The definition of the EWMA filter is given in the following equation.
1292
1293.. image:: img/ewma_filter_eq_1.*
1294
1295Where:
1296
1297*   *avg*  = average queue size
1298
1299*   *wq*   = filter weight
1300
1301*   *q*    = actual queue size
1302
1303.. note::
1304
1305    The filter weight, wq = 1/2^n, where n is the filter weight parameter value passed to the dropper module
1306	on configuration (see :ref:`Section2.23.3.1 <Configuration>` ).
1307
1308Average Queue Size Calculation when the Queue is Empty
1309^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1310
1311The EWMA filter does not read time stamps and instead assumes that enqueue operations will happen quite regularly.
1312Special handling is required when the queue becomes empty as the queue could be empty for a short time or a long time.
1313When the queue becomes empty, average queue size should decay gradually to zero instead of dropping suddenly to zero
1314or remaining stagnant at the last computed value.
1315When a packet is enqueued on an empty queue, the average queue size is computed using the following formula:
1316
1317.. image:: img/ewma_filter_eq_2.*
1318
1319Where:
1320
1321*   *m*   = the number of enqueue operations that could have occurred on this queue while the queue was empty
1322
1323In the dropper module, *m* is defined as:
1324
1325.. image:: img/m_definition.*
1326
1327Where:
1328
1329*   *time*  = current time
1330
1331*   *qtime* = time the queue became empty
1332
1333*   *s* = typical time between successive enqueue operations on this queue
1334
1335The time reference is in units of bytes,
1336where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium
1337(see Section `Internal Time Reference`_).
1338The parameter s is defined in the dropper module as a constant with the value: s=2^22.
1339This corresponds to the time required by every leaf node in a hierarchy with 64K leaf nodes
1340to transmit one 64-byte packet onto the wire and represents the worst case scenario.
1341For much smaller scheduler hierarchies,
1342it may be necessary to reduce the parameter s, which is defined in the red header source file (rte_red.h) as:
1343
1344.. code-block:: c
1345
1346    #define RTE_RED_S
1347
1348Since the time reference is in bytes, the port speed is implied in the expression: *time-qtime*.
1349The dropper does not have to be configured with the actual port speed.
1350It adjusts automatically to low speed and high speed links.
1351
1352Implementation
1353""""""""""""""
1354
1355A numerical method is used to compute the factor (1-wq)^m that appears in Equation 2.
1356
1357This method is based on the following identity:
1358
1359.. image:: img/eq2_factor.*
1360
1361
1362This allows us to express the following:
1363
1364.. image:: img/eq2_expression.*
1365
1366
1367In the dropper module, a look-up table is used to compute log2(1-wq) for each value of wq supported by the dropper module.
1368The factor (1-wq)^m can then be obtained by multiplying the table value by *m* and applying shift operations.
1369To avoid overflow in the multiplication, the value, *m*, and the look-up table values are limited to 16 bits.
1370The total size of the look-up table is 56 bytes.
1371Once the factor (1-wq)^m is obtained using this method, the average queue size can be calculated from Equation 2.
1372
1373Alternative Approaches
1374""""""""""""""""""""""
1375
1376Other methods for calculating the factor (1-wq)^m in the expression for computing average queue size
1377when the queue is empty (Equation 2) were considered.
1378These approaches include:
1379
1380*   Floating-point evaluation
1381
1382*   Fixed-point evaluation using a small look-up table (512B) and up to 16 multiplications
1383    (this is the approach used in the FreeBSD* ALTQ RED implementation)
1384
1385*   Fixed-point evaluation using a small look-up table (512B) and 16 SSE multiplications
1386    (SSE optimized version of the approach used in the FreeBSD* ALTQ RED implementation)
1387
1388*   Large look-up table (76 KB)
1389
1390The method that was finally selected (described above in Section 26.3.2.2.1) out performs all of these approaches
1391in terms of run-time performance and memory requirements and
1392also achieves accuracy comparable to floating-point evaluation.
1393:numref:`table_qos_17` lists the performance of each of these alternative approaches relative to the method that is used in the dropper.
1394As can be seen, the floating-point implementation achieved the worst performance.
1395
1396.. _table_qos_17:
1397
1398.. table:: Relative Performance of Alternative Approaches
1399
1400   +------------------------------------------------------------------------------------+----------------------+
1401   | Method                                                                             | Relative Performance |
1402   |                                                                                    |                      |
1403   +====================================================================================+======================+
1404   | Current dropper method (see :ref:`Section 23.3.2.1.3 <Dropper>`)                   | 100%                 |
1405   |                                                                                    |                      |
1406   +------------------------------------------------------------------------------------+----------------------+
1407   | Fixed-point method with small (512B) look-up table                                 | 148%                 |
1408   |                                                                                    |                      |
1409   +------------------------------------------------------------------------------------+----------------------+
1410   | SSE method with small (512B) look-up table                                         | 114%                 |
1411   |                                                                                    |                      |
1412   +------------------------------------------------------------------------------------+----------------------+
1413   | Large (76KB) look-up table                                                         | 118%                 |
1414   |                                                                                    |                      |
1415   +------------------------------------------------------------------------------------+----------------------+
1416   | Floating-point                                                                     | 595%                 |
1417   |                                                                                    |                      |
1418   +------------------------------------------------------------------------------------+----------------------+
1419   | **Note**: In this case, since performance is expressed as time spent executing the operation in a         |
1420   | specific condition, any relative performance value above 100% runs slower than the reference method.      |
1421   |                                                                                                           |
1422   +-----------------------------------------------------------------------------------------------------------+
1423
1424Drop Decision Block
1425^^^^^^^^^^^^^^^^^^^
1426
1427The Drop Decision block:
1428
1429*   Compares the average queue size with the minimum and maximum thresholds
1430
1431*   Calculates a packet drop probability
1432
1433*   Makes a random decision to enqueue or drop an arriving packet
1434
1435The calculation of the drop probability occurs in two stages.
1436An initial drop probability is calculated based on the average queue size,
1437the minimum and maximum thresholds and the mark probability.
1438An actual drop probability is then computed from the initial drop probability.
1439The actual drop probability takes the count run-time value into consideration
1440so that the actual drop probability increases as more packets arrive to the packet queue
1441since the last packet was dropped.
1442
1443Initial Packet Drop Probability
1444"""""""""""""""""""""""""""""""
1445
1446The initial drop probability is calculated using the following equation.
1447
1448.. image:: img/drop_probability_eq3.*
1449
1450Where:
1451
1452*   *maxp*  = mark probability
1453
1454*   *avg*  = average queue size
1455
1456*   *minth*  = minimum threshold
1457
1458*   *maxth*  = maximum threshold
1459
1460The calculation of the packet drop probability using Equation 3 is illustrated in :numref:`figure_pkt_drop_probability`.
1461If the average queue size is below the minimum threshold, an arriving packet is enqueued.
1462If the average queue size is at or above the maximum threshold, an arriving packet is dropped.
1463If the average queue size is between the minimum and maximum thresholds,
1464a drop probability is calculated to determine if the packet should be enqueued or dropped.
1465
1466.. _figure_pkt_drop_probability:
1467
1468.. figure:: img/pkt_drop_probability.*
1469
1470   Packet Drop Probability for a Given RED Configuration
1471
1472
1473Actual Drop Probability
1474"""""""""""""""""""""""
1475
1476If the average queue size is between the minimum and maximum thresholds,
1477then the actual drop probability is calculated from the following equation.
1478
1479.. image:: img/drop_probability_eq4.*
1480
1481Where:
1482
1483*   *Pb*  = initial drop probability (from Equation 3)
1484
1485*   *count* = number of packets that have arrived since the last drop
1486
1487The constant 2, in Equation 4 is the only deviation from the drop probability formulae
1488given in the reference document where a value of 1 is used instead.
1489It should be noted that the value pa computed from can be negative or greater than 1.
1490If this is the case, then a value of 1 should be used instead.
1491
1492The initial and actual drop probabilities are shown in :numref:`figure_drop_probability_graph`.
1493The actual drop probability is shown for the case where
1494the formula given in the reference document1 is used (blue curve)
1495and also for the case where the formula implemented in the dropper module,
1496is used (red curve).
1497The formula in the reference document results in a significantly higher drop rate
1498compared to the mark probability configuration parameter specified by the user.
1499The choice to deviate from the reference document is simply a design decision and
1500one that has been taken by other RED implementations, for example, FreeBSD* ALTQ RED.
1501
1502.. _figure_drop_probability_graph:
1503
1504.. figure:: img/drop_probability_graph.*
1505
1506   Initial Drop Probability (pb), Actual Drop probability (pa) Computed Using
1507   a Factor 1 (Blue Curve) and a Factor 2 (Red Curve)
1508
1509
1510.. _Queue_Empty_Operation:
1511
1512Queue Empty Operation
1513~~~~~~~~~~~~~~~~~~~~~
1514
1515The time at which a packet queue becomes empty must be recorded and saved with the RED run-time data
1516so that the EWMA filter block can calculate the average queue size on the next enqueue operation.
1517It is the responsibility of the calling application to inform the dropper module
1518through the API that a queue has become empty.
1519
1520Source Files Location
1521~~~~~~~~~~~~~~~~~~~~~
1522
1523The source files for the DPDK dropper are located at:
1524
1525*   DPDK/lib/librte_sched/rte_red.h
1526
1527*   DPDK/lib/librte_sched/rte_red.c
1528
1529Integration with the DPDK QoS Scheduler
1530~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1531
1532RED functionality in the DPDK QoS scheduler is disabled by default.
1533To enable it, use the DPDK configuration parameter:
1534
1535::
1536
1537    CONFIG_RTE_SCHED_RED=y
1538
1539This parameter must be set to y.
1540The parameter is found in the build configuration files in the DPDK/config directory,
1541for example, DPDK/config/common_linuxapp.
1542RED configuration parameters are specified in the rte_red_params structure within the rte_sched_port_params structure
1543that is passed to the scheduler on initialization.
1544RED parameters are specified separately for four traffic classes and three packet colors (green, yellow and red)
1545allowing the scheduler to implement Weighted Random Early Detection (WRED).
1546
1547Integration with the DPDK QoS Scheduler Sample Application
1548~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1549
1550The DPDK QoS Scheduler Application reads a configuration file on start-up.
1551The configuration file includes a section containing RED parameters.
1552The format of these parameters is described in :ref:`Section2.23.3.1 <Configuration>`.
1553A sample RED configuration is shown below. In this example, the queue size is 64 packets.
1554
1555.. note::
1556
1557    For correct operation, the same EWMA filter weight parameter (wred weight) should be used
1558    for each packet color (green, yellow, red) in the same traffic class (tc).
1559
1560::
1561
1562    ; RED params per traffic class and color (Green / Yellow / Red)
1563
1564   [red]
1565   tc 0 wred min = 28 22 16
1566   tc 0 wred max = 32 32 32
1567   tc 0 wred inv prob = 10 10 10
1568   tc 0 wred weight = 9 9 9
1569
1570   tc 1 wred min = 28 22 16
1571   tc 1 wred max = 32 32 32
1572   tc 1 wred inv prob = 10 10 10
1573   tc 1 wred weight = 9 9 9
1574
1575   tc 2 wred min = 28 22 16
1576   tc 2 wred max = 32 32 32
1577   tc 2 wred inv prob = 10 10 10
1578   tc 2 wred weight = 9 9 9
1579
1580   tc 3 wred min = 28 22 16
1581   tc 3 wred max = 32 32 32
1582   tc 3 wred inv prob = 10 10 10
1583   tc 3 wred weight = 9 9 9
1584
1585With this configuration file, the RED configuration that applies to green,
1586yellow and red packets in traffic class 0 is shown in :numref:`table_qos_18`.
1587
1588.. _table_qos_18:
1589
1590.. table:: RED Configuration Corresponding to RED Configuration File
1591
1592   +--------------------+--------------------+-------+--------+-----+
1593   | RED Parameter      | Configuration Name | Green | Yellow | Red |
1594   |                    |                    |       |        |     |
1595   +====================+====================+=======+========+=====+
1596   | Minimum Threshold  | tc 0 wred min      | 28    | 22     | 16  |
1597   |                    |                    |       |        |     |
1598   +--------------------+--------------------+-------+--------+-----+
1599   | Maximum Threshold  | tc 0 wred max      | 32    | 32     | 32  |
1600   |                    |                    |       |        |     |
1601   +--------------------+--------------------+-------+--------+-----+
1602   | Mark Probability   | tc 0 wred inv prob | 10    | 10     | 10  |
1603   |                    |                    |       |        |     |
1604   +--------------------+--------------------+-------+--------+-----+
1605   | EWMA Filter Weight | tc 0 wred weight   | 9     | 9      | 9   |
1606   |                    |                    |       |        |     |
1607   +--------------------+--------------------+-------+--------+-----+
1608
1609Application Programming Interface (API)
1610~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1611
1612Enqueue API
1613^^^^^^^^^^^
1614
1615The syntax of the enqueue API is as follows:
1616
1617.. code-block:: c
1618
1619   int rte_red_enqueue(const struct rte_red_config *red_cfg, struct rte_red *red, const unsigned q, const uint64_t time)
1620
1621
1622The arguments passed to the enqueue API are configuration data, run-time data,
1623the current size of the packet queue (in packets) and a value representing the current time.
1624The time reference is in units of bytes,
1625where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium
1626(see Section 26.2.4.5.1 "Internal Time Reference" ).
1627The dropper reuses the scheduler time stamps for performance reasons.
1628
1629Empty API
1630^^^^^^^^^
1631
1632The syntax of the empty API is as follows:
1633
1634.. code-block:: c
1635
1636    void rte_red_mark_queue_empty(struct rte_red *red, const uint64_t time)
1637
1638The arguments passed to the empty API are run-time data and the current time in bytes.
1639
1640Traffic Metering
1641----------------
1642
1643The traffic metering component implements the Single Rate Three Color Marker (srTCM) and
1644Two Rate Three Color Marker (trTCM) algorithms, as defined by IETF RFC 2697 and 2698 respectively.
1645These algorithms meter the stream of incoming packets based on the allowance defined in advance for each traffic flow.
1646As result, each incoming packet is tagged as green,
1647yellow or red based on the monitored consumption of the flow the packet belongs to.
1648
1649Functional Overview
1650~~~~~~~~~~~~~~~~~~~
1651
1652The srTCM algorithm defines two token buckets for each traffic flow,
1653with the two buckets sharing the same token update rate:
1654
1655*   Committed (C) bucket: fed with tokens at the rate defined by the Committed Information Rate (CIR) parameter
1656    (measured in IP packet bytes per second).
1657    The size of the C bucket is defined by the Committed Burst Size (CBS) parameter (measured in bytes);
1658
1659*   Excess (E) bucket: fed with tokens at the same rate as the C bucket.
1660    The size of the E bucket is defined by the Excess Burst Size (EBS) parameter (measured in bytes).
1661
1662The trTCM algorithm defines two token buckets for each traffic flow,
1663with the two buckets being updated with tokens at independent rates:
1664
1665*   Committed (C) bucket: fed with tokens at the rate defined by the Committed Information Rate (CIR) parameter
1666    (measured in bytes of IP packet per second).
1667    The size of the C bucket is defined by the Committed Burst Size (CBS) parameter (measured in bytes);
1668
1669*   Peak (P) bucket: fed with tokens at the rate defined by the Peak Information Rate (PIR) parameter
1670    (measured in IP packet bytes per second).
1671    The size of the P bucket is defined by the Peak Burst Size (PBS) parameter (measured in bytes).
1672
1673Please refer to RFC 2697 (for srTCM) and RFC 2698 (for trTCM) for details on how tokens are consumed
1674from the buckets and how the packet color is determined.
1675
1676Color Blind and Color Aware Modes
1677^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1678
1679For both algorithms, the color blind mode is functionally equivalent to the color aware mode with input color set as green.
1680For color aware mode, a packet with red input color can only get the red output color,
1681while a packet with yellow input color can only get the yellow or red output colors.
1682
1683The reason why the color blind mode is still implemented distinctly than the color aware mode is
1684that color blind mode can be implemented with fewer operations than the color aware mode.
1685
1686Implementation Overview
1687~~~~~~~~~~~~~~~~~~~~~~~
1688
1689For each input packet, the steps for the srTCM / trTCM algorithms are:
1690
1691*   Update the C and E / P token buckets. This is done by reading the current time (from the CPU timestamp counter),
1692    identifying the amount of time since the last bucket update and computing the associated number of tokens
1693    (according to the pre-configured bucket rate).
1694    The number of tokens in the bucket is limited by the pre-configured bucket size;
1695
1696*   Identify the output color for the current packet based on the size of the IP packet
1697    and the amount of tokens currently available in the C and E / P buckets; for color aware mode only,
1698    the input color of the packet is also considered.
1699    When the output color is not red, a number of tokens equal to the length of the IP packet are
1700    subtracted from the C or E /P or both buckets, depending on the algorithm and the output color of the packet.
1701