Ethernet Load Balancing via Offload Adapter Byte Count Monitoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional Ethernet adapter load balancing methods, such as EtherChannel, face issues like additional software latency, scaling problems in multi-CPU environments, delayed error detection, and bandwidth reduction due to context switching and single-threaded interrupt servicing.
Innovation Solution
A system and method for Ethernet packet load balancing that uses an offload adapter to identify the least busy port based on byte count and status, assigning packets to it and updating the port list for error handling, eliminating the need for additional software layers and improving error detection and recovery.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If EtherChannel driver software is used for load balancing, then packet distribution among multiple ports is achieved, but additional software latency is introduced
Solution Approach 1:
The patent extracts the load balancing functionality from the central EtherChannel driver software and implements it directly within the network adapter hardware itself. Each port has its own load balancing logic that independently selects packets for transmission, eliminating the need for centralized software coordination and reducing software processing latency.
Solution Approach 2:
The network adapter performs load balancing autonomously without requiring intervention from the operating system or application layer. The hardware-based load balancer makes packet selection decisions locally based on port status and traffic conditions, making the system self-sufficient and eliminating software latency.
2Ease of operation
If EtherChannel software is configured with N-to-1 receive and 1-to-N transmit model, then packet routing is controlled, but software locking issues arise in multi-CPU environments
Solution Approach 1:
The patent removes the centralized software locking mechanism entirely by implementing load balancing at the hardware level. Each port's load balancing logic operates independently without requiring inter-process communication or locking, eliminating the complexity of synchronization in multi-CPU environments.
Solution Approach 2:
The load balancing function is segmented into independent per-port logic rather than a centralized software process. Each port has its own state tracking and packet selection capability, allowing parallel operation without coordination overhead or locking requirements.
3Reliability
If EtherChannel driver waits for error indication from port hardware, then error detection is achieved, but longer delay causes more data to be dropped
Solution Approach 1:
The patent implements preliminary error detection by having each port continuously monitor its own operational status and immediately notify the load balancer when an error occurs. This eliminates the need to wait for error indications to propagate through the software stack, reducing detection delay and allowing faster error recovery.
4Device complexity
If single-threaded Kernel Interrupt function is used, then interrupt handling is simplified, but longer latency for servicing reduces bandwidth
Solution Approach 1:
The patent replaces the software-based single-threaded interrupt handling with a hardware-based interrupt mechanism. The network adapter hardware directly services interrupts without requiring context switching or software intervention, reducing latency and improving bandwidth utilization while maintaining simple interrupt handling logic.
5Ease of operation
If context switching is performed for each interrupt between ports, then interrupt servicing is achieved, but CPU cycles are consumed reducing effective bandwidth
Solution Approach 1:
The patent extracts interrupt servicing from the CPU and relocates it to the network adapter hardware itself. The hardware-based load balancer and interrupt handler process interrupts locally without requiring CPU context switching, eliminating CPU cycle consumption while maintaining full interrupt servicing capability.
Solution Approach 2:
The network adapter hardware autonomously handles its own interrupts and load balancing without requiring CPU involvement. The system serves itself by processing packets and interrupts locally, eliminating the need for context switching and reducing CPU resource consumption.
Data Source
AI summary
A method for Ethernet packet load balancing includes receiving a transmit packet for transmission on an Ethernet network. An offload adapter identifies a least busy port from a plurality of ports indicated in a port list, based on a byte count associated with each of the plurality of ports. The offload adapter determines whether the identified least busy port is in a working status. In the event an identified least busy port is in a working status, the offload adapter assigns the transmit packet to the identified least busy port and increments the byte count associated with the identified least busy port. In the event an identified least busy port is not in a working status, the offload adapter updates the port list and, based on a determination that there are additional working ports, assigns the transmit packet to one of the additional working ports.