Flow Director Low Latency Networking Polling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional networking stacks, such as TCP/IP, face challenges in reducing latency and jitter due to device interrupts and DPC scheduling, which are not effectively managed by network device drivers unaware of application polling.
Innovation Solution
Implementing a flow director-based system where the network device driver polls a receive queue using a packet flow identifier, disabling interrupts to avoid context switching and DPC scheduling, and enabling low-latency packet processing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional networking stack with interrupts is used, then compatibility for socket-based applications is improved, but latency and jitter increase
Solution Approach 1:
The patent segments the packet processing path by introducing a dedicated receive queue (RxQ) that is separate from the traditional interrupt-driven processing path. This allows polling-based low-latency processing for specific packet flows while maintaining traditional interrupt handling for other traffic, thus resolving the contradiction between compatibility and latency.
Solution Approach 2:
The patent introduces a flow director as an intermediary component that classifies packets into different queues based on flow identifiers. This mediator enables the system to route certain packet flows to polling-based processing while leaving others to traditional interrupt handling, maintaining both compatibility and low latency performance.
2Loss of time
If polling is implemented by application, then latency is reduced, but device interrupts and DPC scheduling still occur increasing latency variation
Solution Approach 1:
The patent extracts the interrupt handling function from the traditional networking stack by introducing a polling mechanism that directly queries the receive queue without triggering interrupts. This extraction eliminates DPC scheduling and interrupt context switching, reducing latency variation while maintaining low latency performance.
Solution Approach 2:
The patent implements dynamic ownership transfer of the receive queue between the network device driver and the application. The driver temporarily holds the queue for processing, then transfers ownership to the application for polling, enabling flexible and adaptive packet handling that reduces latency variation.
3Loss of time
If network device driver disables interrupts for polling, then latency and jitter are reduced, but interrupt handling capability is temporarily suspended
Solution Approach 1:
The patent implements dynamic enable/disable of interrupts based on the processing state. The network device driver disables interrupts only during polling operations to reduce latency, then re-enables them when polling completes to restore full interrupt handling capability. This dynamic state change resolves the contradiction between low latency and interrupt handling versatility.
Solution Approach 2:
The patent performs preliminary actions by pre-configuring the receive queue ownership transfer mechanism before polling begins. The driver establishes the polling context and transfers queue ownership in advance, allowing interrupts to be safely disabled without compromising future interrupt handling capability, thus resolving the contradiction.
Data Source
AI summary
Generally, this disclosure relates to low latency networking. A system may include processor circuitry comprising at least one processor; memory circuitry configured to store an application, a receive queue and a networking stack comprising a network device driver; a network controller comprising a flow director, the network controller configured to couple the host device to at least one link partner and the flow director configured to store one or more selected received packets in the receive queue, the selecting based, at least in part, on a packet flow identifier; and a network device driver configured to identify the receive queue in response to a polling request comprising the packet flow identifier; poll the receive queue; and process each received packet stored in the receive queue.