Quality of Service (QoS)

Link-Inline™ Software Features
Platform
Napatech SmartNIC
Content Type
Feature Description
Capture Software Version
Link-Inline™ Software 3.2

Napatech SmartNICs running Link-Inline™ Software support traffic metering and policing. The policing discards frames that exceed a configured maximum bit rate while the traffic meter counts the number of frames and bytes, and provide statistics.

Policing and metering process

The leaky bucket with a configured maximum bit rate (MBR) is used for traffic policing in the SmartNIC. This figure illustrates the sequence of the policing and metering process in the SmartNIC.


Page-1 Sheet.1 SmartNIC SmartNIC Sheet.2 Flow lookup Flow lookup Sheet.3 Usage counter update Usage counter update Bent Arrow.14 Bent Arrow.25 Simple Arrow.28 HIT HIT Sheet.10 Flow table Flow table Sheet.11 Sheet.13 Policy lookup Policy lookup Bucket Bucket Sheet.32 Sheet.33 Sheet.34 Sheet.35 Sheet.36 Bucket Sheet.63 Drop Drop Sheet.65 Simple Arrow.67 Exceed Exceed Simple Arrow.68 Sheet.69 Simple Arrow.70 Sheet.71 Further processing Further processing Bent Arrow.72 Sheet.78 Application Application Bent Arrow.20 Sheet.111 Sheet.112 MISS MISS Simple Arrow.114 Low priority Low priority Simple Arrow.115 Sheet.117 Drop Drop Bent Arrow.118 Bent Arrow.119 Sheet.120 Simple Arrow.121 Low priority Low priority Sheet.122 Drop Drop

The sequence of steps per frame in the SmartNIC is as follows:
  1. The flow of a frame is found in the table during the flow-lookup process in the SmartNIC
  2. Associated policies of the flow are looked up.
    1. If the maximum bit rate (MBR) of the flow in a policy has been exceeded, the frame is discarded. The discarded frame is counted as dropped. No further policy lookup is performed
    2. If the maximum bit rate (MBR) of the flow in a policy has not been exceeded, the next policy is looked up. A maximum of 4 policies per flow are looked up.
  3. If the frame passes all associated policies, usage counters only in the last policy are updated for metering.

Multiple policy lookups per flow

Napatech Link-Inline™ Software supports policing for quality of service (QoS) as follows.
  • A maximum of 4 policies per flow are supported.
  • The multiple policy lookups are performed in order as listed by the application.
  • In case of multiple policy lookups, if a policy lookup causes the drop action, no further policy lookup is performed.
  • A policy can be shared by multiple flows.

Maximum bit rate (MBR) support

The DPDK API for creating meter profiles supports different policing algorithms. Napatech Link-Inline™ Software partially supports the trTCM (two-rate three-color marker) algorithm according to RFC 2698 and only in byte mode. Napatech Link-Inline™ Software supports parameters for the trTCM algorithm as follows.
  • The committed information rate (CIR) and the peak information rate (PIR) in a metering profile set the maximum bit rate in bytes per second. These parameters must be set to the same value.
  • The committed burst size (CBS) and the peak burst size (PBS) in a metering profile define the bucket size in bytes. These parameters must be set to the same value.
  • The packet mode parameter must be set to 0 to select the byte mode.

Creating a policy without an MBR

It is possible to create a policy without limiting the rate by configuring the limit to a higher value than the line-speed throughput (higher than 100 Gbit/s, for example). This enables monitoring usage counters of target flows without discarding frames.

Adjusting the fill level of the leaky bucket

When frames are forwarded to the host, the leaky-bucket state of associated policies are not updated. It is possible to adjust the fill level of the leaky bucket using the DPDK API rte_mtr_stats_update. If the most significant bit of the stats_mask field is set (bit 63), rte_mtr_stats_update updates the fill level of the bucket for the MTR object with the given ID. For example:
const uint64_t adjust_bit = (uint64_t)1 << 63;
struct rte_mtr_error err;

if (rte_mtr_stats_update(PORT_ID, MTR_ID, adjust_bit | 1000000, &err)) {
  /* Error handling */
}
This example shows how to add 1 million bytes to the leaky bucket.
Note: Usage counters are not updated when updating the fill level of the leaky bucket is triggered by the application. The application must add the corresponding values to the statistics received from the SmartNIC.

Flow priority

Frames can be discarded in the SmartNIC based on the priority of each flow in the following situations:
  • Network congestion: If the policy-lookup rate cannot keep up with the flow-lookup rate, or the RX rate is in sustained high traffic load.
  • Oversubscription on the TX port: After encapsulation, if frames are expanded too much. This can lead to the TX port being oversubscribed.
See the figure sequence of the policy-lookup process.
The priority of each flow is configured in the application. 4 priority levels are supported: 0 to 3 where 0 indicates the highest priority as follows. The priority is set to 0 by default.
  • Priority 3: Drop frames at 12.5% FPGA load level.
  • Priority 2: Drop frames at 25% FPGA load level.
  • Priority 1: Drop frames at 37.5% FPGA load level.
  • Priority 0: Drop frames at 100% FPGA load level. Frames are dropped only if the SmartNIC is overloaded.
For frame processing of the user plane function (UPF) in the 5G core network architecture, the guaranteed bit rate (GBR) can be achieved by assigning a high priority to GBR flows and a low priority to non-GBR flows. This ensures that GBR flows are always prioritized.
Note: Discarded frames are counted as dropped.

Metering statistics

The following usage counters are maintained for each policy in the SmartNIC.
  • Byte counter
  • Packet counter
Usage counters can be retrieved by the application at regular intervals. The SmartNIC sends the usage information to the host when a frame is received, if any of the following conditions have been true since the last record of the flow has been sent:
  • The byte counter of the flow reaches 8 MB.
  • The packet counter of the flow reaches 64000.
  • 279 seconds has passed.
Therefore, the interval for reading usage counters must be adjusted depending on the amount of traffic.
Parameters for generating the usage information are defined in the flow_api_profile_inline_config.h header file as follows:
/*
* Statistics are generated each time the byte counter crosses a limit.
* If BYTE_LIMIT is zero, then the byte counter does not trigger statistics
* generation.
*
* Format: 2^(BYTE_LIMIT + 15) bytes
* Valid range: 0 to 31
*
* Example: 2^(8 + 15) = 2^23 ~~ 8MB
*/
#define NTNIC_FLOW_PERIODIC_STATS_BYTE_LIMIT 8
 
/*
* Statistics are generated each time the packet counter crosses a limit.
* If PKT_LIMIT is zero then the packet counter does not trigger statistics
* generation.
*
* Format: 2^(PKT_LIMIT + 11) pkts
* Valid range: 0 to 31
*
* Example: 2^(5 + 11) = 2^16 pkts ~~ 64K pkts
*/
#define NTNIC_FLOW_PERIODIC_STATS_PKT_LIMIT 5
 
/*
* Statistics are generated each time flow time (measured in ns) crosses a
* limit.
* If BYTE_TIMEOUT is zero then the flow time does not trigger statistics
* generation.
*
* Format: 2^(BYTE_TIMEOUT + 15) ns
* Valid range: 0 to 31
*
* Example: 2^(23 + 15) = 2^38 ns ~~ 275 sec
*/
#define NTNIC_FLOW_PERIODIC_STATS_BYTE_TIMEOUT 23

Related links