NIC Hardware Offloading for Software Packet QoS Rate Limiting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current software-based approaches for network packet processing struggle to efficiently handle rate limiting for Quality of Service (QoS) due to high CPU overhead, especially with increasing network bandwidth and the need for precise timing, which can lead to latency and throughput issues in handling network flows with strict QoS requirements.
Innovation Solution
Offloading QoS rate limiting to Network Interface Controller (NIC) hardware while maintaining packet classification and priority assignment in software, allowing for efficient packet processing and minimizing CPU overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If rate limiting is performed using software executing on a CPU, then QoS priority assignment and flow classification can be done efficiently, but the CPU overhead increases significantly due to the need to read CPU cycle count during each loop to calculate running time
Solution Approach 1:
The patent extracts the rate limiting function from the CPU software processing path and implements it in dedicated hardware circuitry within the network interface card. This separation allows the CPU to focus on packet classification and priority assignment while the hardware circuitry independently handles timing-critical rate limiting operations, eliminating the CPU overhead of reading cycle counts during each packet processing loop.
Solution Approach 2:
The patent introduces a hardware intermediary component in the form of a timestamp counter and control logic within the NIC that bridges the software-based QoS priority assignment with hardware-based rate limiting enforcement. This intermediary hardware automatically captures packet arrival times and enforces rate limits without requiring CPU intervention for timing operations.
2Reliability
If more CPU cycles are allocated to rate limiting operations, then QoS requirements for strict latency can be met, but the overall packet processing latency increases due to serialization overhead
Solution Approach 1:
The patent replaces the software-based mechanical system of reading CPU cycle counts and calculating elapsed time with a dedicated hardware timestamp counter that automatically records packet arrival times. This hardware timing mechanism operates in parallel with packet processing, eliminating serialization overhead and ensuring deterministic latency compliance for QoS-critical packets without blocking the packet processing pipeline.
3Productivity
If hardware-based rate limiting is used in switches and NICs, then processing speed increases, but the number of supported flows is limited due to limited TCAM capacity
Solution Approach 1:
The patent segments the QoS processing functionality into two distinct parts: flow classification and priority assignment remain in software on the CPU, while only the rate limiting enforcement is implemented in hardware. This segmentation allows the system to support a large number of flows through software-based classification while using hardware only for the time-critical rate limiting function, avoiding the TCAM capacity constraints that would limit the number of supported flows.
Data Source
AI summary
Methods and apparatus for facilitating efficient Quality of Service (QoS) support for software-based packet processing by offloading QoS rate-limiting to NIC hardware. Software-based packet processing is performed on packet flows received at a compute platform, such as a general purpose server, and/or packet flows generated by local applications running on the compute platform. The packet processing includes packet classification that associates packets with packet flows using flow IDs, and identifying a QoS class for the packet and packet flow. NIC Tx queues are dynamically configured or pre-configured to effect rate limiting for forwarding packets enqueued in the NIC Tx queues. New packet flows are detected, and mapping data is created to map flow IDs associated with flows to the NIC Tx queues used to forward the packets associated with the flows.