Quality of Service (QoS) Framework
==================================
-This chapter describes the Intel® DPDK Quality of Service (QoS) framework.
+This chapter describes the DPDK Quality of Service (QoS) framework.
Packet Pipeline with QoS Support
--------------------------------
An example of a complex packet processing pipeline with QoS support is shown in the following figure.
-.. _pg_figure_21:
+.. _figure_pkt_proc_pipeline_qos:
-**Figure 21. Complex Packet Processing Pipeline with QoS Support**
+.. figure:: img/pkt_proc_pipeline_qos.*
-.. image47_png has been renamed
+ Complex Packet Processing Pipeline with QoS Support
-|pkt_proc_pipeline_qos|
-This pipeline can be built using reusable Intel® DPDK software libraries.
+This pipeline can be built using reusable DPDK software libraries.
The main blocks implementing QoS in this pipeline are: the policer, the dropper and the scheduler.
A functional description of each block is provided in the following table.
-.. _pg_table_1:
-
-**Table 1. Packet Processing Pipeline Implementing QoS**
-
-+---+------------------------+--------------------------------------------------------------------------------+
-| # | Block | Functional Description |
-| | | |
-+===+========================+================================================================================+
-| 1 | Packet I/O RX & TX | Packet reception/ transmission from/to multiple NIC ports. Poll mode drivers |
-| | | (PMDs) for Intel 1 GbE/10 GbE NICs. |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 2 | Packet parser | Identify the protocol stack of the input packet. Check the integrity of the |
-| | | packet headers. |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 3 | Flow classification | Map the input packet to one of the known traffic flows. Exact match table |
-| | | lookup using configurable hash function (jhash, CRC and so on) and bucket |
-| | | logic to handle collisions. |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 4 | Policer | Packet metering using srTCM (RFC 2697) or trTCM (RFC2698) algorithms. |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 5 | Load Balancer | Distribute the input packets to the application workers. Provide uniform load |
-| | | to each worker. Preserve the affinity of traffic flows to workers and the |
-| | | packet order within each flow. |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 6 | Worker threads | Placeholders for the customer specific application workload (for example, IP |
-| | | stack and so on). |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 7 | Dropper | Congestion management using the Random Early Detection (RED) algorithm |
-| | | (specified by the Sally Floyd - Van Jacobson paper) or Weighted RED (WRED). |
-| | | Drop packets based on the current scheduler queue load level and packet |
-| | | priority. When congestion is experienced, lower priority packets are dropped |
-| | | first. |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
-| 8 | Hierarchical Scheduler | 5-level hierarchical scheduler (levels are: output port, subport, pipe, |
-| | | traffic class and queue) with thousands (typically 64K) leaf nodes (queues). |
-| | | Implements traffic shaping (for subport and pipe levels), strict priority |
-| | | (for traffic class level) and Weighted Round Robin (WRR) (for queues within |
-| | | each pipe traffic class). |
-| | | |
-+---+------------------------+--------------------------------------------------------------------------------+
+.. _table_qos_1:
+
+.. table:: Packet Processing Pipeline Implementing QoS
+
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | # | Block | Functional Description |
+ | | | |
+ +===+========================+================================================================================+
+ | 1 | Packet I/O RX & TX | Packet reception/ transmission from/to multiple NIC ports. Poll mode drivers |
+ | | | (PMDs) for Intel 1 GbE/10 GbE NICs. |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 2 | Packet parser | Identify the protocol stack of the input packet. Check the integrity of the |
+ | | | packet headers. |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 3 | Flow classification | Map the input packet to one of the known traffic flows. Exact match table |
+ | | | lookup using configurable hash function (jhash, CRC and so on) and bucket |
+ | | | logic to handle collisions. |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 4 | Policer | Packet metering using srTCM (RFC 2697) or trTCM (RFC2698) algorithms. |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 5 | Load Balancer | Distribute the input packets to the application workers. Provide uniform load |
+ | | | to each worker. Preserve the affinity of traffic flows to workers and the |
+ | | | packet order within each flow. |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 6 | Worker threads | Placeholders for the customer specific application workload (for example, IP |
+ | | | stack and so on). |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 7 | Dropper | Congestion management using the Random Early Detection (RED) algorithm |
+ | | | (specified by the Sally Floyd - Van Jacobson paper) or Weighted RED (WRED). |
+ | | | Drop packets based on the current scheduler queue load level and packet |
+ | | | priority. When congestion is experienced, lower priority packets are dropped |
+ | | | first. |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
+ | 8 | Hierarchical Scheduler | 5-level hierarchical scheduler (levels are: output port, subport, pipe, |
+ | | | traffic class and queue) with thousands (typically 64K) leaf nodes (queues). |
+ | | | Implements traffic shaping (for subport and pipe levels), strict priority |
+ | | | (for traffic class level) and Weighted Round Robin (WRR) (for queues within |
+ | | | each pipe traffic class). |
+ | | | |
+ +---+------------------------+--------------------------------------------------------------------------------+
The infrastructure blocks used throughout the packet processing pipeline are listed in the following table.
-.. _pg_table_2:
+.. _table_qos_2:
-**Table 2. Infrastructure Blocks Used by the Packet Processing Pipeline**
+.. table:: Infrastructure Blocks Used by the Packet Processing Pipeline
-+---+-----------------------+-----------------------------------------------------------------------+
-| # | Block | Functional Description |
-| | | |
-+===+=======================+=======================================================================+
-| 1 | Buffer manager | Support for global buffer pools and private per-thread buffer caches. |
-| | | |
-+---+-----------------------+-----------------------------------------------------------------------+
-| 2 | Queue manager | Support for message passing between pipeline blocks. |
-| | | |
-+---+-----------------------+-----------------------------------------------------------------------+
-| 3 | Power saving | Support for power saving during low activity periods. |
-| | | |
-+---+-----------------------+-----------------------------------------------------------------------+
+ +---+-----------------------+-----------------------------------------------------------------------+
+ | # | Block | Functional Description |
+ | | | |
+ +===+=======================+=======================================================================+
+ | 1 | Buffer manager | Support for global buffer pools and private per-thread buffer caches. |
+ | | | |
+ +---+-----------------------+-----------------------------------------------------------------------+
+ | 2 | Queue manager | Support for message passing between pipeline blocks. |
+ | | | |
+ +---+-----------------------+-----------------------------------------------------------------------+
+ | 3 | Power saving | Support for power saving during low activity periods. |
+ | | | |
+ +---+-----------------------+-----------------------------------------------------------------------+
The mapping of pipeline blocks to CPU cores is configurable based on the performance level required by each specific application
and the set of features enabled for each block.
as the NIC TX is requesting more packets for transmission,
these packets are later on removed and handed over to the NIC TX with the packet selection logic observing the predefined SLAs (dequeue operation).
-.. _pg_figure_22:
+.. _figure_hier_sched_blk:
-**Figure 22. Hierarchical Scheduler Block Internal Diagram**
+.. figure:: img/hier_sched_blk.*
-.. image48_png has been renamed
+ Hierarchical Scheduler Block Internal Diagram
-|hier_sched_blk|
The hierarchical scheduler is optimized for a large number of packet queues.
When only a small number of queues are needed, message passing queues should be used instead of this block.
-See Section 26.2.5 "Worst Case Scenarios for Performance" for a more detailed discussion.
+See `Worst Case Scenarios for Performance`_ for a more detailed discussion.
Scheduling Hierarchy
~~~~~~~~~~~~~~~~~~~~
-The scheduling hierarchy is shown in Figure 23.
+The scheduling hierarchy is shown in :numref:`figure_sched_hier_per_port`.
The first level of the hierarchy is the Ethernet TX port 1/10/40 GbE,
with subsequent hierarchy levels defined as subport, pipe, traffic class and queue.
delay and jitter requirements, such as voice, video or data transfers.
Each queue hosts packets from one or multiple connections of the same type belonging to the same user.
-.. _pg_figure_23:
+.. _figure_sched_hier_per_port:
-**Figure 23. Scheduling Hierarchy per Port**
+.. figure:: img/sched_hier_per_port.*
-.. image49_png has been renamed
+ Scheduling Hierarchy per Port
-|sched_hier_per_port|
The functionality of each hierarchical level is detailed in the following table.
-.. _pg_table_3:
-
-**Table 3. Port Scheduling Hierarchy**
-
-+---+--------------------+----------------------------+---------------------------------------------------------------+
-| # | Level | Siblings per Parent | Functional Description |
-| | | | |
-+===+====================+============================+===============================================================+
-| 1 | Port | - | #. Output Ethernet port 1/10/40 GbE. |
-| | | | |
-| | | | #. Multiple ports are scheduled in round robin order with |
-| | | | all ports having equal priority. |
-| | | | |
-+---+--------------------+----------------------------+---------------------------------------------------------------+
-| 2 | Subport | Configurable (default: 8) | #. Traffic shaping using token bucket algorithm (one token |
-| | | | bucket per subport). |
-| | | | |
-| | | | #. Upper limit enforced per Traffic Class (TC) at the |
-| | | | subport level. |
-| | | | |
-| | | | #. Lower priority TCs able to reuse subport bandwidth |
-| | | | currently unused by higher priority TCs. |
-| | | | |
-+---+--------------------+----------------------------+---------------------------------------------------------------+
-| 3 | Pipe | Configurable (default: 4K) | #. Traffic shaping using the token bucket algorithm (one |
-| | | | token bucket per pipe. |
-| | | | |
-+---+--------------------+----------------------------+---------------------------------------------------------------+
-| 4 | Traffic Class (TC) | 4 | #. TCs of the same pipe handled in strict priority order. |
-| | | | |
-| | | | #. Upper limit enforced per TC at the pipe level. |
-| | | | |
-| | | | #. Lower priority TCs able to reuse pipe bandwidth currently |
-| | | | unused by higher priority TCs. |
-| | | | |
-| | | | #. When subport TC is oversubscribed (configuration time |
-| | | | event), pipe TC upper limit is capped to a dynamically |
-| | | | adjusted value that is shared by all the subport pipes. |
-| | | | |
-+---+--------------------+----------------------------+---------------------------------------------------------------+
-| 5 | Queue | 4 | #. Queues of the same TC are serviced using Weighted Round |
-| | | | Robin (WRR) according to predefined weights. |
-| | | | |
-+---+--------------------+----------------------------+---------------------------------------------------------------+
+.. _table_qos_3:
+
+.. table:: Port Scheduling Hierarchy
+
+ +---+--------------------+----------------------------+---------------------------------------------------------------+
+ | # | Level | Siblings per Parent | Functional Description |
+ | | | | |
+ +===+====================+============================+===============================================================+
+ | 1 | Port | - | #. Output Ethernet port 1/10/40 GbE. |
+ | | | | |
+ | | | | #. Multiple ports are scheduled in round robin order with |
+ | | | | all ports having equal priority. |
+ | | | | |
+ +---+--------------------+----------------------------+---------------------------------------------------------------+
+ | 2 | Subport | Configurable (default: 8) | #. Traffic shaping using token bucket algorithm (one token |
+ | | | | bucket per subport). |
+ | | | | |
+ | | | | #. Upper limit enforced per Traffic Class (TC) at the |
+ | | | | subport level. |
+ | | | | |
+ | | | | #. Lower priority TCs able to reuse subport bandwidth |
+ | | | | currently unused by higher priority TCs. |
+ | | | | |
+ +---+--------------------+----------------------------+---------------------------------------------------------------+
+ | 3 | Pipe | Configurable (default: 4K) | #. Traffic shaping using the token bucket algorithm (one |
+ | | | | token bucket per pipe. |
+ | | | | |
+ +---+--------------------+----------------------------+---------------------------------------------------------------+
+ | 4 | Traffic Class (TC) | 4 | #. TCs of the same pipe handled in strict priority order. |
+ | | | | |
+ | | | | #. Upper limit enforced per TC at the pipe level. |
+ | | | | |
+ | | | | #. Lower priority TCs able to reuse pipe bandwidth currently |
+ | | | | unused by higher priority TCs. |
+ | | | | |
+ | | | | #. When subport TC is oversubscribed (configuration time |
+ | | | | event), pipe TC upper limit is capped to a dynamically |
+ | | | | adjusted value that is shared by all the subport pipes. |
+ | | | | |
+ +---+--------------------+----------------------------+---------------------------------------------------------------+
+ | 5 | Queue | 4 | #. Queues of the same TC are serviced using Weighted Round |
+ | | | | Robin (WRR) according to predefined weights. |
+ | | | | |
+ +---+--------------------+----------------------------+---------------------------------------------------------------+
Application Programming Interface (API)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Port Scheduler Enqueue API
^^^^^^^^^^^^^^^^^^^^^^^^^^
-The port scheduler enqueue API is very similar to the API of the Intel® DPDK PMD TX function.
+The port scheduler enqueue API is very similar to the API of the DPDK PMD TX function.
.. code-block:: c
Port Scheduler Dequeue API
^^^^^^^^^^^^^^^^^^^^^^^^^^
-The port scheduler dequeue API is very similar to the API of the Intel® DPDK PMD RX function.
+The port scheduler dequeue API is very similar to the API of the DPDK PMD RX function.
.. code-block:: c
A schematic of the internal data structures in shown in with details in.
-.. _pg_figure_24:
-
-**Figure 24. Internal Data Structures per Port**
-
-.. image50_png has been renamed
-
-|data_struct_per_port|
-
-.. _pg_table_4:
-
-**Table 4. Scheduler Internal Data Structures per Port**
-
-+---+----------------------+-------------------------+---------------------+------------------------------+---------------------------------------------------+
-| # | Data structure | Size (bytes) | # per port | Access type | Description |
-| | | | | | |
-| | | | +-------------+----------------+---------------------------------------------------+
-| | | | | Enq | Deq | |
-| | | | | | | |
-+===+======================+=========================+=====================+=============+================+===================================================+
-| 1 | Subport table entry | 64 | # subports per port | - | Rd, Wr | Persistent subport data (credits, etc). |
-| | | | | | | |
-+---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
-| 2 | Pipe table entry | 64 | # pipes per port | - | Rd, Wr | Persistent data for pipe, its TCs and its queues |
-| | | | | | | (credits, etc) that is updated during run-time. |
-| | | | | | | |
-| | | | | | | The pipe configuration parameters do not change |
-| | | | | | | during run-time. The same pipe configuration |
-| | | | | | | parameters are shared by multiple pipes, |
-| | | | | | | therefore they are not part of pipe table entry. |
-| | | | | | | |
-+---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
-| 3 | Queue table entry | 4 | #queues per port | Rd, Wr | Rd, Wr | Persistent queue data (read and write pointers). |
-| | | | | | | The queue size is the same per TC for all queues, |
-| | | | | | | allowing the queue base address to be computed |
-| | | | | | | using a fast formula, so these two parameters are |
-| | | | | | | not part of queue table entry. |
-| | | | | | | |
-| | | | | | | The queue table entries for any given pipe are |
-| | | | | | | stored in the same cache line. |
-| | | | | | | |
-+---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
-| 4 | Queue storage area | Config (default: 64 x8) | # queues per port | Wr | Rd | Array of elements per queue; each element is 8 |
-| | | | | | | byte in size (mbuf pointer). |
-| | | | | | | |
-+---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
-| 5 | Active queues bitmap | 1 bit per queue | 1 | Wr (Set) | Rd, Wr (Clear) | The bitmap maintains one status bit per queue: |
-| | | | | | | queue not active (queue is empty) or queue active |
-| | | | | | | (queue is not empty). |
-| | | | | | | |
-| | | | | | | Queue bit is set by the scheduler enqueue and |
-| | | | | | | cleared by the scheduler dequeue when queue |
-| | | | | | | becomes empty. |
-| | | | | | | |
-| | | | | | | Bitmap scan operation returns the next non-empty |
-| | | | | | | pipe and its status (16-bit mask of active queue |
-| | | | | | | in the pipe). |
-| | | | | | | |
-+---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
-| 6 | Grinder | ~128 | Config (default: 8) | - | Rd, Wr | Short list of active pipes currently under |
-| | | | | | | processing. The grinder contains temporary data |
-| | | | | | | during pipe processing. |
-| | | | | | | |
-| | | | | | | Once the current pipe exhausts packets or |
-| | | | | | | credits, it is replaced with another active pipe |
-| | | | | | | from the bitmap. |
-| | | | | | | |
-+---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
+.. _figure_data_struct_per_port:
+
+.. figure:: img/data_struct_per_port.*
+
+ Internal Data Structures per Port
+
+
+.. _table_qos_4:
+
+.. table:: Scheduler Internal Data Structures per Port
+
+ +---+----------------------+-------------------------+---------------------+------------------------------+---------------------------------------------------+
+ | # | Data structure | Size (bytes) | # per port | Access type | Description |
+ | | | | | | |
+ | | | | +-------------+----------------+---------------------------------------------------+
+ | | | | | Enq | Deq | |
+ | | | | | | | |
+ +===+======================+=========================+=====================+=============+================+===================================================+
+ | 1 | Subport table entry | 64 | # subports per port | - | Rd, Wr | Persistent subport data (credits, etc). |
+ | | | | | | | |
+ +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
+ | 2 | Pipe table entry | 64 | # pipes per port | - | Rd, Wr | Persistent data for pipe, its TCs and its queues |
+ | | | | | | | (credits, etc) that is updated during run-time. |
+ | | | | | | | |
+ | | | | | | | The pipe configuration parameters do not change |
+ | | | | | | | during run-time. The same pipe configuration |
+ | | | | | | | parameters are shared by multiple pipes, |
+ | | | | | | | therefore they are not part of pipe table entry. |
+ | | | | | | | |
+ +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
+ | 3 | Queue table entry | 4 | #queues per port | Rd, Wr | Rd, Wr | Persistent queue data (read and write pointers). |
+ | | | | | | | The queue size is the same per TC for all queues, |
+ | | | | | | | allowing the queue base address to be computed |
+ | | | | | | | using a fast formula, so these two parameters are |
+ | | | | | | | not part of queue table entry. |
+ | | | | | | | |
+ | | | | | | | The queue table entries for any given pipe are |
+ | | | | | | | stored in the same cache line. |
+ | | | | | | | |
+ +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
+ | 4 | Queue storage area | Config (default: 64 x8) | # queues per port | Wr | Rd | Array of elements per queue; each element is 8 |
+ | | | | | | | byte in size (mbuf pointer). |
+ | | | | | | | |
+ +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
+ | 5 | Active queues bitmap | 1 bit per queue | 1 | Wr (Set) | Rd, Wr (Clear) | The bitmap maintains one status bit per queue: |
+ | | | | | | | queue not active (queue is empty) or queue active |
+ | | | | | | | (queue is not empty). |
+ | | | | | | | |
+ | | | | | | | Queue bit is set by the scheduler enqueue and |
+ | | | | | | | cleared by the scheduler dequeue when queue |
+ | | | | | | | becomes empty. |
+ | | | | | | | |
+ | | | | | | | Bitmap scan operation returns the next non-empty |
+ | | | | | | | pipe and its status (16-bit mask of active queue |
+ | | | | | | | in the pipe). |
+ | | | | | | | |
+ +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
+ | 6 | Grinder | ~128 | Config (default: 8) | - | Rd, Wr | Short list of active pipes currently under |
+ | | | | | | | processing. The grinder contains temporary data |
+ | | | | | | | during pipe processing. |
+ | | | | | | | |
+ | | | | | | | Once the current pipe exhausts packets or |
+ | | | | | | | credits, it is replaced with another active pipe |
+ | | | | | | | from the bitmap. |
+ | | | | | | | |
+ +---+----------------------+-------------------------+---------------------+-------------+----------------+---------------------------------------------------+
Multicore Scaling Strategy
^^^^^^^^^^^^^^^^^^^^^^^^^^
The only other work available is to execute different stages of the enqueue sequence of operations on other input packets,
thus resulting in a pipelined implementation for the enqueue operation.
-Figure 25 illustrates a pipelined implementation for the enqueue operation with 4 pipeline stages and each stage executing 2 different input packets.
+:numref:`figure_prefetch_pipeline` illustrates a pipelined implementation for the enqueue operation with 4 pipeline stages and each stage executing 2 different input packets.
No input packet can be part of more than one pipeline stage at a given time.
-.. _pg_figure_25:
+.. _figure_prefetch_pipeline:
-**Figure 25. Prefetch Pipeline for the Hierarchical Scheduler Enqueue Operation**
+.. figure:: img/prefetch_pipeline.*
-.. image51 has been renamed
+ Prefetch Pipeline for the Hierarchical Scheduler Enqueue Operation
-|prefetch_pipeline|
The congestion management scheme implemented by the enqueue pipeline described above is very basic:
packets are enqueued until a specific queue becomes full,
therefore it tries to send as many packets from the same pipe TC and pipe as possible (up to the available packets and credits) before
moving to the next active TC from the same pipe (if any) or to another active pipe.
-.. _pg_figure_26:
+.. _figure_pipe_prefetch_sm:
-**Figure 26. Pipe Prefetch State Machine for the Hierarchical Scheduler Dequeue Operation**
+.. figure:: img/pipe_prefetch_sm.*
-.. image52 has been renamed
+ Pipe Prefetch State Machine for the Hierarchical Scheduler Dequeue
+ Operation
-|pipe_prefetch_sm|
Timing and Synchronization
^^^^^^^^^^^^^^^^^^^^^^^^^^
The number of credits required for the transmission of a packet of n bytes is equal to (n+h),
where h is equal to the number of framing overhead bytes per packet.
-.. _pg_table_5:
-
-**Table 5. Ethernet Frame Overhead Fields**
-
-+---+--------------------------------+----------------+---------------------------------------------------------------------------+
-| # | Packet field | Length (bytes) | Comments |
-| | | | |
-+===+================================+================+===========================================================================+
-| 1 | Preamble | 7 | |
-| | | | |
-+---+--------------------------------+----------------+---------------------------------------------------------------------------+
-| 2 | Start of Frame Delimiter (SFD) | 1 | |
-| | | | |
-+---+--------------------------------+----------------+---------------------------------------------------------------------------+
-| 3 | Frame Check Sequence (FCS) | 4 | Considered overhead only if not included in the mbuf packet length field. |
-| | | | |
-+---+--------------------------------+----------------+---------------------------------------------------------------------------+
-| 4 | Inter Frame Gap (IFG) | 12 | |
-| | | | |
-+---+--------------------------------+----------------+---------------------------------------------------------------------------+
-| 5 | Total | 24 | |
-| | | | |
-+---+--------------------------------+----------------+---------------------------------------------------------------------------+
+.. _table_qos_5:
+
+.. table:: Ethernet Frame Overhead Fields
+
+ +---+--------------------------------+----------------+---------------------------------------------------------------------------+
+ | # | Packet field | Length (bytes) | Comments |
+ | | | | |
+ +===+================================+================+===========================================================================+
+ | 1 | Preamble | 7 | |
+ | | | | |
+ +---+--------------------------------+----------------+---------------------------------------------------------------------------+
+ | 2 | Start of Frame Delimiter (SFD) | 1 | |
+ | | | | |
+ +---+--------------------------------+----------------+---------------------------------------------------------------------------+
+ | 3 | Frame Check Sequence (FCS) | 4 | Considered overhead only if not included in the mbuf packet length field. |
+ | | | | |
+ +---+--------------------------------+----------------+---------------------------------------------------------------------------+
+ | 4 | Inter Frame Gap (IFG) | 12 | |
+ | | | | |
+ +---+--------------------------------+----------------+---------------------------------------------------------------------------+
+ | 5 | Total | 24 | |
+ | | | | |
+ +---+--------------------------------+----------------+---------------------------------------------------------------------------+
Traffic Shaping
"""""""""""""""
The traffic shaping for subport and pipe is implemented using a token bucket per subport/per pipe.
Each token bucket is implemented using one saturated counter that keeps track of the number of available credits.
-The token bucket generic parameters and operations are presented in Table 6 and Table 7.
-
-.. _pg_table_6:
-
-**Table 6. Token Bucket Generic Operations**
-
-+---+------------------------+--------------------+---------------------------------------------------------+
-| # | Token Bucket Parameter | Unit | Description |
-| | | | |
-+===+========================+====================+=========================================================+
-| 1 | bucket_rate | Credits per second | Rate of adding credits to the bucket. |
-| | | | |
-+---+------------------------+--------------------+---------------------------------------------------------+
-| 2 | bucket_size | Credits | Max number of credits that can be stored in the bucket. |
-| | | | |
-+---+------------------------+--------------------+---------------------------------------------------------+
-
-.. _pg_table_7:
-
-**Table 7. Token Bucket Generic Parameters**
-
-+---+------------------------+------------------------------------------------------------------------------+
-| # | Token Bucket Operation | Description |
-| | | |
-+===+========================+==============================================================================+
-| 1 | Initialization | Bucket set to a predefined value, e.g. zero or half of the bucket size. |
-| | | |
-+---+------------------------+------------------------------------------------------------------------------+
-| 2 | Credit update | Credits are added to the bucket on top of existing ones, either periodically |
-| | | or on demand, based on the bucket_rate. Credits cannot exceed the upper |
-| | | limit defined by the bucket_size, so any credits to be added to the bucket |
-| | | while the bucket is full are dropped. |
-| | | |
-+---+------------------------+------------------------------------------------------------------------------+
-| 3 | Credit consumption | As result of packet scheduling, the necessary number of credits is removed |
-| | | from the bucket. The packet can only be sent if enough credits are in the |
-| | | bucket to send the full packet (packet bytes and framing overhead for the |
-| | | packet). |
-| | | |
-+---+------------------------+------------------------------------------------------------------------------+
+The token bucket generic parameters and operations are presented in :numref:`table_qos_6` and :numref:`table_qos_7`.
+
+.. _table_qos_6:
+
+.. table:: Token Bucket Generic Operations
+
+ +---+------------------------+--------------------+---------------------------------------------------------+
+ | # | Token Bucket Parameter | Unit | Description |
+ | | | | |
+ +===+========================+====================+=========================================================+
+ | 1 | bucket_rate | Credits per second | Rate of adding credits to the bucket. |
+ | | | | |
+ +---+------------------------+--------------------+---------------------------------------------------------+
+ | 2 | bucket_size | Credits | Max number of credits that can be stored in the bucket. |
+ | | | | |
+ +---+------------------------+--------------------+---------------------------------------------------------+
+
+.. _table_qos_7:
+
+.. table:: Token Bucket Generic Parameters
+
+ +---+------------------------+------------------------------------------------------------------------------+
+ | # | Token Bucket Operation | Description |
+ | | | |
+ +===+========================+==============================================================================+
+ | 1 | Initialization | Bucket set to a predefined value, e.g. zero or half of the bucket size. |
+ | | | |
+ +---+------------------------+------------------------------------------------------------------------------+
+ | 2 | Credit update | Credits are added to the bucket on top of existing ones, either periodically |
+ | | | or on demand, based on the bucket_rate. Credits cannot exceed the upper |
+ | | | limit defined by the bucket_size, so any credits to be added to the bucket |
+ | | | while the bucket is full are dropped. |
+ | | | |
+ +---+------------------------+------------------------------------------------------------------------------+
+ | 3 | Credit consumption | As result of packet scheduling, the necessary number of credits is removed |
+ | | | from the bucket. The packet can only be sent if enough credits are in the |
+ | | | bucket to send the full packet (packet bytes and framing overhead for the |
+ | | | packet). |
+ | | | |
+ +---+------------------------+------------------------------------------------------------------------------+
To implement the token bucket generic operations described above,
-the current design uses the persistent data structure presented in,
-while the implementation of the token bucket operations is described in Table 9.
-
-.. _pg_table_8:
-
-**Table 8. Token Bucket Persistent Data Structure**
-
-+---+------------------------+-------+----------------------------------------------------------------------+
-| # | Token bucket field | Unit | Description |
-| | | | |
-+===+========================+=======+======================================================================+
-| 1 | tb_time | Bytes | Time of the last credit update. Measured in bytes instead of seconds |
-| | | | or CPU cycles for ease of credit consumption operation |
-| | | | (as the current time is also maintained in bytes). |
-| | | | |
-| | | | See Section 26.2.4.5.1 "Internal Time Reference" for an |
-| | | | explanation of why the time is maintained in byte units. |
-| | | | |
-+---+------------------------+-------+----------------------------------------------------------------------+
-| 2 | tb_period | Bytes | Time period that should elapse since the last credit update in order |
-| | | | for the bucket to be awarded tb_credits_per_period worth or credits. |
-| | | | |
-+---+------------------------+-------+----------------------------------------------------------------------+
-| 3 | tb_credits_per_period | Bytes | Credit allowance per tb_period. |
-| | | | |
-+---+------------------------+-------+----------------------------------------------------------------------+
-| 4 | tb_size | Bytes | Bucket size, i.e. upper limit for the tb_credits. |
-| | | | |
-+---+------------------------+-------+----------------------------------------------------------------------+
-| 5 | tb_credits | Bytes | Number of credits currently in the bucket. |
-| | | | |
-+---+------------------------+-------+----------------------------------------------------------------------+
+the current design uses the persistent data structure presented in :numref:`table_qos_8`,
+while the implementation of the token bucket operations is described in :numref:`table_qos_9`.
+
+.. _table_qos_8:
+
+.. table:: Token Bucket Persistent Data Structure
+
+ +---+------------------------+-------+----------------------------------------------------------------------+
+ | # | Token bucket field | Unit | Description |
+ | | | | |
+ +===+========================+=======+======================================================================+
+ | 1 | tb_time | Bytes | Time of the last credit update. Measured in bytes instead of seconds |
+ | | | | or CPU cycles for ease of credit consumption operation |
+ | | | | (as the current time is also maintained in bytes). |
+ | | | | |
+ | | | | See Section 26.2.4.5.1 "Internal Time Reference" for an |
+ | | | | explanation of why the time is maintained in byte units. |
+ | | | | |
+ +---+------------------------+-------+----------------------------------------------------------------------+
+ | 2 | tb_period | Bytes | Time period that should elapse since the last credit update in order |
+ | | | | for the bucket to be awarded tb_credits_per_period worth or credits. |
+ | | | | |
+ +---+------------------------+-------+----------------------------------------------------------------------+
+ | 3 | tb_credits_per_period | Bytes | Credit allowance per tb_period. |
+ | | | | |
+ +---+------------------------+-------+----------------------------------------------------------------------+
+ | 4 | tb_size | Bytes | Bucket size, i.e. upper limit for the tb_credits. |
+ | | | | |
+ +---+------------------------+-------+----------------------------------------------------------------------+
+ | 5 | tb_credits | Bytes | Number of credits currently in the bucket. |
+ | | | | |
+ +---+------------------------+-------+----------------------------------------------------------------------+
The bucket rate (in bytes per second) can be computed with the following formula:
where, r = port line rate (in bytes per second).
-.. _pg_table_9:
-
-**Table 9. Token Bucket Operations**
-
-+---+-------------------------+-----------------------------------------------------------------------------+
-| # | Token bucket operation | Description |
-| | | |
-+===+=========================+=============================================================================+
-| 1 | Initialization | *tb_credits = 0; or tb_credits = tb_size / 2;* |
-| | | |
-+---+-------------------------+-----------------------------------------------------------------------------+
-| 2 | Credit update | Credit update options: |
-| | | |
-| | | * Every time a packet is sent for a port, update the credits of all the |
-| | | the subports and pipes of that port. Not feasible. |
-| | | |
-| | | * Every time a packet is sent, update the credits for the pipe and |
-| | | subport. Very accurate, but not needed (a lot of calculations). |
-| | | |
-| | | * Every time a pipe is selected (that is, picked by one |
-| | | of the grinders), update the credits for the pipe and its subport. |
-| | | |
-| | | The current implementation is using option 3. According to Section |
-| | | 26.2.4.4 "Dequeue State Machine", the pipe and subport credits are |
-| | | updated every time a pipe is selected by the dequeue process before the |
-| | | pipe and subport credits are actually used. |
-| | | |
-| | | The implementation uses a tradeoff between accuracy and speed by updating |
-| | | the bucket credits only when at least a full *tb_period* has elapsed since |
-| | | the last update. |
-| | | |
-| | | * Full accuracy can be achieved by selecting the value for *tb_period* |
-| | | for which *tb_credits_per_period = 1*. |
-| | | |
-| | | * When full accuracy is not required, better performance is achieved by |
-| | | setting *tb_credits* to a larger value. |
-| | | |
-| | | Update operations: |
-| | | |
-| | | * n_periods = (time - tb_time) / tb_period; |
-| | | |
-| | | * tb_credits += n_periods * tb_credits_per_period; |
-| | | |
-| | | * tb_credits = min(tb_credits, tb_size); |
-| | | |
-| | | * tb_time += n_periods * tb_period; |
-| | | |
-+---+-------------------------+-----------------------------------------------------------------------------+
-| 3 | Credit consumption | As result of packet scheduling, the necessary number of credits is removed |
-| | (on packet scheduling) | from the bucket. The packet can only be sent if enough credits are in the |
-| | | bucket to send the full packet (packet bytes and framing overhead for the |
-| | | packet). |
-| | | |
-| | | Scheduling operations: |
-| | | |
-| | | pkt_credits = pkt_len + frame_overhead; |
-| | | if (tb_credits >= pkt_credits){tb_credits -= pkt_credits;} |
-| | | |
-+---+-------------------------+-----------------------------------------------------------------------------+
+.. _table_qos_9:
+
+.. table:: Token Bucket Operations
+
+ +---+-------------------------+-----------------------------------------------------------------------------+
+ | # | Token bucket operation | Description |
+ | | | |
+ +===+=========================+=============================================================================+
+ | 1 | Initialization | *tb_credits = 0; or tb_credits = tb_size / 2;* |
+ | | | |
+ +---+-------------------------+-----------------------------------------------------------------------------+
+ | 2 | Credit update | Credit update options: |
+ | | | |
+ | | | * Every time a packet is sent for a port, update the credits of all the |
+ | | | the subports and pipes of that port. Not feasible. |
+ | | | |
+ | | | * Every time a packet is sent, update the credits for the pipe and |
+ | | | subport. Very accurate, but not needed (a lot of calculations). |
+ | | | |
+ | | | * Every time a pipe is selected (that is, picked by one |
+ | | | of the grinders), update the credits for the pipe and its subport. |
+ | | | |
+ | | | The current implementation is using option 3. According to Section |
+ | | | `Dequeue State Machine`_, the pipe and subport credits are |
+ | | | updated every time a pipe is selected by the dequeue process before the |
+ | | | pipe and subport credits are actually used. |
+ | | | |
+ | | | The implementation uses a tradeoff between accuracy and speed by updating |
+ | | | the bucket credits only when at least a full *tb_period* has elapsed since |
+ | | | the last update. |
+ | | | |
+ | | | * Full accuracy can be achieved by selecting the value for *tb_period* |
+ | | | for which *tb_credits_per_period = 1*. |
+ | | | |
+ | | | * When full accuracy is not required, better performance is achieved by |
+ | | | setting *tb_credits* to a larger value. |
+ | | | |
+ | | | Update operations: |
+ | | | |
+ | | | * n_periods = (time - tb_time) / tb_period; |
+ | | | |
+ | | | * tb_credits += n_periods * tb_credits_per_period; |
+ | | | |
+ | | | * tb_credits = min(tb_credits, tb_size); |
+ | | | |
+ | | | * tb_time += n_periods * tb_period; |
+ | | | |
+ +---+-------------------------+-----------------------------------------------------------------------------+
+ | 3 | Credit consumption | As result of packet scheduling, the necessary number of credits is removed |
+ | | (on packet scheduling) | from the bucket. The packet can only be sent if enough credits are in the |
+ | | | bucket to send the full packet (packet bytes and framing overhead for the |
+ | | | packet). |
+ | | | |
+ | | | Scheduling operations: |
+ | | | |
+ | | | pkt_credits = pkt_len + frame_overhead; |
+ | | | if (tb_credits >= pkt_credits){tb_credits -= pkt_credits;} |
+ | | | |
+ +---+-------------------------+-----------------------------------------------------------------------------+
Traffic Classes
"""""""""""""""
The upper limit for the traffic classes at the subport and
pipe levels is enforced by periodically refilling the subport / pipe traffic class credit counter,
out of which credits are consumed every time a packet is scheduled for that subport / pipe,
-as described in Table 10 and Table 11.
-
-.. _pg_table_10:
-
-**Table 10. Subport/Pipe Traffic Class Upper Limit Enforcement Persistent Data Structure**
-
-+---+-----------------------+-------+-----------------------------------------------------------------------+
-| # | Subport or pipe field | Unit | Description |
-| | | | |
-+===+=======================+=======+=======================================================================+
-| 1 | tc_time | Bytes | Time of the next update (upper limit refill) for the 4 TCs of the |
-| | | | current subport / pipe. |
-| | | | |
-| | | | See Section 26.2.4.5.1, "Internal Time Reference" for the |
-| | | | explanation of why the time is maintained in byte units. |
-| | | | |
-+---+-----------------------+-------+-----------------------------------------------------------------------+
-| 2 | tc_period | Bytes | Time between two consecutive updates for the 4 TCs of the current |
-| | | | subport / pipe. This is expected to be many times bigger than the |
-| | | | typical value of the token bucket tb_period. |
-| | | | |
-+---+-----------------------+-------+-----------------------------------------------------------------------+
-| 3 | tc_credits_per_period | Bytes | Upper limit for the number of credits allowed to be consumed by the |
-| | | | current TC during each enforcement period tc_period. |
-| | | | |
-+---+-----------------------+-------+-----------------------------------------------------------------------+
-| 4 | tc_credits | Bytes | Current upper limit for the number of credits that can be consumed by |
-| | | | the current traffic class for the remainder of the current |
-| | | | enforcement period. |
-| | | | |
-+---+-----------------------+-------+-----------------------------------------------------------------------+
-
-.. _pg_table_11:
-
-**Table 11. Subport/Pipe Traffic Class Upper Limit Enforcement Operations**
-
-+---+--------------------------+----------------------------------------------------------------------------+
-| # | Traffic Class Operation | Description |
-| | | |
-+===+==========================+============================================================================+
-| 1 | Initialization | tc_credits = tc_credits_per_period; |
-| | | |
-| | | tc_time = tc_period; |
-| | | |
-+---+--------------------------+----------------------------------------------------------------------------+
-| 2 | Credit update | Update operations: |
-| | | |
-| | | if (time >= tc_time) { |
-| | | |
-| | | tc_credits = tc_credits_per_period; |
-| | | |
-| | | tc_time = time + tc_period; |
-| | | |
-| | | } |
-| | | |
-+---+--------------------------+----------------------------------------------------------------------------+
-| 3 | Credit consumption | As result of packet scheduling, the TC limit is decreased with the |
-| | (on packet scheduling) | necessary number of credits. The packet can only be sent if enough credits |
-| | | are currently available in the TC limit to send the full packet |
-| | | (packet bytes and framing overhead for the packet). |
-| | | |
-| | | Scheduling operations: |
-| | | |
-| | | pkt_credits = pk_len + frame_overhead; |
-| | | |
-| | | if (tc_credits >= pkt_credits) {tc_credits -= pkt_credits;} |
-| | | |
-+---+--------------------------+----------------------------------------------------------------------------+
+as described in :numref:`table_qos_10` and :numref:`table_qos_11`.
+
+.. _table_qos_10:
+
+.. table:: Subport/Pipe Traffic Class Upper Limit Enforcement Persistent Data Structure
+
+ +---+-----------------------+-------+-----------------------------------------------------------------------+
+ | # | Subport or pipe field | Unit | Description |
+ | | | | |
+ +===+=======================+=======+=======================================================================+
+ | 1 | tc_time | Bytes | Time of the next update (upper limit refill) for the 4 TCs of the |
+ | | | | current subport / pipe. |
+ | | | | |
+ | | | | See Section `Internal Time Reference`_ for the |
+ | | | | explanation of why the time is maintained in byte units. |
+ | | | | |
+ +---+-----------------------+-------+-----------------------------------------------------------------------+
+ | 2 | tc_period | Bytes | Time between two consecutive updates for the 4 TCs of the current |
+ | | | | subport / pipe. This is expected to be many times bigger than the |
+ | | | | typical value of the token bucket tb_period. |
+ | | | | |
+ +---+-----------------------+-------+-----------------------------------------------------------------------+
+ | 3 | tc_credits_per_period | Bytes | Upper limit for the number of credits allowed to be consumed by the |
+ | | | | current TC during each enforcement period tc_period. |
+ | | | | |
+ +---+-----------------------+-------+-----------------------------------------------------------------------+
+ | 4 | tc_credits | Bytes | Current upper limit for the number of credits that can be consumed by |
+ | | | | the current traffic class for the remainder of the current |
+ | | | | enforcement period. |
+ | | | | |
+ +---+-----------------------+-------+-----------------------------------------------------------------------+
+
+.. _table_qos_11:
+
+.. table:: Subport/Pipe Traffic Class Upper Limit Enforcement Operations
+
+ +---+--------------------------+----------------------------------------------------------------------------+
+ | # | Traffic Class Operation | Description |
+ | | | |
+ +===+==========================+============================================================================+
+ | 1 | Initialization | tc_credits = tc_credits_per_period; |
+ | | | |
+ | | | tc_time = tc_period; |
+ | | | |
+ +---+--------------------------+----------------------------------------------------------------------------+
+ | 2 | Credit update | Update operations: |
+ | | | |
+ | | | if (time >= tc_time) { |
+ | | | |
+ | | | tc_credits = tc_credits_per_period; |
+ | | | |
+ | | | tc_time = time + tc_period; |
+ | | | |
+ | | | } |
+ | | | |
+ +---+--------------------------+----------------------------------------------------------------------------+
+ | 3 | Credit consumption | As result of packet scheduling, the TC limit is decreased with the |
+ | | (on packet scheduling) | necessary number of credits. The packet can only be sent if enough credits |
+ | | | are currently available in the TC limit to send the full packet |
+ | | | (packet bytes and framing overhead for the packet). |
+ | | | |
+ | | | Scheduling operations: |
+ | | | |
+ | | | pkt_credits = pk_len + frame_overhead; |
+ | | | |
+ | | | if (tc_credits >= pkt_credits) {tc_credits -= pkt_credits;} |
+ | | | |
+ +---+--------------------------+----------------------------------------------------------------------------+
Weighted Round Robin (WRR)
""""""""""""""""""""""""""
-The evolution of the WRR design solution from simple to complex is shown in Table 12.
-
-.. _pg_table_12:
-
-**Table 12. Weighted Round Robin (WRR)**
-
-+---+------------+-----------------+-------------+----------------------------------------------------------+
-| # | All Queues | Equal Weights | All Packets | Strategy |
-| | Active? | for All Queues? | Equal? | |
-+===+============+=================+=============+==========================================================+
-| 1 | Yes | Yes | Yes | **Byte level round robin** |
-| | | | | |
-| | | | | *Next queue* queue #i, i = *(i + 1) % n* |
-| | | | | |
-+---+------------+-----------------+-------------+----------------------------------------------------------+
-| 2 | Yes | Yes | No | **Packet level round robin** |
-| | | | | |
-| | | | | Consuming one byte from queue #i requires consuming |
-| | | | | exactly one token for queue #i. |
-| | | | | |
-| | | | | T(i) = Accumulated number of tokens previously consumed |
-| | | | | from queue #i. Every time a packet is consumed from |
-| | | | | queue #i, T(i) is updated as: T(i) += *pkt_len*. |
-| | | | | |
-| | | | | *Next queue* : queue with the smallest T. |
-| | | | | |
-| | | | | |
-+---+------------+-----------------+-------------+----------------------------------------------------------+
-| 3 | Yes | No | No | **Packet level weighted round robin** |
-| | | | | |
-| | | | | This case can be reduced to the previous case by |
-| | | | | introducing a cost per byte that is different for each |
-| | | | | queue. Queues with lower weights have a higher cost per |
-| | | | | byte. This way, it is still meaningful to compare the |
-| | | | | consumption amongst different queues in order to select |
-| | | | | the next queue. |
-| | | | | |
-| | | | | w(i) = Weight of queue #i |
-| | | | | |
-| | | | | t(i) = Tokens per byte for queue #i, defined as the |
-| | | | | inverse weight of queue #i. |
-| | | | | For example, if w[0..3] = [1:2:4:8], |
-| | | | | then t[0..3] = [8:4:2:1]; if w[0..3] = [1:4:15:20], |
-| | | | | then t[0..3] = [60:15:4:3]. |
-| | | | | Consuming one byte from queue #i requires consuming t(i) |
-| | | | | tokens for queue #i. |
-| | | | | |
-| | | | | T(i) = Accumulated number of tokens previously consumed |
-| | | | | from queue #i. Every time a packet is consumed from |
-| | | | | queue #i, T(i) is updated as: *T(i) += pkt_len * t(i)*. |
-| | | | | *Next queue* : queue with the smallest T. |
-| | | | | |
-+---+------------+-----------------+-------------+----------------------------------------------------------+
-| 4 | No | No | No | **Packet level weighted round robin with variable queue |
-| | | | | status** |
-| | | | | |
-| | | | | Reduce this case to the previous case by setting the |
-| | | | | consumption of inactive queues to a high number, so that |
-| | | | | the inactive queues will never be selected by the |
-| | | | | smallest T logic. |
-| | | | | |
-| | | | | To prevent T from overflowing as result of successive |
-| | | | | accumulations, T(i) is truncated after each packet |
-| | | | | consumption for all queues. |
-| | | | | For example, T[0..3] = [1000, 1100, 1200, 1300] |
-| | | | | is truncated to T[0..3] = [0, 100, 200, 300] |
-| | | | | by subtracting the min T from T(i), i = 0..n. |
-| | | | | |
-| | | | | This requires having at least one active queue in the |
-| | | | | set of input queues, which is guaranteed by the dequeue |
-| | | | | state machine never selecting an inactive traffic class. |
-| | | | | |
-| | | | | *mask(i) = Saturation mask for queue #i, defined as:* |
-| | | | | |
-| | | | | mask(i) = (queue #i is active)? 0 : 0xFFFFFFFF; |
-| | | | | |
-| | | | | w(i) = Weight of queue #i |
-| | | | | |
-| | | | | t(i) = Tokens per byte for queue #i, defined as the |
-| | | | | inverse weight of queue #i. |
-| | | | | |
-| | | | | T(i) = Accumulated numbers of tokens previously consumed |
-| | | | | from queue #i. |
-| | | | | |
-| | | | | *Next queue* : queue with smallest T. |
-| | | | | |
-| | | | | Before packet consumption from queue #i: |
-| | | | | |
-| | | | | *T(i) |= mask(i)* |
-| | | | | |
-| | | | | After packet consumption from queue #i: |
-| | | | | |
-| | | | | T(j) -= T(i), j != i |
-| | | | | |
-| | | | | T(i) = pkt_len * t(i) |
-| | | | | |
-| | | | | Note: T(j) uses the T(i) value before T(i) is updated. |
-| | | | | |
-+---+------------+-----------------+-------------+----------------------------------------------------------+
+The evolution of the WRR design solution from simple to complex is shown in :numref:`table_qos_12`.
+
+.. _table_qos_12:
+
+.. table:: Weighted Round Robin (WRR)
+
+ +---+------------+-----------------+-------------+----------------------------------------------------------+
+ | # | All Queues | Equal Weights | All Packets | Strategy |
+ | | Active? | for All Queues? | Equal? | |
+ +===+============+=================+=============+==========================================================+
+ | 1 | Yes | Yes | Yes | **Byte level round robin** |
+ | | | | | |
+ | | | | | *Next queue* queue #i, i = *(i + 1) % n* |
+ | | | | | |
+ +---+------------+-----------------+-------------+----------------------------------------------------------+
+ | 2 | Yes | Yes | No | **Packet level round robin** |
+ | | | | | |
+ | | | | | Consuming one byte from queue #i requires consuming |
+ | | | | | exactly one token for queue #i. |
+ | | | | | |
+ | | | | | T(i) = Accumulated number of tokens previously consumed |
+ | | | | | from queue #i. Every time a packet is consumed from |
+ | | | | | queue #i, T(i) is updated as: T(i) += *pkt_len*. |
+ | | | | | |
+ | | | | | *Next queue* : queue with the smallest T. |
+ | | | | | |
+ | | | | | |
+ +---+------------+-----------------+-------------+----------------------------------------------------------+
+ | 3 | Yes | No | No | **Packet level weighted round robin** |
+ | | | | | |
+ | | | | | This case can be reduced to the previous case by |
+ | | | | | introducing a cost per byte that is different for each |
+ | | | | | queue. Queues with lower weights have a higher cost per |
+ | | | | | byte. This way, it is still meaningful to compare the |
+ | | | | | consumption amongst different queues in order to select |
+ | | | | | the next queue. |
+ | | | | | |
+ | | | | | w(i) = Weight of queue #i |
+ | | | | | |
+ | | | | | t(i) = Tokens per byte for queue #i, defined as the |
+ | | | | | inverse weight of queue #i. |
+ | | | | | For example, if w[0..3] = [1:2:4:8], |
+ | | | | | then t[0..3] = [8:4:2:1]; if w[0..3] = [1:4:15:20], |
+ | | | | | then t[0..3] = [60:15:4:3]. |
+ | | | | | Consuming one byte from queue #i requires consuming t(i) |
+ | | | | | tokens for queue #i. |
+ | | | | | |
+ | | | | | T(i) = Accumulated number of tokens previously consumed |
+ | | | | | from queue #i. Every time a packet is consumed from |
+ | | | | | queue #i, T(i) is updated as: *T(i) += pkt_len * t(i)*. |
+ | | | | | *Next queue* : queue with the smallest T. |
+ | | | | | |
+ +---+------------+-----------------+-------------+----------------------------------------------------------+
+ | 4 | No | No | No | **Packet level weighted round robin with variable queue |
+ | | | | | status** |
+ | | | | | |
+ | | | | | Reduce this case to the previous case by setting the |
+ | | | | | consumption of inactive queues to a high number, so that |
+ | | | | | the inactive queues will never be selected by the |
+ | | | | | smallest T logic. |
+ | | | | | |
+ | | | | | To prevent T from overflowing as result of successive |
+ | | | | | accumulations, T(i) is truncated after each packet |
+ | | | | | consumption for all queues. |
+ | | | | | For example, T[0..3] = [1000, 1100, 1200, 1300] |
+ | | | | | is truncated to T[0..3] = [0, 100, 200, 300] |
+ | | | | | by subtracting the min T from T(i), i = 0..n. |
+ | | | | | |
+ | | | | | This requires having at least one active queue in the |
+ | | | | | set of input queues, which is guaranteed by the dequeue |
+ | | | | | state machine never selecting an inactive traffic class. |
+ | | | | | |
+ | | | | | *mask(i) = Saturation mask for queue #i, defined as:* |
+ | | | | | |
+ | | | | | mask(i) = (queue #i is active)? 0 : 0xFFFFFFFF; |
+ | | | | | |
+ | | | | | w(i) = Weight of queue #i |
+ | | | | | |
+ | | | | | t(i) = Tokens per byte for queue #i, defined as the |
+ | | | | | inverse weight of queue #i. |
+ | | | | | |
+ | | | | | T(i) = Accumulated numbers of tokens previously consumed |
+ | | | | | from queue #i. |
+ | | | | | |
+ | | | | | *Next queue* : queue with smallest T. |
+ | | | | | |
+ | | | | | Before packet consumption from queue #i: |
+ | | | | | |
+ | | | | | *T(i) |= mask(i)* |
+ | | | | | |
+ | | | | | After packet consumption from queue #i: |
+ | | | | | |
+ | | | | | T(j) -= T(i), j != i |
+ | | | | | |
+ | | | | | T(i) = pkt_len * t(i) |
+ | | | | | |
+ | | | | | Note: T(j) uses the T(i) value before T(i) is updated. |
+ | | | | | |
+ +---+------------+-----------------+-------------+----------------------------------------------------------+
Subport Traffic Class Oversubscription
""""""""""""""""""""""""""""""""""""""
summarizes some of the possible approaches for handling this problem,
with the third approach selected for implementation.
-.. _pg_table_13:
-
-**Table 13. Subport Traffic Class Oversubscription**
-
-+-----+---------------------------+-------------------------------------------------------------------------+
-| No. | Approach | Description |
-| | | |
-+=====+===========================+=========================================================================+
-| 1 | Don't care | First come, first served. |
-| | | |
-| | | This approach is not fair amongst subport member pipes, as pipes that |
-| | | are served first will use up as much bandwidth for TC X as they need, |
-| | | while pipes that are served later will receive poor service due to |
-| | | bandwidth for TC X at the subport level being scarce. |
-| | | |
-+-----+---------------------------+-------------------------------------------------------------------------+
-| 2 | Scale down all pipes | All pipes within the subport have their bandwidth limit for TC X scaled |
-| | | down by the same factor. |
-| | | |
-| | | This approach is not fair among subport member pipes, as the low end |
-| | | pipes (that is, pipes configured with low bandwidth) can potentially |
-| | | experience severe service degradation that might render their service |
-| | | unusable (if available bandwidth for these pipes drops below the |
-| | | minimum requirements for a workable service), while the service |
-| | | degradation for high end pipes might not be noticeable at all. |
-| | | |
-+-----+---------------------------+-------------------------------------------------------------------------+
-| 3 | Cap the high demand pipes | Each subport member pipe receives an equal share of the bandwidth |
-| | | available at run-time for TC X at the subport level. Any bandwidth left |
-| | | unused by the low-demand pipes is redistributed in equal portions to |
-| | | the high-demand pipes. This way, the high-demand pipes are truncated |
-| | | while the low-demand pipes are not impacted. |
-| | | |
-+-----+---------------------------+-------------------------------------------------------------------------+
+.. _table_qos_13:
+
+.. table:: Subport Traffic Class Oversubscription
+
+ +-----+---------------------------+-------------------------------------------------------------------------+
+ | No. | Approach | Description |
+ | | | |
+ +=====+===========================+=========================================================================+
+ | 1 | Don't care | First come, first served. |
+ | | | |
+ | | | This approach is not fair amongst subport member pipes, as pipes that |
+ | | | are served first will use up as much bandwidth for TC X as they need, |
+ | | | while pipes that are served later will receive poor service due to |
+ | | | bandwidth for TC X at the subport level being scarce. |
+ | | | |
+ +-----+---------------------------+-------------------------------------------------------------------------+
+ | 2 | Scale down all pipes | All pipes within the subport have their bandwidth limit for TC X scaled |
+ | | | down by the same factor. |
+ | | | |
+ | | | This approach is not fair among subport member pipes, as the low end |
+ | | | pipes (that is, pipes configured with low bandwidth) can potentially |
+ | | | experience severe service degradation that might render their service |
+ | | | unusable (if available bandwidth for these pipes drops below the |
+ | | | minimum requirements for a workable service), while the service |
+ | | | degradation for high end pipes might not be noticeable at all. |
+ | | | |
+ +-----+---------------------------+-------------------------------------------------------------------------+
+ | 3 | Cap the high demand pipes | Each subport member pipe receives an equal share of the bandwidth |
+ | | | available at run-time for TC X at the subport level. Any bandwidth left |
+ | | | unused by the low-demand pipes is redistributed in equal portions to |
+ | | | the high-demand pipes. This way, the high-demand pipes are truncated |
+ | | | while the low-demand pipes are not impacted. |
+ | | | |
+ +-----+---------------------------+-------------------------------------------------------------------------+
Typically, the subport TC oversubscription feature is enabled only for the lowest priority traffic class (TC 3),
which is typically used for best effort traffic,
When demand is low, the watermark is set high to prevent it from impeding the subport member pipes from consuming more bandwidth.
The highest value for the watermark is picked as the highest rate configured for a subport member pipe.
-Table 15 illustrates the watermark operation.
-
-.. _pg_table_14:
-
-**Table 14. Watermark Propagation from Subport Level to Member Pipes at the Beginning of Each Traffic Class Upper Limit Enforcement Period**
-
-+-----+---------------------------------+----------------------------------------------------+
-| No. | Subport Traffic Class Operation | Description |
-| | | |
-+=====+=================================+====================================================+
-| 1 | Initialization | **Subport level**: subport_period_id= 0 |
-| | | |
-| | | **Pipe level**: pipe_period_id = 0 |
-| | | |
-+-----+---------------------------------+----------------------------------------------------+
-| 2 | Credit update | **Subport Level**: |
-| | | |
-| | | if (time>=subport_tc_time) |
-| | | |
-| | | { |
-| | | subport_wm = water_mark_update(); |
-| | | |
-| | | subport_tc_time = time + subport_tc_period; |
-| | | |
-| | | subport_period_id++; |
-| | | |
-| | | } |
-| | | |
-| | | **Pipelevel:** |
-| | | |
-| | | if(pipe_period_id != subport_period_id) |
-| | | |
-| | | { |
-| | | |
-| | | pipe_ov_credits = subport_wm \* pipe_weight; |
-| | | |
-| | | pipe_period_id = subport_period_id; |
-| | | |
-| | | } |
-| | | |
-+-----+---------------------------------+----------------------------------------------------+
-| 3 | Credit consumption | **Pipe level:** |
-| | (on packet scheduling) | |
-| | | pkt_credits = pk_len + frame_overhead; |
-| | | |
-| | | if(pipe_ov_credits >= pkt_credits{ |
-| | | |
-| | | pipe_ov_credits -= pkt_credits; |
-| | | |
-| | | } |
-| | | |
-+-----+---------------------------------+----------------------------------------------------+
-
-.. _pg_table_15:
-
-**Table 15. Watermark Calculation**
-
-+-----+------------------+----------------------------------------------------------------------------------+
-| No. | Subport Traffic | Description |
-| | Class Operation | |
-+=====+==================+==================================================================================+
-| 1 | Initialization | **Subport level:** |
-| | | |
-| | | wm = WM_MAX |
-| | | |
-+-----+------------------+----------------------------------------------------------------------------------+
-| 2 | Credit update | **Subport level (water_mark_update):** |
-| | | |
-| | | tc0_cons = subport_tc0_credits_per_period - subport_tc0_credits; |
-| | | |
-| | | tc1_cons = subport_tc1_credits_per_period - subport_tc1_credits; |
-| | | |
-| | | tc2_cons = subport_tc2_credits_per_period - subport_tc2_credits; |
-| | | |
-| | | tc3_cons = subport_tc3_credits_per_period - subport_tc3_credits; |
-| | | |
-| | | tc3_cons_max = subport_tc3_credits_per_period - (tc0_cons + tc1_cons + |
-| | | tc2_cons); |
-| | | |
-| | | if(tc3_consumption > (tc3_consumption_max - MTU)){ |
-| | | |
-| | | wm -= wm >> 7; |
-| | | |
-| | | if(wm < WM_MIN) wm = WM_MIN; |
-| | | |
-| | | } else { |
-| | | |
-| | | wm += (wm >> 7) + 1; |
-| | | |
-| | | if(wm > WM_MAX) wm = WM_MAX; |
-| | | |
-| | | } |
-| | | |
-+-----+------------------+----------------------------------------------------------------------------------+
+:numref:`table_qos_14` and :numref:`table_qos_15` illustrates the watermark operation.
+
+.. _table_qos_14:
+
+.. table:: Watermark Propagation from Subport Level to Member Pipes at the Beginning of Each Traffic Class Upper Limit Enforcement Period
+
+ +-----+---------------------------------+----------------------------------------------------+
+ | No. | Subport Traffic Class Operation | Description |
+ | | | |
+ +=====+=================================+====================================================+
+ | 1 | Initialization | **Subport level**: subport_period_id= 0 |
+ | | | |
+ | | | **Pipe level**: pipe_period_id = 0 |
+ | | | |
+ +-----+---------------------------------+----------------------------------------------------+
+ | 2 | Credit update | **Subport Level**: |
+ | | | |
+ | | | if (time>=subport_tc_time) |
+ | | | |
+ | | | { |
+ | | | subport_wm = water_mark_update(); |
+ | | | |
+ | | | subport_tc_time = time + subport_tc_period; |
+ | | | |
+ | | | subport_period_id++; |
+ | | | |
+ | | | } |
+ | | | |
+ | | | **Pipelevel:** |
+ | | | |
+ | | | if(pipe_period_id != subport_period_id) |
+ | | | |
+ | | | { |
+ | | | |
+ | | | pipe_ov_credits = subport_wm \* pipe_weight; |
+ | | | |
+ | | | pipe_period_id = subport_period_id; |
+ | | | |
+ | | | } |
+ | | | |
+ +-----+---------------------------------+----------------------------------------------------+
+ | 3 | Credit consumption | **Pipe level:** |
+ | | (on packet scheduling) | |
+ | | | pkt_credits = pk_len + frame_overhead; |
+ | | | |
+ | | | if(pipe_ov_credits >= pkt_credits{ |
+ | | | |
+ | | | pipe_ov_credits -= pkt_credits; |
+ | | | |
+ | | | } |
+ | | | |
+ +-----+---------------------------------+----------------------------------------------------+
+
+.. _table_qos_15:
+
+.. table:: Watermark Calculation
+
+ +-----+------------------+----------------------------------------------------------------------------------+
+ | No. | Subport Traffic | Description |
+ | | Class Operation | |
+ +=====+==================+==================================================================================+
+ | 1 | Initialization | **Subport level:** |
+ | | | |
+ | | | wm = WM_MAX |
+ | | | |
+ +-----+------------------+----------------------------------------------------------------------------------+
+ | 2 | Credit update | **Subport level (water_mark_update):** |
+ | | | |
+ | | | tc0_cons = subport_tc0_credits_per_period - subport_tc0_credits; |
+ | | | |
+ | | | tc1_cons = subport_tc1_credits_per_period - subport_tc1_credits; |
+ | | | |
+ | | | tc2_cons = subport_tc2_credits_per_period - subport_tc2_credits; |
+ | | | |
+ | | | tc3_cons = subport_tc3_credits_per_period - subport_tc3_credits; |
+ | | | |
+ | | | tc3_cons_max = subport_tc3_credits_per_period - (tc0_cons + tc1_cons + |
+ | | | tc2_cons); |
+ | | | |
+ | | | if(tc3_consumption > (tc3_consumption_max - MTU)){ |
+ | | | |
+ | | | wm -= wm >> 7; |
+ | | | |
+ | | | if(wm < WM_MIN) wm = WM_MIN; |
+ | | | |
+ | | | } else { |
+ | | | |
+ | | | wm += (wm >> 7) + 1; |
+ | | | |
+ | | | if(wm > WM_MAX) wm = WM_MAX; |
+ | | | |
+ | | | } |
+ | | | |
+ +-----+------------------+----------------------------------------------------------------------------------+
Worst Case Scenarios for Performance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dropper
-------
-The purpose of the Intel® DPDK dropper is to drop packets arriving at a packet scheduler to avoid congestion.
+The purpose of the DPDK dropper is to drop packets arriving at a packet scheduler to avoid congestion.
The dropper supports the Random Early Detection (RED),
Weighted Random Early Detection (WRED) and tail drop algorithms.
-Figure 1 illustrates how the dropper integrates with the scheduler.
-The Intel® DPDK currently does not support congestion management
+:numref:`figure_blk_diag_dropper` illustrates how the dropper integrates with the scheduler.
+The DPDK currently does not support congestion management
so the dropper provides the only method for congestion avoidance.
-.. _pg_figure_27:
+.. _figure_blk_diag_dropper:
-**Figure 27. High-level Block Diagram of the Intel® DPDK Dropper**
+.. figure:: img/blk_diag_dropper.*
-.. image53_png has been renamed
+ High-level Block Diagram of the DPDK Dropper
-|blk_diag_dropper|
The dropper uses the Random Early Detection (RED) congestion avoidance algorithm as documented in the reference publication.
The purpose of the RED algorithm is to monitor a packet queue,
This occurs when a packet queue has reached maximum capacity and cannot store any more packets.
In this situation, all arriving packets are dropped.
-The flow through the dropper is illustrated in Figure 28.
+The flow through the dropper is illustrated in :numref:`figure_flow_tru_droppper`.
The RED/WRED algorithm is exercised first and tail drop second.
-.. _pg_figure_28:
+.. _figure_flow_tru_droppper:
-**Figure 28. Flow Through the Dropper**
+.. figure:: img/flow_tru_droppper.*
-.. image54_png has been renamed
+ Flow Through the Dropper
-|flow_tru_droppper|
The use cases supported by the dropper are:
Configuration
~~~~~~~~~~~~~
-A RED configuration contains the parameters given in Table 16.
-
-.. _pg_table_16:
-
-**Table 16. RED Configuration Parameters**
-
-+--------------------------+---------+---------+------------------+
-| Parameter | Minimum | Maximum | Typical |
-| | | | |
-+==========================+=========+=========+==================+
-| Minimum Threshold | 0 | 1022 | 1/4 x queue size |
-| | | | |
-+--------------------------+---------+---------+------------------+
-| Maximum Threshold | 1 | 1023 | 1/2 x queue size |
-| | | | |
-+--------------------------+---------+---------+------------------+
-| Inverse Mark Probability | 1 | 255 | 10 |
-| | | | |
-+--------------------------+---------+---------+------------------+
-| EWMA Filter Weight | 1 | 12 | 9 |
-| | | | |
-+--------------------------+---------+---------+------------------+
+A RED configuration contains the parameters given in :numref:`table_qos_16`.
+
+.. _table_qos_16:
+
+.. table:: RED Configuration Parameters
+
+ +--------------------------+---------+---------+------------------+
+ | Parameter | Minimum | Maximum | Typical |
+ | | | | |
+ +==========================+=========+=========+==================+
+ | Minimum Threshold | 0 | 1022 | 1/4 x queue size |
+ | | | | |
+ +--------------------------+---------+---------+------------------+
+ | Maximum Threshold | 1 | 1023 | 1/2 x queue size |
+ | | | | |
+ +--------------------------+---------+---------+------------------+
+ | Inverse Mark Probability | 1 | 255 | 10 |
+ | | | | |
+ +--------------------------+---------+---------+------------------+
+ | EWMA Filter Weight | 1 | 12 | 9 |
+ | | | | |
+ +--------------------------+---------+---------+------------------+
The meaning of these parameters is explained in more detail in the following sections.
The format of these parameters as specified to the dropper module API
Enqueue Operation
~~~~~~~~~~~~~~~~~
-In the example shown in Figure 29, q (actual queue size) is the input value,
+In the example shown in :numref:`figure_ex_data_flow_tru_dropper`, q (actual queue size) is the input value,
avg (average queue size) and count (number of packets since the last drop) are run-time values,
decision is the output value and the remaining values are configuration parameters.
-.. _pg_figure_29:
+.. _figure_ex_data_flow_tru_dropper:
-**Figure 29. Example Data Flow Through Dropper**
+.. figure:: img/ex_data_flow_tru_dropper.*
-.. image55_png has been renamed
+ Example Data Flow Through Dropper
-|ex_data_flow_tru_dropper|
EWMA Filter Microblock
^^^^^^^^^^^^^^^^^^^^^^
The definition of the EWMA filter is given in the following equation.
-**Equation 1.**
-
-.. image56_png has been renamed
-
-|ewma_filter_eq_1|
+.. image:: img/ewma_filter_eq_1.*
Where:
or remaining stagnant at the last computed value.
When a packet is enqueued on an empty queue, the average queue size is computed using the following formula:
-**Equation 2.**
-
-.. image57_png has been renamed
-
-|ewma_filter_eq_2|
+.. image:: img/ewma_filter_eq_2.*
Where:
In the dropper module, *m* is defined as:
-.. image58_png has been renamed
-
-|m_definition|
+.. image:: img/m_definition.*
Where:
The time reference is in units of bytes,
where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium
-(see Section 26.2.4.5.1 "Internal Time Reference").
+(see Section `Internal Time Reference`_).
The parameter s is defined in the dropper module as a constant with the value: s=2^22.
This corresponds to the time required by every leaf node in a hierarchy with 64K leaf nodes
to transmit one 64-byte packet onto the wire and represents the worst case scenario.
This method is based on the following identity:
-.. image59_png has been renamed
+.. image:: img/eq2_factor.*
-|eq2_factor|
This allows us to express the following:
-.. image60_png has been renamed
+.. image:: img/eq2_expression.*
-|eq2_expression|
In the dropper module, a look-up table is used to compute log2(1-wq) for each value of wq supported by the dropper module.
The factor (1-wq)^m can then be obtained by multiplying the table value by *m* and applying shift operations.
The method that was finally selected (described above in Section 26.3.2.2.1) out performs all of these approaches
in terms of run-time performance and memory requirements and
also achieves accuracy comparable to floating-point evaluation.
-Table 17 lists the performance of each of these alternative approaches relative to the method that is used in the dropper.
+:numref:`table_qos_17` lists the performance of each of these alternative approaches relative to the method that is used in the dropper.
As can be seen, the floating-point implementation achieved the worst performance.
-.. _pg_table_17:
-
-**Table 17. Relative Performance of Alternative Approaches**
-
-+------------------------------------------------------------------------------------+----------------------+
-| Method | Relative Performance |
-| | |
-+====================================================================================+======================+
-| Current dropper method (see :ref:`Section 23.3.2.1.3 <Dropper>`) | 100% |
-| | |
-+------------------------------------------------------------------------------------+----------------------+
-| Fixed-point method with small (512B) look-up table | 148% |
-| | |
-+------------------------------------------------------------------------------------+----------------------+
-| SSE method with small (512B) look-up table | 114% |
-| | |
-+------------------------------------------------------------------------------------+----------------------+
-| Large (76KB) look-up table | 118% |
-| | |
-+------------------------------------------------------------------------------------+----------------------+
-| Floating-point | 595% |
-| | |
-+------------------------------------------------------------------------------------+----------------------+
-| **Note**: In this case, since performance is expressed as time spent executing the operation in a |
-| specific condition, any relative performance value above 100% runs slower than the reference method. |
-| |
-+-----------------------------------------------------------------------------------------------------------+
+.. _table_qos_17:
+
+.. table:: Relative Performance of Alternative Approaches
+
+ +------------------------------------------------------------------------------------+----------------------+
+ | Method | Relative Performance |
+ | | |
+ +====================================================================================+======================+
+ | Current dropper method (see :ref:`Section 23.3.2.1.3 <Dropper>`) | 100% |
+ | | |
+ +------------------------------------------------------------------------------------+----------------------+
+ | Fixed-point method with small (512B) look-up table | 148% |
+ | | |
+ +------------------------------------------------------------------------------------+----------------------+
+ | SSE method with small (512B) look-up table | 114% |
+ | | |
+ +------------------------------------------------------------------------------------+----------------------+
+ | Large (76KB) look-up table | 118% |
+ | | |
+ +------------------------------------------------------------------------------------+----------------------+
+ | Floating-point | 595% |
+ | | |
+ +------------------------------------------------------------------------------------+----------------------+
+ | **Note**: In this case, since performance is expressed as time spent executing the operation in a |
+ | specific condition, any relative performance value above 100% runs slower than the reference method. |
+ | |
+ +-----------------------------------------------------------------------------------------------------------+
Drop Decision Block
^^^^^^^^^^^^^^^^^^^
The initial drop probability is calculated using the following equation.
-**Equation 3.**
-
-.. image61_png has been renamed
-
-|drop_probability_eq3|
+.. image:: img/drop_probability_eq3.*
Where:
* *maxth* = maximum threshold
-The calculation of the packet drop probability using Equation 3 is illustrated in Figure 30.
+The calculation of the packet drop probability using Equation 3 is illustrated in :numref:`figure_pkt_drop_probability`.
If the average queue size is below the minimum threshold, an arriving packet is enqueued.
If the average queue size is at or above the maximum threshold, an arriving packet is dropped.
If the average queue size is between the minimum and maximum thresholds,
a drop probability is calculated to determine if the packet should be enqueued or dropped.
-.. _pg_figure_30:
+.. _figure_pkt_drop_probability:
-**Figure 30. Packet Drop Probability for a Given RED Configuration**
+.. figure:: img/pkt_drop_probability.*
-.. image62_png has been renamed
+ Packet Drop Probability for a Given RED Configuration
-|pkt_drop_probability|
Actual Drop Probability
"""""""""""""""""""""""
If the average queue size is between the minimum and maximum thresholds,
then the actual drop probability is calculated from the following equation.
-**Equation 4.**
-
-.. image63_png has been renamed
-
-|drop_probability_eq4|
+.. image:: img/drop_probability_eq4.*
Where:
It should be noted that the value pa computed from can be negative or greater than 1.
If this is the case, then a value of 1 should be used instead.
-The initial and actual drop probabilities are shown in Figure 31.
+The initial and actual drop probabilities are shown in :numref:`figure_drop_probability_graph`.
The actual drop probability is shown for the case where
the formula given in the reference document1 is used (blue curve)
and also for the case where the formula implemented in the dropper module,
The choice to deviate from the reference document is simply a design decision and
one that has been taken by other RED implementations, for example, FreeBSD* ALTQ RED.
-.. _pg_figure_31:
+.. _figure_drop_probability_graph:
-**Figure 31. Initial Drop Probability (pb), Actual Drop probability (pa) Computed Using a Factor 1 (Blue Curve) and a Factor 2 (Red Curve)**
+.. figure:: img/drop_probability_graph.*
-.. image64_png has been renamed
+ Initial Drop Probability (pb), Actual Drop probability (pa) Computed Using
+ a Factor 1 (Blue Curve) and a Factor 2 (Red Curve)
-|drop_probability_graph|
.. _Queue_Empty_Operation:
Source Files Location
~~~~~~~~~~~~~~~~~~~~~
-The source files for the Intel® DPDK dropper are located at:
+The source files for the DPDK dropper are located at:
* DPDK/lib/librte_sched/rte_red.h
* DPDK/lib/librte_sched/rte_red.c
-Integration with the Intel® DPDK QoS Scheduler
+Integration with the DPDK QoS Scheduler
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-RED functionality in the Intel® DPDK QoS scheduler is disabled by default.
-To enable it, use the Intel® DPDK configuration parameter:
+RED functionality in the DPDK QoS scheduler is disabled by default.
+To enable it, use the DPDK configuration parameter:
::
RED parameters are specified separately for four traffic classes and three packet colors (green, yellow and red)
allowing the scheduler to implement Weighted Random Early Detection (WRED).
-Integration with the Intel® DPDK QoS Scheduler Sample Application
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Integration with the DPDK QoS Scheduler Sample Application
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The Intel® DPDK QoS Scheduler Application reads a configuration file on start-up.
+The DPDK QoS Scheduler Application reads a configuration file on start-up.
The configuration file includes a section containing RED parameters.
The format of these parameters is described in :ref:`Section2.23.3.1 <Configuration>`.
A sample RED configuration is shown below. In this example, the queue size is 64 packets.
tc 3 wred weight = 9 9 9
With this configuration file, the RED configuration that applies to green,
-yellow and red packets in traffic class 0 is shown in Table 18.
-
-.. _pg_table_18:
-
-**Table 18. RED Configuration Corresponding to RED Configuration File**
-
-+--------------------+--------------------+-------+--------+-----+
-| RED Parameter | Configuration Name | Green | Yellow | Red |
-| | | | | |
-+====================+====================+=======+========+=====+
-| Minimum Threshold | tc 0 wred min | 28 | 22 | 16 |
-| | | | | |
-+--------------------+--------------------+-------+--------+-----+
-| Maximum Threshold | tc 0 wred max | 32 | 32 | 32 |
-| | | | | |
-+--------------------+--------------------+-------+--------+-----+
-| Mark Probability | tc 0 wred inv prob | 10 | 10 | 10 |
-| | | | | |
-+--------------------+--------------------+-------+--------+-----+
-| EWMA Filter Weight | tc 0 wred weight | 9 | 9 | 9 |
-| | | | | |
-+--------------------+--------------------+-------+--------+-----+
+yellow and red packets in traffic class 0 is shown in :numref:`table_qos_18`.
+
+.. _table_qos_18:
+
+.. table:: RED Configuration Corresponding to RED Configuration File
+
+ +--------------------+--------------------+-------+--------+-----+
+ | RED Parameter | Configuration Name | Green | Yellow | Red |
+ | | | | | |
+ +====================+====================+=======+========+=====+
+ | Minimum Threshold | tc 0 wred min | 28 | 22 | 16 |
+ | | | | | |
+ +--------------------+--------------------+-------+--------+-----+
+ | Maximum Threshold | tc 0 wred max | 32 | 32 | 32 |
+ | | | | | |
+ +--------------------+--------------------+-------+--------+-----+
+ | Mark Probability | tc 0 wred inv prob | 10 | 10 | 10 |
+ | | | | | |
+ +--------------------+--------------------+-------+--------+-----+
+ | EWMA Filter Weight | tc 0 wred weight | 9 | 9 | 9 |
+ | | | | | |
+ +--------------------+--------------------+-------+--------+-----+
Application Programming Interface (API)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the input color of the packet is also considered.
When the output color is not red, a number of tokens equal to the length of the IP packet are
subtracted from the C or E /P or both buckets, depending on the algorithm and the output color of the packet.
-
-.. |flow_tru_droppper| image:: img/flow_tru_droppper.png
-
-.. |drop_probability_graph| image:: img/drop_probability_graph.png
-
-.. |drop_probability_eq3| image:: img/drop_probability_eq3.png
-
-.. |eq2_expression| image:: img/eq2_expression.png
-
-.. |drop_probability_eq4| image:: img/drop_probability_eq4.png
-
-.. |pkt_drop_probability| image:: img/pkt_drop_probability.png
-
-.. |pkt_proc_pipeline_qos| image:: img/pkt_proc_pipeline_qos.png
-
-.. |ex_data_flow_tru_dropper| image:: img/ex_data_flow_tru_dropper.png
-
-.. |ewma_filter_eq_1| image:: img/ewma_filter_eq_1.png
-
-.. |ewma_filter_eq_2| image:: img/ewma_filter_eq_2.png
-
-.. |data_struct_per_port| image:: img/data_struct_per_port.png
-
-.. |prefetch_pipeline| image:: img/prefetch_pipeline.png
-
-.. |pipe_prefetch_sm| image:: img/pipe_prefetch_sm.png
-
-.. |blk_diag_dropper| image:: img/blk_diag_dropper.png
-
-.. |m_definition| image:: img/m_definition.png
-
-.. |eq2_factor| image:: img/eq2_factor.png
-
-.. |sched_hier_per_port| image:: img/sched_hier_per_port.png
-
-.. |hier_sched_blk| image:: img/hier_sched_blk.png
git.droids-corp.org / dpdk.git / blobdiff