Virtual Switch Scaling via Hardware Queue Manager Distribution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current virtual switch solutions in cloud computing data centers face inefficiencies and limitations in scaling and latency due to the need for dedicated compute threads for switching, leading to bottlenecks and non-linear scaling issues, especially in high-performance use cases with granular composable architectures.
Innovation Solution
The implementation of a Hardware Queue Manager (HQM) distributes switching functions across compute cores, allowing direct communication between cores and eliminating the need for dedicated virtual switch cores, using a many-to-one connection to scale performance linearly with the number of cores and reduce latency by keeping packets in the middle-level cache.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If dedicated compute threads are reserved for virtual switching, then switching function is provided, but scaling is non-linear and expensive due to many-to-many queue relationships between switch cores and compute cores
Solution Approach 1:
The patent segments the virtual switching function by distributing switch cores across multiple compute cores rather than having a centralized switch core. Each compute core handles switching for its local containers, eliminating the need for complex many-to-many queue relationships between dedicated switch cores and compute cores. This segmentation allows linear scaling as compute cores are added to the system.
Solution Approach 2:
The patent makes compute cores multi-functional by having them perform both computation and virtual switching functions. Instead of dedicating specific cores solely to switching, each compute core can handle both its own computational tasks and switching operations for local containers. This universality eliminates the need for separate dedicated switch cores and their associated complex queue management.
2Productivity
If packets are moved between compute cores and switch cores, then virtual switching is achieved, but latency increases due to thread switches and core transitions
Solution Approach 1:
The patent merges the switching function with compute cores by allowing compute cores to perform both computation and switching operations. This eliminates the need for packets to be moved between separate switch cores and compute cores, thereby reducing latency caused by thread switches and core transitions. The merging of functions keeps packet processing local to the compute core.
3Productivity
If multiple switch cores are used for high performance, then bandwidth is increased, but latency worsens as overworked cores become a bottleneck
Solution Approach 1:
The patent segments the switching workload across multiple compute cores that are already distributed throughout the system. Instead of adding more centralized switch cores that can become bottlenecks, the segmentation approach distributes switching responsibilities to multiple compute cores, each handling local traffic independently. This eliminates the bottleneck effect and maintains low latency while providing high bandwidth.
4Reliability
If compute threads are exclusively reserved for switching, then switching function is ensured, but threads are unavailable for other purposes reducing system efficiency
Solution Approach 1:
The patent implements multi-functionality by enabling compute cores to perform both computation and virtual switching operations. Instead of reserving dedicated threads exclusively for switching, the same compute cores handle both their computational workloads and switching tasks for local containers. This universality ensures switching function availability while maintaining high overall system efficiency by utilizing existing compute resources.
Data Source
AI summary
Examples include a method of switching a packet by a virtual switch by receiving a system call to transmit a packet from a first application running in a first container on a first core, determining a destination for the packet, obtaining a buffer in an application memory space of the destination, copying the packet to the destination application memory space, and writing an entry for the packet to a queue assigned to the destination, the destination queue being in a queue manager. The packet may then be obtained by an entity at the destination.