Accelerated multi-plane routing

Abstract

This disclosure relates to accelerating multi-plane routing. Techniques are described that provide an accelerated routing service that supports multi-plane routing. One approach is to exchange control traffic between an accelerated routing service executed by a host device and an accelerated routing service executed by other host devices. The approach configures a virtual bridge with a first set of multi-plane routing rules using control traffic, the first set of multi-plane routing rules specifying a first set of available data planes for each host device. The approach configures registers associated with a plurality of network adapters using the virtual bridge. The approach receives a first packet at the virtual bridge destined for a first target host device and routes the first packet to one of the first set of available data planes for the first target host device using the virtual bridge according to the first set of multi-plane routing rules.

Description

Technical Field

[0001] At least one embodiment relates to processing resources for performing and facilitating operations to provide accelerated routing services with multi-plane support. For example, at least one embodiment relates to a processor or computing system for providing and enabling an acceleration hardware engine to provide accelerated routing of network traffic data across multiple accelerated data planes according to the various new technologies described herein. Background Technology

[0002] In traditional network architectures, various security and performance functions are managed by dedicated hardware devices called middleboxes, each playing a different role. Firewalls, as independent physical devices, are the primary defense mechanism at the network edge. They review incoming and outgoing traffic according to predefined rules, blocking or allowing data transmission to protect the internal network from external threats. Load balancers, operating as independent hardware units, intelligently distribute incoming network and application traffic across multiple servers to prevent overload and ensure efficient resource utilization, thereby improving application availability and performance. Intrusion Detection Systems (IDS) are strategically deployed in the network, specifically designed to monitor and analyze network traffic to detect anomalies, attacks, or signs of security policy violations, thus acting as a security component to identify potential security vulnerabilities.

[0003] In addition, the network utilizes other middlebox functions, such as Data Loss Prevention (DLP) systems to monitor and prevent unauthorized data breaches, Virtual Private Network (VPN) gateways to establish secure and encrypted connections across networks, and WAN-optimized equipment designed to improve data transmission efficiency over the WAN. These middleboxes are crucial but also present challenges: they require significant capital investment, occupy valuable data center space, and require specialized personnel for operation and maintenance. Expanding these network functions typically means acquiring and integrating more physical equipment, increasing the complexity and cost of the network infrastructure. Attached Figure Description

[0004] Various embodiments of this disclosure will now be described with reference to the accompanying drawings, in which: Figure 1 This is a block diagram of a computing system according to at least one embodiment, the computing system having multiplane routing logic for providing virtual bridges and supporting accelerated routing services across multiple planes.

[0005] Figure 2 This is a block diagram of the software stack of a host device according to at least one embodiment, the host device having a virtual bridge and accelerated routing services supporting multiple planes.

[0006] Figure 3A It is a block diagram of a two-layer ridge topology according to at least one embodiment.

[0007] Figure 3B It is a block diagram of a three-layer ridge topology according to at least one embodiment.

[0008] Figure 4A It is a block diagram of a multi-plane topology according to at least one embodiment, wherein there are multiple NICs, each of which supports multiple planes.

[0009] Figure 4B According to at least one embodiment Figure 4A A block diagram of a multiplane topology, in which a plane failure occurs.

[0010] Figure 5 This is a flowchart of an example method for providing accelerated multiplane routing to a target host device according to at least one embodiment.

[0011] Figure 6 An example computer system according to at least some embodiments is shown, the computer system including an accelerated routing service that supports multiple planes.

[0012] Figure 7 It is a block diagram of a computing system having two mutually coupled processing devices and multiple networks according to at least one embodiment.

[0013] Figure 8 It is a block diagram of a computing system having a central processing unit (CPU) and a graphics processing unit (GPU) located in a single integrated circuit, according to at least one embodiment.

[0014] Figure 9 It is a block diagram of a computing system having a tensor kernel graphics processing unit (GPU) according to at least one embodiment. Detailed Implementation

[0015] This document describes techniques for providing accelerated routing services with multi-plane support. The following description lists numerous specific details, such as examples of particular systems, components, methods, etc., to better understand several embodiments of this disclosure. However, those skilled in the art will understand that at least some embodiments of this disclosure can be implemented without these specific details. In other instances, to avoid unnecessarily obscuring this disclosure, well-known components or methods are not described in detail herein, but are presented in the form of simple block diagrams. Therefore, the specific details listed are merely illustrative. Actual implementations may differ from these illustrative details but should still be considered within the scope of this disclosure.

[0016] As mentioned above, in traditional network architectures, various security and performance functions are managed by dedicated hardware devices called middle boxes (such as firewalls, load balancers, IDS, etc.). The design philosophy of traditional networks assumes that all resources are housed within a local data center, typically represented by a centralized model.

[0017] Modern networks are increasingly cloud-centric, designed to support cloud services and applications. This includes the use of public, private, and hybrid cloud infrastructures, thus requiring greater network flexibility and scalability. Unlike traditional network architectures that heavily rely on physical hardware (i.e., each network function requires dedicated equipment), current network architectures leverage virtualization technologies such as Software-Defined Networking (SDN) and Network Functions Virtualization (NFV). These technologies abstract network resources from hardware, providing greater flexibility, easier management, and lower costs. Modern networks increasingly use automation and orchestration tools to efficiently manage network resources, reduce operational overhead, and accelerate the deployment of network services. Modern networks are designed with scalability and high performance in mind, utilizing technologies such as edge computing to process data closer to the source and reduce latency. Current network architectures are more flexible, scalable, and efficient than traditional architectures, designed to support the dynamic and distributed nature of modern computing resources and work practices. They integrate advanced technologies such as cloud services, virtualization, and automation to meet the needs of today's digital environment.

[0018] Multiplane networking is a technique used in large data centers to increase port cardinality, enhance scalability, and reduce the number of spine layers in the network topology. Multiplane networks consist of multiple independent planes (switch groups) that provide parallel paths for traffic between endpoints. Instead of a single large fabric, the network is divided into multiple smaller fabrics (planes), each operating independently but interconnected at some nodes. This approach increases the port cardinality of the fabric by distributing traffic across several independent paths, enabling more connections while keeping the switch port count manageable. Furthermore, because multiplane networks allow traffic to be distributed across parallel planes, they also reduce the number of spine layers required in traditional Clos topologies, minimizing the need for additional layers. Clos topology is a multi-stage switching network commonly used in data centers that allows any input to reach any output without congestion, even during periods of network overload. Multiplane networking technology was first proposed by Charles Close in 1952 and is defined by three integer parameters: n (number of inputs), m (number of intermediate switches), and r (number of outputs). Furthermore, multi-plane networking improves fault tolerance and redundancy; if one plane fails, other planes can continue forwarding traffic, ensuring higher reliability. Using Equal Cost Multipath (ECMP) technology, traffic load balancing can be efficiently performed across multiple planes, thus optimizing load balancing. In addition, this technology can reduce latency because the spine-leaf topology has fewer layers, resulting in fewer hops per packet in the network, thereby reducing end-to-end latency.

[0019] The following section outlines some key differences between multiplane and non-multiplane network architectures. A single architecture without multiplanes can be a traditional Clos architecture, where leaf switches connect to servers, and spine switches provide interconnectivity between the leaf switches. If more ports are needed, another layer of spine switches must be added, thus increasing network depth (latency).

[0020] Using a multi-plane (multiple structures) approach, the entire network is divided into independent structures (planes). Each plane contains its own set of spine switches and leaf switches. Leaf switches can be configured for dual-homed or multi-homed operation across multiple planes, ensuring redundancy. Traffic between any two devices can traverse different planes, increasing overall bandwidth and reducing hop count.

[0021] However, the current deployment of host devices coupled with leaf switches does not support multiplane because traditional NICs and DPUs do not support multiplane.

[0022] Various aspects and embodiments of this disclosure can provide virtual bridges and accelerated routing services supporting multiple planes. An accelerated routing service is a service routing protocol that includes data path protocols (e.g., IP, TCP / UDP) and control protocols (e.g., BGP) for configuring multi-plane decisions. Various aspects and embodiments of this disclosure can provide more available ports without increasing network depth, reduce latency (by reducing switch hop count), and provide higher redundancy (a failure in one plane does not affect other planes). Table 1 below describes the main advantages: Data Processing Unit (DPU) Various aspects and embodiments of this disclosure can provide acceleration of multiplane routing at the underlying hardware (e.g., NIC or DPU). In particular, when using a DPU, multiplane routing rules can be controlled by an accelerated routing service and accelerated by the DPU.

[0023] In modern network architectures, Data Processing Units (DPUs) can be used to provide a set of software-defined networking, storage, security, and management services at the data center scale, and can offload, accelerate, and isolate data center infrastructure. DPUs can offload processing tasks typically handled by server central processing units (CPUs), such as encryption / decryption, firewalling, Transmission Control Protocol / Internet Protocol (TCP / IP) and Hypertext Transfer Protocol (HTTP) processing, and any combination of network operations. A DPU can be an integrated circuit or a System-on-a-Chip (SoC), which is considered data center infrastructure on a chip. A CPU can include DPU hardware and DPU software (e.g., a software framework with acceleration libraries). DPU hardware may include a CPU (e.g., a single-core or multi-core CPU), one or more hardware accelerators, memory, one or more physical host interfaces operatively coupled to one or more host devices (e.g., the CPU of a host device), and one or more physical network interfaces operatively coupled to a network (e.g., a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or a wide area network (WAN)), a wired network (e.g., Ethernet), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) network), a router, a hub, a switch, a server computer, a network adapter, an NVLink switch, and / or combinations thereof). The DPU can handle network data path processing for network traffic data, while the host devices can control path initialization and exception handling. Acceleration hardware engines (e.g., DPU hardware) can utilize the hardware capabilities of acceleration hardware engines to offload and filter network traffic according to predefined filters. The software framework and acceleration library may include one or more hardware acceleration services, including hardware acceleration services (such as NVIDIA DOCA), hardware acceleration virtualization services, hardware acceleration networking services, hardware acceleration storage services, hardware acceleration artificial intelligence / machine learning (AI / ML) services, hardware acceleration services, and hardware acceleration management services.

[0024] A DPU can provide accelerated network services to one or more host devices. DPU network services can be used to accelerate Layer 2 (L2) protocols, Layer 3 (L3) protocols, tunneling protocols, and more on the DPU hardware. The DPU can use a service-controlled virtual bridge (e.g., an Open vSwitch (OVS) bridge) to provide all accelerated network functions. This service can support various protocols and network functions, such as Access Control Lists (ACLs), Equal Cost Multipath (ECMP), tunneling, Connection Tracking (CT), Quality of Service (QoS) rules, Spanning Tree Protocol (STP), Virtual Local Area Network (VLAN) mapping, Network Address Translation (NAT), Software-Defined Networking (SDN), Multiprotocol Label Switching (MPLS), and more.

[0025] OVS and OVS bridge Various aspects and embodiments of this disclosure can provide virtual bridges, such as OVS bridges. Open vSwitch (OVS) is an open-source, multi-tiered virtual switch used to manage network traffic in virtualized environments, particularly in data centers and cloud computing platforms. OVS provides network connectivity between virtual machines (VMs), containers, and physical devices. OVS is widely used in virtualization and cloud computing technologies and is a typical component of many software-defined networking (SDN) and network virtualization solutions.

[0026] Virtual switches are commonly found in virtualized computing environments. They are software applications that allow virtual machines (VMs) on a single physical host to communicate with each other and with external networks. Virtual switches provide network connectivity between VMs, containers, and physical devices. Virtual switches can emulate the functionality of a physical network switch but operate at a software level within a hypervisor or host operating system. Virtual switches manage network traffic, routing data packets between VMs on the same host or between VMs and the physical network using ports. These ports can be configured for various policies, such as security settings, Quality of Service (QoS) rules, etc. Virtual switches can segment network traffic, providing isolation between different virtual networks. Virtual switches provide an interface between the virtualization environment and the physical network, enabling VMs to communicate outside their host. Virtual switches can support standard network protocols and functions, such as Virtual LAN (VLAN) tagging, Layer 2 forwarding, Layer 3 functions, etc. OVS supports the OpenFlow protocol, allowing network controllers to control virtual switches and determine how traffic is routed within the network. A network controller (such as a Software-Defined Networking (SDN) controller) is a centralized entity responsible for managing traffic control for network devices. It is the "brain" of the network, maintaining a comprehensive view of the network and making decisions about where packets are sent. The OpenFlow (OF) protocol enables the controller to interact directly with the forwarding plane of network devices, such as switches and routers, including physical and virtual devices. OF configuration refers to setting up and managing network behavior using the OpenFlow protocol in an SDN environment. It involves defining flow rules and actions to control how network devices (typically centrally managed by the SDN controller) handle traffic. OF configuration can include flow tables, which contain packet processing rules. Each flow table contains a set of flow entries. A flow entry defines how to process packets that match specific conditions. An entry can contain three parts: a match field, an action, and a counter. The match field defines the packet attributes to match, such as source / destination Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, port numbers, VLAN tags, etc. Actions can define how to process matching packets, such as forwarding them to a specific port, modifying fields in the packet, or dropping it. The counter can be used to track the number of packets and bytes in each flow. The network controller can use control messages to manage flow entries in switches. It can add, update, or delete flow entries. Optional configurations can include group tables for more advanced forwarding actions such as multicast and load balancing. It's important to note that OVS is a virtual switch technology, but other virtual switch technologies exist, such as SDN-based switches.

[0027] OVS bridges act as virtual network switches at the software level, allowing the connection and management of multiple network interfaces as if they were ports on a physical switch. OVS bridges support the creation and management of virtual networks across multiple servers within a server environment, data center, or cloud environment. OVS bridges connect virtual network interfaces and physical network interfaces, facilitating communication between them. This can include interfaces from VMs, containers, physical network interfaces, or even other virtual bridges. Similar to physical Ethernet switches, OVS bridges operate at Layer 2 (L2) of the Open Systems Interconnection model (known as the OSI model), forwarding, filtering, and managing traffic based on Media Access Control (MAC) addresses. OVS bridges can support advanced features such as Virtual LAN (VLAN) tagging, Quality of Service (QoS), traffic mirroring, and Access Control Lists (ACLs). OVS bridges can be controlled via a controller using protocols such as OpenFlow (OF), enabling dynamic and programmable network configuration.

[0028] This document describes certain aspects and embodiments of this disclosure in relation to OVS and includes terminology specific to OVS and OpenFlow. However, certain aspects and embodiments of this disclosure can also be used with other virtual switching and bridging technologies. Similarly, this document describes various embodiments in the context of DPUs, but they can also be used with other virtual switching environments, including virtual bridges, switches, network interface controllers (NICs) (also known as network interface cards), smart NICs, network interface devices, network switches, network adapters, intelligent processing units (IPUs), or other dedicated computing devices designed to offload specific tasks from the CPU of a computer or server.

[0029] DPUs are dedicated semiconductor devices designed to offload and accelerate networking, security, and storage tasks traditionally run on server CPUs. By taking over these functions, DPUs aim to significantly improve the overall efficiency and performance of data centers. They are equipped with their own processors and memory, enabling them to handle complex data processing tasks independently of the host CPU. Embedded within the data center infrastructure, DPUs manage data movement and processing across the network, freeing up CPU resources to focus more on application and workload processing. This architectural shift increases workload density, boosts data throughput, and enhances security measures at the hardware level. DPUs play a crucial role in software-defined networking (SDN), providing hardware acceleration for advanced features such as encryption, traffic management, and virtualization. By optimizing these critical operations, DPUs help create more agile, secure, and efficient data centers.

[0030] An Integrated Processing Unit (IPU) is a dedicated hardware accelerator designed to optimize the performance of machine learning algorithms and artificial intelligence (AI) workloads. Unlike general-purpose CPUs or graphics processing units (GPUs), which, while versatile, may not be optimized for AI tasks, IPUs are specifically designed to handle the high computational demands and data throughput requirements of deep learning models and neural network processing. They achieve this by implementing highly parallel computing architectures and memory systems, enabling efficient processing of the massive amounts of data associated with AI applications. IPUs aim to reduce latency and increase AI computing speed, allowing for faster and more efficient training of more complex models.

[0031] A Smart NIC is an advanced network interface card equipped with built-in processing capabilities to offload network tasks from the CPU, thereby improving data processing efficiency and performance within the server. Unlike traditional NICs, which primarily serve as data channels between the server and the network, Smart NICs can directly perform various network functions on the card, such as traffic management, encryption / decryption, and network virtualization tasks. These functions enable Smart NICs to significantly reduce CPU load, freeing up resources to improve the overall processing power of the server, thus better handling application workloads. By handling complex network functions, Smart NICs can achieve reduced latency and higher throughput in data center environments, making them particularly important in scenarios requiring real-time processing and high-speed networks, such as cloud computing, high-performance computing (HPC), and enterprise data centers. The intelligence and programmability of Smart NICs provide flexible solutions to meet the ever-changing needs of modern network infrastructure, contributing to more efficient and customizable network operations.

[0032] Plane Faults and Plane Recovery Various aspects and embodiments of this disclosure can provide an accelerated routing service that supports plane fault detection (also known as link failure) and plane recovery (also referred to herein as "plane fault"). A link failure in a network topology refers to a situation where a communication link between two network devices (e.g., routers, NICs, switches, or hosts) becomes unavailable due to various reasons such as hardware failure, cable breakage, or network congestion. Link failures can significantly impact the performance, availability, and reliability of network services, especially in large-scale or critical environments such as data centers or enterprise networks. Link failures can be caused by a variety of reasons, such as physical link failures (e.g., cable damage or breakage due to fiber optic cable breakage, Ethernet cable breakage, etc.), device failures (e.g., hardware failure causing interface failure), congestion or overload (i.e., excessive traffic on the network link causing overload leading to timeouts or packet loss), software errors or misconfigurations causing network device disconnection, power failures, maintenance activities (e.g., planned maintenance or upgrade downtime can also cause temporary link failures), and so on.

[0033] Link failures can have various impacts. When a link breaks, packets transmitted over that link will be lost. This causes transmission delays and impacts real-time applications (e.g., VoIP, streaming media). Connections between devices relying on the failed link will be unavailable until rerouting. After a link failure, traffic may need to be routed through longer alternative paths, introducing higher latency and negatively impacting application performance. If the failed link is part of a redundant configuration (e.g., in ECMP, Spanning Tree Protocol (STP), or dual-homed devices), traffic can be rerouted to a backup link. However, this may reduce the level of redundancy. In networks running dynamic routing protocols such as Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and Intermediate System to Intermediate System (IS-IS)), when a link fails, the network must reconverge by recalculating new routes. This convergence process can take some time, during which time affected network portions may be unreachable. If the rerouting traffic exceeds the capacity of the alternative paths, rerouting traffic from the failed link can cause congestion on the alternative paths. Mission-critical applications (such as financial services or online games) may experience downtime or performance degradation due to link failures. TCP connections may undergo retransmissions, increasing latency, while UDP connections may lose data without retries. Point-to-point communication may cease entirely until network convergence or the failed link is restored, potentially leading to service interruption. Services relying on high availability (HA) solutions may be affected if no failover path exists or if the failover mechanism remains active for an excessively long time.

[0034] One routing strategy is called ECMP. ECMP is a routing strategy that allows packets to be forwarded to their destination via multiple paths when multiple paths have the same routing cost (or metric). By utilizing ECMP, networks can balance traffic across multiple paths, improve bandwidth utilization, enhance redundancy, and provide fault tolerance. Given the impact of link failures mentioned above, rapid recovery from link failures is crucial. Specifically, when a link fails, the ECMP group must be updated immediately to reflect that the specific link is no longer available. Furthermore, when a link is restored, the ECMP group must be updated immediately using the restored link, thereby improving network utilization.

[0035] As will be described in more detail below, the accelerated routing service can periodically monitor links. For example, inter-process communication (IPC) messages, such as Linux Netlink messages from the Linux kernel, can be used to monitor all ports in a specific ECMP group.

[0036] If a link fails (i.e., experiences a link failure), the accelerated routing service identifies the link as faulty and immediately updates the ECMP group by removing the link from the ECMP group. In other words, the accelerated routing service updates the ECMP group table to remove the faulty link. Once the ECMP group is updated, traffic can be distributed to other links in the ECMP group.

[0037] If a link recovers (i.e., no longer experiences link failure), the accelerated routing service will recognize the link as normal and immediately update the ECMP group by adding the link to it. In other words, the accelerated routing service updates the ECMP group in the routing table to add the recovered link (also known as the new link). Once the ECMP group is updated, traffic can be distributed to the new link and other links in the ECMP group.

[0038] Figure 1 This is a block diagram of a computing system 100 according to at least one embodiment, the computing system having multi-plane routing logic 102 for providing a virtual bridge 104 and multi-plane accelerated routing services 120. The computing system 100 includes a host device 118 and multiple network adapters 110. The host device 118 may be a server. In this embodiment, four network adapters 110 are shown, but other numbers of network adapters may also be used. The network adapters 110 may be network interface controllers (NICs), data processing units (DPUs), smart NICs, network interface devices, etc. Each network adapter 110 is coupled to a leaf switch of a network 112. The network 112 may be a public network (e.g., the Internet) or a private network (e.g., a local area network (LAN) or a wide area network (WAN)). In at least one embodiment, the computing system 100 is part of a data center, as described herein.

[0039] In at least one embodiment, the computing system 100 is located within a data center. Host device 118 refers to a computing device that runs applications, manages workloads, or provides services to clients or other systems. Host device 118 may be a physical server (e.g., rack server, blade server, tower server), a virtual machine (VM) (e.g., a VM hosted on a hypervisor), a bare-metal server, a cloud instance, a high-performance computing (HPC) node, an application server, a container host, a storage host, etc. Host device 118 may include memory 106 and one or more processors 108. Processor 108 may be one or more central processing units (CPUs), graphics processing units (GPUs), intelligent processing units (IPUs), accelerators (e.g., acceleration hardware engines), etc. Memory 106 may store instructions for the operating system 116, the accelerated routing service 120 supporting multi-plane routing, and the virtual bridge 104. Processor 108 may include multi-plane routing logic 102 supporting the accelerated routing service 120 and the virtual bridge 104. As will be described in detail below, processor 108 can host virtual bridge 104 and accelerated routing service 120 supporting multi-plane routing. Virtual bridge 104 (also known as a virtual switch) is software running in a computer network to connect different network segments or devices. It functions similarly to a physical network bridge but operates in a virtualized environment. It is a core component of network virtualization, enabling virtual machines (VMs), containers, and other virtual network interfaces to interconnect and connect to the physical network, thus fully simulating the functionality of a traditional Ethernet network through software. Virtual bridge 104 allows the creation and management of isolated network segments within a single physical infrastructure, facilitating communication, enforcing security policies, and providing bandwidth management, while also offering the flexibility and scalability required for dynamic virtualization and cloud environments. Virtual bridge 104 can be an Open vSwitch (OVS) bridge. As a virtual switch at the core of the Open vSwitch architecture, the OVS bridge enables advanced network management and connectivity in a virtualized environment. It works by aggregating multiple network interfaces into a single logical interface, thereby managing traffic flow between VMs on the same physical host and with external networks. Unlike traditional virtual bridges, OVS bridges support a variety of network functions, such as VLAN tagging, traffic monitoring using sFlow and NetFlow, Quality of Service (QoS), and Access Control Lists (ACLs), providing network administrators with greater flexibility and control. OVS bridges can efficiently route network traffic according to predefined policies and rules, making them an important tool for building complex multi-tenant cloud and data center networks.

[0040] Specifically, such as combining Figure 1As shown, virtual bridge 104 can provide network connectivity between VMs running on the same computing system 100 or on a separate host device, container, and / or physical device. In short, virtual bridge 104 allows VMs on a single physical host to communicate with each other and with network 112. Virtual bridge 104 can emulate the functionality of a physical network switch, but it runs at the software level of computing system 100. Virtual bridge 104 can manage network traffic data 114 and bootstrap data packets using ports between VMs on the same host or between VMs and the physical network. These ports can be configured with various policies, such as security settings, QoS rules, etc. Virtual bridge 104 can segment network traffic, thereby providing isolation between different virtual networks. Virtual bridge 104 can provide an interface between the virtualization environment and the physical network, allowing VMs to communicate with the outside world of their host. Virtual bridge 104 supports standard network protocols and functions such as VLAN tagging, Layer 2 (L2) forwarding, Layer 3 (L3) functions, tunneling transport protocols (such as Virtual Extended LAN (VXLAN), Generic Routing Encapsulation (GRE), and Geneve protocol), flow-based forwarding, OpenFlow support, integration with virtualization platforms (such as VMware, KVM, Xen, etc.) (providing network connectivity for virtual machines and containers), scalability, traffic monitoring and mirroring, security, multi-platform support (such as Linux, FreeBSD, Windows, etc.), and more. For Layer 2 switching, one or more virtual bridges 104 act as Layer 2 Ethernet switches, supporting the forwarding of Ethernet frames between different network interfaces (including virtual ports and physical ports). For Layer 3 routing, one or more virtual bridges 104 support Layer 3 IP routing, enabling them to route traffic between different IP subnets and perform IP-based forwarding. Virtual bridge 104 can support VLAN tagging and allow network traffic to be segmented into different VLANs using VLAN tagging. Virtual bridge 104 can use flow-based forwarding, where network flows are classified according to their characteristics and packet forwarding decisions are made based on flow rules, as well as enforcing security policies and access controls. OVS is commonly used in data center and cloud environments to provide network agility, flexibility, and automation. It plays a crucial role in creating and managing virtual networks, enabling network administrators to adapt to the ever-changing needs of modern dynamic data centers.

[0041] In at least one embodiment, the virtual bridge 104 may use OVS and OF technologies. The virtual bridge 104 may be controlled by a multi-plane accelerated routing service 120. The multi-plane accelerated routing service 120 may act as a network controller (also called a network service) to make decisions about how traffic should be routed through network 112. As described herein, a network controller (e.g., an SDN controller) is a centralized entity that manages traffic control over network devices. OF protocols can be used to interact directly with the forwarding planes of network devices (e.g., virtual or physical switches and routers). In at least one embodiment, the virtual bridge 104 may use flow tables containing rules about how packets should be handled. Each flow table contains a set of flow entries. Flow entries define how to handle packets that match specific criteria. An entry may contain three parts: a match field, an action, and a counter. The match field defines the packet attributes to be matched, such as source / destination Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, port numbers, VLAN tags, etc. The action may define how to handle the matched packet, such as forwarding it to a specific port, modifying fields in the packet, or discarding it. Counters can be used to track the number of packets and bytes in each flow. Because the virtual bridge 104 is virtualized, it can create rules at the software, data path (DP), and hardware levels. Rules created at the software level are called software (SW) rules or OF rules. Rules created at the DP level are called DP rules. Rules created at the hardware level are called hardware (HW) rules. When an SW rule is created, corresponding DP and HW rules are also created. The network controller can add, update, or delete flow entries, thereby changing configuration settings.

[0042] In another embodiment, the virtual bridge 104 is a standard virtual switch or a distributed virtual switch. In another embodiment, the virtual bridge 104 is an SDN-based switch integrated with an SDN controller. The computing system 100 can be used in data centers, cloud computing environments, development and testing environments, network function virtualization (NFV) environments, etc. The virtual bridge 104 can be used in data centers where server virtualization is prevalent to efficiently facilitate communication within and between servers. In cloud computing environments, the virtual bridge 104 can enable multi-tenant networks, allowing different clients to have isolated network segments. The virtual bridge 104 can allow the connection and management of network function virtualization (e.g., NFV) within a virtual infrastructure. Some advantages of the virtual bridge 104 include: easy configuration or reconfiguration of the virtual bridge 104 without physical intervention; reduced need for physical network hardware and its associated maintenance; and the ability to create isolated networks for different applications or tenants. In summary, the virtual bridge 104 is a software-based device that performs the networking functions of a physical switch in a virtualized environment (such as a data center or cloud computing environment) and provides flexibility, isolation, and efficient network management in the virtualized environment.

[0043] In at least one embodiment, the computing system 100 may also host one or more hypervisors and one or more virtual machines (VMs). Network traffic data 114 may be directed to the corresponding VMs via the virtual bridge 104.

[0044] During operation, the multiplane routing logic 102 can generate a virtual bridge 104 using a configuration file, which can be controlled by the multiplane-enabled accelerated routing service 120.

[0045] In at least one embodiment, computing system 100 stores operating system 116 (OS 116) in memory 106. Computing system 100 may execute OS 116 on one or more processors 108. In at least one embodiment, multi-plane routing logic 102 generates virtual bridge 104 and multi-plane accelerated routing service 120 as part of installing OS 116 on host device 118. In another embodiment, multi-plane routing logic 102 may generate virtual bridge 104 and multi-plane accelerated routing service 120 as part of the runtime of computing system 100 without reinstalling OS 116 on computing system 100. In at least one embodiment, multi-plane routing logic 102 may configure one or more routing rules in the virtual bridge according to a configuration file to allow accelerated routing services across multiple planes, as will be described in detail below.

[0046] like Figure 1As shown, the multi-plane routing logic 102 is implemented in the processor 108. In other embodiments, the multi-plane routing logic 102 can be implemented in the processor 108. Figure 1 The multiplane routing logic 102 is implemented in one or more processors 108. In other embodiments, the multiplane routing logic 102 may be implemented as software executed by host device 118. In other embodiments, the multiplane routing logic 102 may be implemented in a processor, computing system, CPU, DPU, smart NIC, IPU, etc. The underlying hardware may host a virtual bridge 104 and an accelerated routing service 120 with multiplane support.

[0047] In at least one embodiment, the computing system 100 can be deployed in a data center (DC) network or a service provider (SP) network. A data center (DC) network is a fundamental infrastructure that facilitates communication, data exchange, and connectivity between different computing resources, storage systems, and network devices within a data center. It is designed to support high-speed data transmission, reliable access to distributed resources, and efficient management of data flows across various physical and virtual platforms. At its core, a DC network integrates a large number of switches, routers, firewalls, and load balancers, coordinated by advanced network protocols and software-defined networking (SDN) technologies to ensure optimal performance, scalability, and security. The architecture of a DC network typically includes a physical backbone and a virtual overlay. The physical backbone uses high-capacity cabling and switches to ensure bandwidth and redundancy, while the virtual overlay enables flexibility, rapid configuration, and resource optimization through virtual networks. A well-designed DC network can support a wide range of applications, from enterprise services to cloud computing and big data analytics, by providing the infrastructure to handle the massive data volumes, complex computing, and application workloads typical of modern data centers. It plays a crucial role in disaster recovery, data replication, and high availability strategies, ensuring that data center services remain resilient in the face of failures and operate efficiently under various loads. Service Provider (SP) networks refer to large, high-capacity communications infrastructures operated by organizations that provide a wide range of telecommunications, internet, cloud computing, and digital services to businesses, residential users, and other entities. These networks are designed to provide broad coverage, connecting numerous geographic locations, including city centers, remote areas, and international destinations, to facilitate global communications and data exchange. SP networks have a multi-layered architecture, incorporating a hybrid of technologies such as fiber optics, wireless transmission, satellite links, and broadband access to achieve extensive connectivity. At the heart of these networks is a high-performance backbone network responsible for the high-speed transmission of massive amounts of data over long distances. On top of the physical infrastructure, SP networks deploy advanced network technologies, including MPLS, Software-Defined Networking (SDN), and Network Functions Virtualization (NFV), to enhance the efficiency, flexibility, and scalability of service delivery. Service Provider networks are designed to support a wide range of services, from traditional voice and data services to modern cloud applications and streaming services, to meet the evolving needs of similar consumers and businesses. They are crucial for the implementation of the internet, mobile communications, enterprise network solutions, and the emerging Internet of Things (IoT) ecosystem, ensuring connectivity and access to digital resources and services globally.

[0048] In at least one embodiment, host device 118 (or computing system 100) can provide accelerated routing service 120 with multi-plane support and virtual bridge 104 as a software layer in the software stack, as described below. Figure 2 As shown and described.

[0049] Figure 2 This is a block diagram of a software stack 200 of a host device according to at least one embodiment, the host device having a virtual bridge 104 and a multi-plane accelerated routing service 120. From a software perspective, the software stack 200 can support multiple logical ports 210 through a single physical port 212. The software stack 200 can be stored in... Figure 1 The software stack 200 is located in the memory of the host device 118 shown. It includes firmware 206, driver 204, virtual bridge 104, multi-plane accelerated routing service 120, and orchestration system 202. Firmware 206 can interact with hardware 208 and driver 204. Driver 204 can interact with firmware 206 and virtual bridge 104. Multi-plane accelerated routing service 120 can run on top of virtual bridge 104. The software stack 200 consists of instructions that, when executed by the host device, can provide multi-plane accelerated routing service 120 supporting multiple network protocols and network functions for multiple logical ports (multiple planes). Each logical port 210 corresponds to one of the multiple planes of physical port 212.

[0050] like Figure 2 As shown, hardware 208 includes one or more physical ports 212 (for simplicity, only four physical ports are shown in the figure). Each physical port 212 corresponds to a network adapter 110 (e.g., NIC, DPU, etc.). Each physical port 212 is coupled to a leaf switch 214. Physical ports 212 are coupled to the leaf switch 214 of the network. Hardware 208 may also contain other hardware, such as processing devices (e.g., one or more CPU cores), one or more GPUs, etc. It should be noted that the number of physical ports of DPU hardware may be more or less than four physical ports 212. In high-speed network environments, especially in data centers, high-speed physical ports 212 (e.g., 40Gbps or 100Gbps) are typically coupled to leaf switches 214 using cables. In some cases, split cables may also be used. Split cables can "split" high-speed ports (e.g., 40Gbps or 100Gbps) into multiple low-speed ports (e.g., 4 x 10Gbps or 4 x 25Gbps). These splitter cables physically separate data streams and allow multiple devices or ports to connect to a single high-speed interface.

[0051] In at least one embodiment, software stack 200 includes orchestration system 202. Orchestration system 202 can be used to install, deploy, and configure multi-plane-enabled accelerated routing service 120. Multi-plane-enabled accelerated routing service 120 can exchange control traffic (e.g., using control protocols such as Border Gateway Protocol (BPG)) with other routing services on other host devices to construct a multi-plane routing topology. Multi-plane-enabled accelerated routing service 120 can configure virtual bridge 104 based on control traffic using a first set of multi-plane routing rules, which specifies a first set of available data planes for each host device. Virtual bridge 104 can act as middleware between multi-plane-enabled accelerated routing service 120 and lower-level software layers (e.g., driver 204 and firmware 206). In at least one embodiment, virtual bridge 104 can be implemented as an OVS bridge. Driver 204 and firmware 206 can expose registers associated with the network adapter (physical port 212) for hardware multi-plane decision-making. The multi-plane accelerated routing service 120 can configure a set of logical ports 210 for each physical port 212. For example, each physical port 212 can be configured to support four logical ports 210. In other embodiments, each physical port 212 can be configured to support eight or sixteen logical ports 210. Each physical port 212 can also be configured with other numbers of logical ports. The multi-plane accelerated routing service 120 can define a set of routing rules in a routing table that specifies one of multiple planes. Planes (also called paths) can be selected using different methods, the most common being the use of hash values, which are typically based on source IP address / destination IP address, IP protocol, and Layer 4 (L4) source / destination ports. This hash value can be an Equal Cost Multipath (ECMP) hash value. ECMP is widely used in leaf-spine architectures to distribute traffic evenly among spine switches. It ensures high bandwidth and fault tolerance in large-scale data centers. By utilizing the software stack 200, which includes accelerated routing services 120 supporting multiple planes, the two-layer spine topology can be better utilized, thus avoiding the use of super spine switches in the three-layer spine topology, as will be described in detail below. The following will combine... Figure 3A and Figure 3B Examples of two-layer and three-layer ridge lobe topologies are shown and described respectively.

[0052] In another embodiment, the multi-plane accelerated routing service 120 can use control traffic to determine a failure from a first data plane in a first set of available data planes to a second target host device among a plurality of host devices. Based on this failure, the multi-plane accelerated routing service 120 can override the host device's hardware selection of the first data plane by selecting a second data plane from the remaining available data planes for the second target host device. The multi-plane accelerated routing service 120 can then use a virtual bridge to route the second packet to the second data plane.

[0053] In at least one embodiment, firmware 206 may be configured to generate multiple logical ports 210 as physical functions (PFs) and map the physical channels of physical ports 212 to different logical ports 210. In at least one embodiment, firmware 206 and driver 204 may present multiple logical ports 210 as PFs to virtual bridge 104 and multi-plane accelerated routing service 120. Multi-plane accelerated routing service 120 may be configured to manage each PF as a separate physical port, even if they are supported by a single physical port 212.

[0054] The multi-plane accelerated routing service 120 can configure different policies for different PFs. In at least one embodiment, a first logical port is configured with a first policy, and a second logical port is configured with a second policy different from the first policy. In at least one embodiment, different network functions may include L2 bridging, L3 routing, tunnel encapsulation, tunnel decapsulation, hash calculation, ECMP operation, static and dynamic ACLs, CT, etc. Similarly, different network functions can be performed for other logical ports (other PFs). After configuration, the hardware 208 can process network traffic data accordingly.

[0055] From a software perspective, software stack 200 can support ECMP for creating / deleting ECMP groups for multi-plane routing. Multi-plane accelerated routing service 120 can create ECMP groups (e.g., group 0, group 1, etc.). Each ECMP group can contain a set of identifiers (e.g., txid=0, txid=1, etc.). These identifier sets can be used in routing tables. Multi-plane accelerated routing service 120 can monitor the link status of each plane and modify the ECMP group accordingly. In at least one embodiment, multi-plane accelerated routing service 120 can receive a failure notification from an accelerated routing service on another host device. This failure notification can indicate a failure in one or more planes to that host device. Multi-plane accelerated routing service 120 can remove that plane from the ECMP group so that network traffic data destined for the target host device can be sent to the target host device through one of the available data planes. Similarly, when the plane has been restored or reverted, multi-plane accelerated routing service 120 can update the ECMP group so that network traffic data can be sent to the target host device using the restored plane.

[0056] In at least one embodiment, the multi-plane accelerated routing service 120 may include link monitoring logic that monitors the link availability of each link in multiple links (i.e., planes) leading to the destination. The multiple links may be part of an initial identifier group in a routing table or specified in an initial identifier group in a routing table. That is, the link monitoring logic can monitor link availability by monitoring all ports associated with the initial link identifier group. The link monitoring logic may detect a link failure of a first link in the multiple links. This link failure may also be referred to as a plane failure of the first plane in the multiple planes. The link monitoring logic may notify other logic in the multi-plane accelerated routing service 120 to remove the first link identifier associated with the first link from the initial link identifier group, thereby obtaining a modified link identifier group in the ECMP group table. The multi-plane accelerated routing service 120 may also prompt an update to the routing table to remove the first link identifier. Hardware 208 may process network traffic data and distribute the network traffic data to the remaining links (planes) corresponding to the modified identifier group.

[0057] In at least one embodiment, the virtual bridge 104 is controlled by a multi-plane accelerated routing service 120 hosted on host device 118. The multi-plane accelerated routing service 120 can use control protocols (such as BGP) to detect link (plane) failures. The multi-plane accelerated routing service 120 can update the virtual bridge 104 accordingly.

[0058] In at least one embodiment, the virtual bridge 104 can receive a first packet before a link failure occurs on the first link and perform an IP address lookup on the first packet to identify an ECMP group identifier associated with multiple links. The virtual bridge 104 can hash the ECMP group identifier to identify any one of the multiple links. The virtual bridge 104 can receive a second packet after a link failure occurs on the first link and perform an IP address lookup on the second packet to identify an ECMP group identifier. The virtual bridge 104 can hash the ECMP group identifier to identify any one of the remaining links.

[0059] In at least one embodiment, the multi-plane accelerated routing service 120 can monitor the link availability of each of the multiple links to the destination and detect the link recovery status of the first link. This link recovery can also be referred to as "plane recovery" of the first plane. The multi-plane accelerated routing service 120 can add the first link identifier to a modified link identifier group to obtain the initial link identifier group in the ECMP group table. The multi-plane accelerated routing service 120 can cause the routing table to be updated to add the first link identifier. Hardware 208 can process subsequent network traffic data and distribute the subsequent network traffic data to the multiple links corresponding to the initial identifier group. In at least one embodiment, the virtual bridge 104 can receive a first packet before the link recovery of the first link and perform an IP address lookup on the first packet to identify the ECMP group identifier associated with the multiple links. The virtual bridge 104 can hash the ECMP group identifier to identify any one of the remaining links. The virtual bridge 104 can receive a second packet after the link recovery of the first link and perform an IP address lookup on the second packet to identify the ECMP group identifier. The virtual bridge 104 can hash the ECMP group identifier to identify any one of the multiple links.

[0060] As mentioned above, the spine-leaf topology is a widely used data center network architecture designed to provide high bandwidth, scalability, and redundancy. Using a software stack 200 that includes accelerated routing services 120 supporting multiple planes, a two-layer spine-leaf topology can be better utilized, thus avoiding the use of super spine switches in a three-layer spine-leaf topology, as will be described in detail below. The following will combine... Figure 3A and Figure 3B Examples of two-layer and three-layer ridge lobe topologies are illustrated and described.

[0061] Figure 3AThis is a block diagram of a two-layer spine-leaf topology 300 according to at least one embodiment. The two-layer spine-leaf topology 300 includes a leaf layer 302 and a spine layer 304. The leaf layer 302 includes top-of-rack (ToR) switches connected to host devices (e.g., servers). The spine layer 304 includes high-speed switches connecting all the leaf switches of the leaf layer 302. The main advantages of the two-layer spine-leaf topology 300 are low latency, high bandwidth, and easy horizontal scaling by adding more spine switches or leaf switches. The low latency of the two-layer spine-leaf topology 300 is due to the fact that there are only two switch hops between any two host devices (e.g., servers). The high bandwidth of the two-layer spine-leaf topology 300 is achieved through ECMP forwarding. However, the two-layer spine-leaf topology 300 also has some limitations. Scaling becomes difficult when the number of leaf switches exceeds the port capacity of the spine switches, making it less suitable for large networks with thousands of racks and requiring that traffic between servers always pass through a single spine switch.

[0062] Figure 3B This is a block diagram of a three-layer spine-leaf topology 306 according to at least one embodiment. The three-layer spine-leaf topology 306 (also called a super-spine architecture or topology) comprises three layers: a leaf layer 302, a spine layer 304, and a super-spine layer 308 (also called a core layer), with the super-spine layer 308 connecting spine switches in different regions or nodes (pods) within the spine layer 304. This architecture achieves a multi-plane architecture by adding a super-spine, reducing port limitations at the spine layer, and distributing workloads across multiple structures, thus scaling to thousands of racks. However, compared to a two-layer spine-leaf topology 300, the three-layer spine-leaf topology 306 may introduce higher latency due to the additional hop. Routing and management of the three-layer spine-leaf topology 306 are more complex, and the cost is also higher due to the additional super-spine layer 308. Using the software stack 200, the number of ports per physical port can be increased, thereby achieving... Figure 4A The extension of the two-layer ridge topology 300 shown.

[0063] Figure 4A This is a block diagram of a multi-plane topology 400 according to at least one embodiment, wherein multiple NICs each support multiple planes. The multi-plane topology 400 is a two-layer ridge topology, similar to... Figure 3A The difference lies in that the multi-plane topology 400 uses the accelerated routing service 402, which supports multi-plane routing, to support multi-plane routing. For example... Figure 4AAs shown, the first host device 404 implements multi-plane support through an accelerated routing service 402 that supports multiple planes. The accelerated routing service 402 can support multiple planes on each NIC. In the example shown, there are four NICs: a first NIC 410, a second NIC 412, a third NIC 414, and a fourth NIC 416. Each of the four NICs supports four planes. In other examples, each of the four NICs can support eight, sixteen, or more planes. In other embodiments, more or fewer NICs can be used. It should also be noted that a DPU or other network adapters can be used instead of NICs.

[0064] In the multi-plane topology 400, each packet will be sent to one of the four (or eight, or sixteen) planes supported by the accelerated routing service 402. If all planes function correctly, such as... Figure 4A As shown, the NIC hardware can divide network traffic data into different planes. If one of the remote planes fails (i.e., cannot function), such as Figure 4B As shown, accelerated routing service 402 can identify the failure by exchanging control traffic (e.g., BGP traffic) with other routing services (e.g., accelerated routing service 406 of host device 408). In this example, a failure 438 occurs in the fourth plane between the fourth leaf switch 424 and the fourth NIC 436. That is, the connection between the fourth leaf switch 424 and host device 404 has failed. Accelerated routing service 406 can send control traffic containing a fourth plane failure notification to accelerated routing service 402. Accelerated routing service 406 can notify accelerated routing service 402 that the fourth plane has failed. Accelerated routing service 402 can use this failure notification to identify the plane failure 438. Accelerated routing service 402 can change the multi-plane routing rules so that the hardware (e.g., NICs 410 to 416) no longer sends network traffic data on the remaining three planes. Host devices 404 and 408 can only communicate with each other on the other three planes.

[0065] In this embodiment, each host device can communicate with other host devices in each of the four planes on each NIC. In other embodiments, each host device can communicate with other host devices in each of the eight or sixteen planes on each NIC. In at least one embodiment, the accelerated routing service 402 can provide end-to-end multi-plane support, utilizing DPU hardware to perform acceleration, including fault and recovery in the event of link failure. In other embodiments, the accelerated routing service 402 can utilize NIC acceleration to support multi-plane routing.

[0066] In at least one embodiment, host device 404 includes multiple network adapters (e.g., NICs, DPUs, etc.). Host device 404 can execute instructions for a virtual bridge and an accelerated routing service 402. Accelerated routing service 402 can exchange control traffic with other accelerated routing services executed by multiple host devices (e.g., accelerated routing service 406 of host device 408). Accelerated routing service 402 can configure the virtual bridge based on control traffic using a first set of multi-plane routing rules, which specify a first set of available data planes for each of the multiple host devices. The virtual bridge can configure the underlying hardware (e.g., registers) of the network adapters (e.g., NICs 410 to 416) using the first set of multi-plane routing rules. The first set of multi-plane routing rules can be a default rule set that assumes all planes have recovered and are functioning. The virtual bridge can receive a first packet destined for a first target host device (e.g., host device 408) and route the first packet to one of the first set of available data planes for the first target host device according to the first set of multi-plane routing rules.

[0067] In at least one embodiment, the accelerated routing service 402 may utilize control traffic to determine a first set of available data planes (e.g., Figure 4BPlane failure 438 in plane 4) to the first data plane of the first target host (e.g., host device 408) or the second target host device. It should be noted that while the first data plane to host device 408 may fail, the first data planes to other host devices may still be functional. Therefore, the accelerated routing service 406 needs to track the status of the planes to each target accordingly. In at least one embodiment, the accelerated routing service 402 can determine the plane failure 438 of the first data plane by receiving a failure notification from the accelerated routing service 406 of host device 408, indicating the plane failure 438. Alternatively, the notification of the plane failure 438 can also be sent by another accelerated routing service of another host device. The accelerated routing service 402 can modify the first set of multi-plane routing rules based on the plane failure 438 to obtain a second set of multi-plane routing rules, which specifies a second set of multi-plane routing rules for the second set of data planes available to the first target host device (or the second target host device). For example, accelerated routing service 402 can add a higher-priority rule to the first set of multi-plane routing rules, which controls the first packet to be sent on one of the available accelerated data planes (not the failed data plane). That is, the first data plane, which is one of the available data planes in the second set of available data planes, is not included. The virtual bridge can utilize the second set of multi-plane routing rules to configure the underlying hardware, such as registers, of the network adapter (e.g., NICs 410-416). Therefore, when the virtual bridge receives a second packet destined for a first target host device (or a second target host device), it routes the second packet to one of the second set of available data planes for the first target host device (or the second target host device) according to the second set of multi-plane routing rules. For example, host device 404 might route the second packet through one of the other three available planes instead of through the fourth plane where plane failure 438 occurred.

[0068] In at least one embodiment, the first packet is received before the first data plane failure 438 occurs, and the second packet is received after the first data plane failure 438 occurs. The virtual bridge can perform an IP address lookup on the first packet to identify an ECMP group identifier associated with a first set of available data planes of the first target host device. The virtual bridge can hash the ECMP group identifier to identify any one of the first set of available data planes (e.g., the first data plane, the second data plane, the third data plane, and the fourth data plane). The virtual bridge can perform an IP address lookup on the second packet to identify an ECMP group identifier, and can hash the ECMP group identifier to identify any one of the second set of available data planes (e.g., the first plane, the second plane, and the third plane, but excluding the fourth plane that failed 438).

[0069] In at least one embodiment, the accelerated routing service 402 can utilize control traffic to determine the recovery status of the first data plane to the first target host device (or the second target host). The accelerated routing service 402 can modify a second set of multi-plane routing rules based on this recovery status to obtain a first set of multi-plane routing rules that specifies the set of available data planes for the first target host device (or the second target host). The first set of available data planes includes the first data plane. The virtual bridge can utilize the first set of multi-plane routing rules to configure the underlying hardware, such as registers, of the network adapter (e.g., NICs 410 to 416). The virtual bridge can receive a third packet directed to the first target host device (or the second target host) and route the third packet to one of the first set of available data planes for the first target host device (or the second target host) according to the first set of multi-plane routing rules.

[0070] In at least one embodiment, the plurality of network adapters are a plurality of NICs, each NIC being coupled to one of a plurality of leaf switches. In at least one embodiment, the plurality of network adapters are a plurality of DPUs, each DPU being coupled to one of a plurality of leaf switches.

[0071] In at least one embodiment, the plurality of network adapters includes at least one of four, eight, or sixteen network adapters. The accelerated routing service 402 can configure each of the plurality of network adapters to support at least one of four, eight, or sixteen accelerated data planes based on control traffic, each accelerated data plane corresponding to a logical port, wherein the number of logical ports configured by the accelerated routing service is greater than the number of the plurality of network adapters.

[0072] In at least one embodiment, each of the available data planes in the set of available data planes leading to the first target host device (e.g., host device 408) provides a separate path to the first target host device. The virtual bridge can perform ECMP operations in response to each packet to be routed to the first target host device.

[0073] In at least one embodiment, host device 404 may include one or more processors and memory, the memory for storing instructions that, when executed by the one or more processors, can provide accelerated routing services and virtual bridges to perform operations, such as those described below. Figure 5 The operation described in method 500.

[0074] Figure 5 This is a flowchart of an example method 500 for providing accelerated multiplane routing to a target host device according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, switch, network device, GPU, NIC, CPU, etc. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled to the switch. In at least one embodiment, method 500 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In at least one embodiment, the processing threads executing method 500 can be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads executing method 500 can execute asynchronously with respect to each other. Various operations of method 500 can be performed differently from... Figure 5 The method is executed in the order shown. Some operations of the method can be executed concurrently with other operations. In at least one embodiment, Figure 5 One or more operations shown may not always be performed. In at least one embodiment, method 500 is... Figure 1 The method 500 is executed by a computing system 100, multiplane routing logic 102, processor 108, or accelerated routing service 120 with multiplane support and virtual bridge 104. In at least one embodiment, the method 500 is performed by... Figure 2 The software stack 200 or the accelerated routing service 120 with multi-plane support and the virtual bridge 104 are executed. In at least one embodiment, method 500 is performed by... Figure 4A and Figure 4B The host device 404, host device 408, accelerated routing service 402 or accelerated routing service 406 in the system are executed.

[0075] See Figure 5Method 500 first involves processing logic exchanging control traffic with other accelerated routing services executed by multiple host devices via an accelerated routing service executed by the host device (box 502). In box 504, the processing logic configures a virtual bridge executed by the host device based on the control traffic using a first set of multi-plane routing rules, which specifies a first set of available data planes for each of the multiple host devices. In box 506, the processing logic uses the virtual bridge to configure registers associated with the multiple network adapters using the first set of multi-plane routing rules. In box 508, the processing logic receives a first packet at the virtual bridge destined for a first target host device among the multiple host devices. In box 510, the processing logic routes the first packet to one of the first set of available data planes for the first target host device using the virtual bridge, according to the first set of multi-plane routing rules.

[0076] In another embodiment, the processing logic utilizes accelerated routing services and control traffic to determine a failure from a first data plane in a first set of available data planes to a second target host device among a plurality of host devices. The second target host device may be the first target host device described above. In at least one embodiment, the processing logic determines the failure by receiving a failure notification from the accelerated routing service of another host device. In at least one embodiment, the processing logic modifies the first set of multi-plane routing rules based on the failure to obtain a second set of multi-plane routing rules that specify a second set of multi-plane routing rules for a second set of available data planes for the second target host device. The second set of available data planes does not include the first data plane. The processing logic uses a virtual bridge and configures registers using the second set of multi-plane routing rules. The processing logic receives a second packet directed to the second target host device at the virtual bridge. The processing logic routes the second packet to one of the second set of available data planes for the second target host device using the virtual bridge, according to the second set of multi-plane routing rules.

[0077] In at least one embodiment, a first packet is received before a first data plane failure, and a second packet is received after a first data plane failure. In this embodiment, processing logic performs an IP address lookup on the first packet to identify an ECMP group identifier associated with a first set of available data planes for a first target host device. The processing logic hashes the ECMP group identifier to identify any one of the first set of available data planes. The processing logic performs an IP address lookup on the second packet to identify an ECMP group identifier. The processing logic hashes the ECMP group identifier to identify any one of the second set of available data planes.

[0078] In another embodiment, the processing logic utilizes accelerated routing services and control traffic to determine recovery of the first data plane to the second target host device. Based on the recovery status, the processing logic modifies a second set of multi-plane routing rules to obtain a first set of multi-plane routing rules that specifies the set of available data planes for the second target host device. The first set of available data planes includes the first data plane. The processing logic uses a virtual bridge to configure registers using the first set of multi-plane routing rules. At the virtual bridge, the processing logic receives a third packet destined for the second target host device. Based on the first set of multi-plane routing rules, the processing logic uses the virtual bridge to route the third packet to one of the first set of available data planes for the second target host device.

[0079] In at least one embodiment, a third packet is received before the first data plane is restored, and a fourth packet is received after the first data plane is restored. In this embodiment, the processing logic performs an IP address lookup on the third packet to identify an ECMP group identifier associated with a second set of available data planes for the first target host device. The processing logic hashes the ECMP group identifier to identify any one of the first set of available data planes. The processing logic performs an IP address lookup on the second packet to identify an ECMP group identifier. The processing logic hashes the ECMP group identifier to identify any one of the first set of available data planes.

[0080] In at least one embodiment, the method further includes: using accelerated routing services and control traffic to determine a failure from a first data plane in a first set of available data planes to a second target host device among a plurality of host devices. Based on the failure, the method replaces the host device hardware's selection of the first data plane with the selection of a second data plane from the remaining available data planes of the second target host. The method utilizes a virtual bridge to route the second packet to the second data plane.

[0081] Figure 6An example computer system 600 according to at least some embodiments is illustrated, the computer system including a multi-plane accelerated routing service 120. In at least one embodiment, the computer system 600 may be a system, a SoC, or a combination thereof having interconnect devices and components. In at least one embodiment, the computer system 600 comprises a processor 602, which may include an execution unit for executing instructions. In at least one embodiment, the computer system 600 may include, but is not limited to, a component, such as the processor 602, that utilizes the execution unit containing logic to execute algorithms for processing data. In at least one embodiment, the computer system 600 may include a PENTIUM® processor family, Xeon™, Itanium®, XScale™ and / or StrongARM™, Intel® Core™, or Intel® Nervana™ microprocessor provided by Intel Corporation, Santa Clara, California, although other systems (including PCs, engineering workstations, set-top boxes, etc.) may also be used. In at least one embodiment, the computer system 600 may run a version of the Windows operating system provided by Microsoft Corporation, located in Redmond, Washington, although other operating systems (such as UNIX and Linux), embedded software, and / or graphical user interfaces may also be used.

[0082] In at least one embodiment, the computer system 600 can be used with other devices, such as handheld devices and embedded applications. Some examples of handheld devices include mobile phones, Internet Protocol devices, digital cameras, personal digital assistants (“PDAs”), and handheld PCs. In at least one embodiment, the embedded application may include a microcontroller, a digital signal processor (DSP), a system-on-a-chip (SoC), a network computer (“NetPC”), a set-top box, a network hub, a wide area network (“WAN”) switch, or any other system capable of executing one or more instructions. In one embodiment, the computer system 600 can be used with devices such as a graphics processing unit (GPU), a network adapter, a central processing unit, and network devices such as switches, such as high-speed GPU-to-GPU direct interconnects like the NVIDIA GH100NVLINK or the NVIDIA Quantum2 64-port InfiniBand NDR switch.

[0083] In at least one embodiment, computer system 600 may include, but is not limited to, processor 602, which may include, but is not limited to, one or more execution units 604 configured to execute Unified Computing Device Architecture (“CUDA”) programs (CUDA® is developed by NVIDIA Corporation, Santa Clara, California). In at least one embodiment, a CUDA program is at least a part of a software application written using the CUDA programming language. In at least one embodiment, computer system 600 is a single-processor desktop or server system. In at least one embodiment, computer system 600 may be a multiprocessor system. In at least one embodiment, processor 602 may include, but is not limited to, a CISC microprocessor, a RISC microprocessor, a VLIW microprocessor, a processor implementing instruction set combinations, or any other processor device, such as a digital signal processor. In at least one embodiment, processor 602 may be coupled to a processor bus 607 that can transmit data signals between processor 602 and other components in computer system 600.

[0084] In at least one embodiment, processor 602 may include, but is not limited to, a Level 1 (“L1”) internal cache memory (“cache”) 622. In at least one embodiment, processor 602 may have a single internal cache or multiple internal caches. In at least one embodiment, the cache memory may be located external to processor 602. In at least one embodiment, processor 602 may also include a combination of internal and external caches. In at least one embodiment, register file 603 may store different types of data in various registers, including but not limited to integer registers, floating-point registers, status registers, and instruction pointer registers.

[0085] In at least one embodiment, execution unit 604 (including, but not limited to, logic for performing integer and floating-point operations) is also located in processor 602. Processor 602 may also include microcode (“ucode”) read-only memory (“ROM”) for storing microcode of certain macro instructions. In at least one embodiment, execution unit 604 may include logic for processing packaged instruction set 606. In at least one embodiment, by including packaged instruction set 606 and associated circuitry for executing instructions in the instruction set of general-purpose processor 602, operations used by many multimedia applications can be performed using packaged data in general-purpose processor 602. In at least one embodiment, by using the full width of the processor data bus to perform operations on packaged data, many multimedia applications can be accelerated and their execution efficiency improved, thereby avoiding the need to transfer smaller data units across the processor data bus to perform one or more operations each time a data element is processed.

[0086] In at least one embodiment, the execution unit 605 may also be used as a microcontroller, embedded processor, graphics device, DSP, and other types of logic circuitry. In at least one embodiment, the computer system 600 may include, but is not limited to, the memory 612. In at least one embodiment, the memory 612 may be implemented as a DRAM device, an SRAM device, a flash memory device, or other memory device. The memory 612 may store instructions 623 and / or data 613 represented by data signals, which may be executed by the processor 602.

[0087] In at least one embodiment, the system logic chip may be coupled to processor bus 607 and memory 612. In at least one embodiment, the system logic chip may include, but is not limited to, a memory controller hub (“MCH”) 610, and processor 602 may communicate with MCH 610 via processor bus 607. In at least one embodiment, MCH 610 may provide a high-bandwidth memory path 611 to memory 612 for storing instructions and data, as well as storing graphics commands, data, and textures. In at least one embodiment, MCH 610 may route data signals between processor 602, memory 612, and other components in computer system 600, and may bridge data signals between processor bus 607, memory 612, and system I / O 624. In at least one embodiment, the system logic chip may provide a graphics port for coupling to a graphics controller. In at least one embodiment, MCH 610 may be coupled to memory 612 via high-bandwidth memory path 611, and graphics / video card 608 may be coupled to MCH 610 via Accelerated Graphics Port (“AGP”) interconnect 609.

[0088] In at least one embodiment, computer system 600 may use system I / O 624 (a proprietary hub interface bus) to couple MCH 610 to I / O controller hub (“ICH”) 620. In at least one embodiment, ICH 620 may provide direct connectivity to certain I / O devices via a local I / O bus. In at least one embodiment, the local I / O bus may include, but is not limited to, a high-speed I / O bus for connecting peripheral devices to memory 612, chipset, and processor 602. Examples may include, but are not limited to, audio controller 619, firmware hub (“flash BIOS”) 726, wireless transceiver 617, data storage device 615, a conventional I / O controller 614 including user input interface 616, keyboard interface, serial expansion port 618 (e.g., USB), and network controller 621. In at least one embodiment, network controller 621 includes accelerated routing service 120 supporting multiplanes. In at least one embodiment, processor 602 includes accelerated routing service 120 supporting multiplanes. In at least one embodiment, instruction 623 performs operations of the multi-plane accelerated routing service 120. Data storage device 615 may include a hard disk drive, floppy disk drive, CD-ROM device, flash memory device, or other mass storage device.

[0089] In at least one embodiment, Figure 6 A system is shown that includes interconnected hardware devices or "chips". In at least one embodiment, Figure 6 An example SoC can be shown. In at least one embodiment, Figure 6 The devices shown can be interconnected via proprietary interconnects, standardized interconnects (such as PCIe), or some combination thereof. In at least one embodiment, one or more components of system 601 are interconnected using a compute fast link (“CXL”) interconnect.

[0090] Figure 7This is a block diagram of a computing system 700 according to at least one embodiment, which has two mutually coupled processing devices and multiple networks. The computing system 700 is designed with multiple integrated circuits (referred to as processing devices), each including a CPU and two GPUs, forming a powerful and flexible architecture. These processing devices are interconnected via NVLink (or other high-speed interconnects) to enable high-speed communication between the processing devices, and are also connected via NICs or data processing units (DPUs) to ensure efficient data transfer within the computing system 700. The NVLink coupling of the processing devices enables seamless data exchange and parallel processing, thereby improving overall computing performance. Furthermore, these processing devices are connected to multiple networks via one or more NICs or DPUs, enabling the system to handle complex multi-network tasks with high bandwidth and low latency. This configuration makes the computing system 700 ideal for demanding applications requiring powerful processing capabilities, such as artificial intelligence (AI), machine learning (ML), and data-intensive computing, while ensuring strong connectivity and scalability in various network environments. The integrated circuits of the computing system 700 may include one or more CPUs and one or more GPUs. Figure 7 The diagram illustrates an example architecture for a multi-GPU architecture.

[0091] like Figure 7 As illustrated, the computing system 700 includes a processing device 702 with a multi-GPU architecture. Specifically, the processing device 702 includes a CPU 706, a GPU 708, and a GPU 710. The CPU 706 can be coupled to the GPU 708 via die-to-die (D2D) or chip-to-chip (C2C) interconnects 712 (such as a Ground Reference Signalling Interconnect (GRS interconnect)). The CPU 706 can be coupled to the GPU 710 via a D2D or C2C interconnect 714. The CPU 706 can also be coupled to the GPU 708 and GPU 710 via a PCIe interconnect. The CPU 706 can be coupled to one or more NICs or data processing units (DPUs), which in turn are coupled to one or more networks. For example, as... Figure 7 As illustrated, CPU 706 is coupled to a first NIC / DPU 726, which in turn is coupled to network 730. CPU 706 is also coupled to a second NIC / DPU 728, which is also coupled to network 730. NIC / DPU 726 and NIC / DPU 728 can be coupled to network 730 via Ethernet (ETH) or InfiniBand (IB) connections.

[0092] The computing system 700 also includes a processing device 704 with a multi-GPU architecture. Specifically, the processing device 704 includes a CPU 716, a GPU 718, and a GPU 720. The CPU 716 can be coupled to the GPU 718 via a D2D or C2C interconnect 722. The CPU 716 can be coupled to the GPU 720 via a D2D or C2C interconnect 724. The CPU 716 can also be coupled to the GPU 718 and GPU 720 via a PCIe interconnect. The CPU 716 can be coupled to one or more NICs or DPUs, which in turn are coupled to one or more networks. For example, as... Figure 7 As illustrated, CPU 716 is coupled to a first NIC / DPU 732, which in turn is coupled to network 736. CPU 716 is also coupled to a second NIC / DPU 734, which is also coupled to network 736. NIC / DPU 732 and NIC / DPU 734 can be coupled to network 736 via Ethernet (ETH) or InfiniBand (IB) connections.

[0093] In at least one embodiment, processing device 702 and processing device 704 can communicate with each other via NIC / DPU 738 (such as via PCIe interconnect). Processing device 702 and processing device 704 can also communicate with each other via high-bandwidth communication interconnect 740 (such as NVLink interconnect or other high-speed interconnect).

[0094] Figure 7 The NIC / DPU in this paper can be combined Figures 1 to 6 Various embodiments of the DPU described herein.

[0095] In at least one embodiment, the computing system 700 is used for high-speed network communication and includes a processing unit (e.g., CPU 706, GPU 708, GPU 710, CPU 716, GPU 718, GPU 720, NIC / DPU 726, NIC / DPU 728, NIC / DPU 732, NIC / DPU 734, or NIC / DPU 738) and a network interface coupled to the processing unit. The computing system 700 may include the operation and functionality of the accelerated routing service 120 with multi-plane support as described herein.

[0096] In at least one embodiment, the computing system 700 includes a host device and an auxiliary device. The auxiliary device includes a device memory and a processor communicatively coupled to the device memory. The auxiliary device performs the functions described herein. Figures 1 to 6 Related operations. Auxiliary devices may include GPUs. Auxiliary devices may include DPUs. Auxiliary devices may include accelerator hardware.

[0097] Figure 8 This is a block diagram of a computing system 800 having a CPU 802 and a GPU 804 on a single integrated circuit, according to at least one embodiment. The computing system 800 can be a highly integrated design where the CPU 802 and GPU 804 are connected on a single integrated circuit, thereby enabling fast, low-latency communication between the two processing units using an NVLink C2C (chip-to-chip) interconnect 806. This tight integration allows for efficient data transfer and parallel processing between the CPU 802 and GPU 804, thereby optimizing the execution of complex computational tasks. The GPU elements within the computing system 800 can be interconnected using an NVLink network, allowing for scalability of up to 256 GPU elements, creating a robust and unified processing environment particularly suitable for large-scale AI, ML, and high-performance computing applications. The NVLink network can be a GPU construct with a high-bandwidth communication interconnect 810. Additionally, the computing system 800 can be designed to interface with high-speed I / O via a PCIe interconnect 808, thereby ensuring fast data transfer with external devices, further enhancing the system's ability to handle data-intensive tasks, and providing robust connectivity to peripheral components. It should be noted that since the CPU 802 and GPU 804 reside on the same integrated circuit, the C2C interconnect 806 can be considered a D2D interconnect. The integrated circuit may include CPU memory (also referred to as main memory) and GPU memory, and the CPU 802 and GPU 804 can access the CPU memory and GPU memory respectively via a high-speed interconnect. The computing system 800 can integrate the performance of the GPU 804 with the versatility of the CPU 802. The CPU 802 can be connected to the high-bandwidth and memory-coherent C2C interconnect 806 within a single integrated circuit. The computing system 800 can support a link-switching system.

[0098] The computing system 800 can be used in conjunction with this paper. Figures 1 to 7 The various embodiments described herein.

[0099] In at least one embodiment, the computing system 800 is used for high-speed network communication and includes a processing unit and a network interface coupled to the processing unit. The computing system 800 may include the operation and functionality of the accelerated routing service 120 with multi-plane support described herein.

[0100] In at least one embodiment, the computing system 800 includes a host device and an auxiliary device. The auxiliary device includes a device memory and a processor, the processor being communicatively coupled to the device memory. The auxiliary device performs the functions described herein. Figures 1 to 7 The operation described herein. The auxiliary device may include a GPU. The auxiliary device may include a DPU. The auxiliary device may include a DPU. The auxiliary device may include accelerator hardware.

[0101] Figure 9 This is a block diagram of a computing system 900 having a tensor core GPU 908 according to at least one embodiment. The computing system 900 may be a DGX H100 system, which is a high-performance computing platform designed to meet the needs of AL, ML, and deep learning (DL) workloads. The computing system 900 may include multiple tensor core GPUs 908 (e.g., NVIDIA H100 tensor core GPUs). Each tensor core GPU 908 may be one of the aforementioned... Figure 8 One of the integrated circuits described is the Tensor Core GPU 908, which is optimized for AI / ML / DL applications, delivering superior performance for deep learning training, inference, and high-performance computing tasks. The Tensor Core GPUs 908 within the Computing System 900 are interconnected using high-speed communication interfaces such as NVLink, enabling rapid data transfer between them, crucial for handling large-scale AI models and datasets with low latency. The Computing System 900 is designed for scalability, allowing for the integration of additional GPUs as needed, making it sufficiently versatile for research, development, and deployment in data centers used for production AI workloads. Each GPU is equipped with a Tensor Core, a dedicated processing unit that accelerates matrix operations and is a fundamental component of AI and deep learning algorithms. These Tensor Cores enable the system to perform mixed-precision computations efficiently, balancing speed and accuracy. Given the power consumption and heat generation of multiple Tensor Core GPUs 908, the Computing System 900 can include advanced cooling solutions and power management features to ensure safe operation while maintaining peak performance. It is powered by a comprehensive software ecosystem that includes NVIDIA's CUDA programming model, AI frameworks such as TensorFlow and PyTorch, and other HPC and AI software tools that enable developers and researchers to leverage the full power of the TensorCore GPU 908 for their specific applications. The Computing System 900 is ideally suited for large-scale AI model training, real-time inference, scientific simulations, data analysis, and other compute-intensive tasks requiring significant parallel processing power.

[0102] The Tensor Core GPU 908 can be coupled to multiple CPUs, such as CPU 902 and CPU 904, using a switch 906 (e.g., a CX7 HCA / NIC with a PCIe switch). The Tensor Core GPU 908 can be coupled to each other via a switch 910 (e.g., an NVSwitch). Switches 906 and 910 can be coupled to a high-speed transceiver module 912. The high-speed transceiver module 912 can be an Octal Small Pluggable (OSFP) module. OSFP modules are high-speed transceiver modules designed for fast data communication, specifically in environments requiring high bandwidth, such as data centers and high-performance computing systems. These modules support extremely high data rates, typically up to 400 Gbps per module, with future expansion capabilities to 800 Gbps or higher. OSFP modules interface with the system via a PCIe interface, enabling fast and efficient data transfer between the integrated CPU-GPU components and external networks or other connected systems. Their hot-swappable nature allows for easy insertion or removal without shutting down the system, providing flexibility and maintainability crucial in critical uptime environments. Additionally, OSFP modules are designed for high density, maximizing the number of high-speed connections within limited spaces, such as densely packed server racks. By complying with the latest networking standards, OSFP modules ensure that the Compute System 900 can meet ever-increasing data demands and can be upgraded to support future network speed increases, thus contributing to improved overall system performance and scalability.

[0103] In at least one embodiment, the computing system 900 can be viewed as a data network configuration with full-bandwidth in-server NVLink. In this example, all eight tensor core GPUs 908 can simultaneously saturate eighteen NVLinks of other GPUs within the server. Bandwidth is limited by oversubscription from multiple other GPUs. In another embodiment, the data network configuration can be half-bandwidth in-server NVLink. In this example, all eight tensor core GPUs 908 can half-subscribe to eighteen NVLinks from GPUs in other servers. Four tensor core GPUs 908 can saturate eighteen NVLinks of GPUs in other servers. This is equivalent to full bandwidth on full reduction (AllReduce) with a scalable hierarchical aggregation and reduction protocol (SHARP). The reduction of all-to-all (all-2-all, All2All) bandwidth is a trade-off between server complexity and cost. In at least one embodiment, all eight tensor core GPUs 908 can independently transmit data in a multi-track InfiniBand / Ethernet configuration using the Remote Direct Memory Access (RDMA) protocol via their own dedicated switches (e.g., 400Gb / s HCA / NIC). In this example, the total full-duplex bandwidth for non-NVLink network devices is 800 GB / s.

[0104] The NIC / switch of the computing system 900 may include those described in this article. Figures 1 to 8 The various embodiments described herein.

[0105] In at least one embodiment, the computing system 900 is used for high-speed network communication and includes processing units (e.g., CPU 902, CPU 904, switch 906, tensor core GPU 908, switch 910, high-speed transceiver module 912) and network interfaces coupled to the processing units. The computing system 900 may include the operation and functionality of the accelerated routing service 120 with multi-plane support as described herein.

[0106] In at least one embodiment, the computing system 900 includes a host device and an auxiliary device. The auxiliary device includes a device memory and a processor, the processor being communicatively coupled to the device memory. The auxiliary device performs the functions described herein. Figures 1 to 9 The operation described herein. The auxiliary device may include a GPU. The auxiliary device may include a DPU. The auxiliary device may include a DPU. The auxiliary device may include accelerator hardware.

[0107] Other variations are within the spirit of this disclosure. Therefore, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments are shown in the accompanying drawings and have been described in detail above. However, it should be understood that this disclosure is not intended to be limited to one or more specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of this disclosure as defined by the appended claims.

[0108] Unless otherwise indicated herein or obviously contradicted by the context, the terms “a,” “an,” and “the,” and similar designations, used in the context of describing the disclosed embodiments (especially in the context of the following claims), should be interpreted as encompassing both the singular and plural, and not as definitions of the terms. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” are to be interpreted as open-ended terms (meaning “including, but not limited to”). The term “connection,” when unmodified and referring to a physical connection, is to be interpreted as partially or completely contained, attached to, or combined, even with intervening elements. Unless otherwise indicated herein, statements of value ranges herein are intended only as a shorthand for individually referring to each individual value falling within the range, and each individual value is incorporated into the specification as if it were individually stated herein. Unless otherwise indicated or contradicted by the context, the use of the terms “set” (e.g., “item set”) or “subset” is to be interpreted as a non-empty set comprising one or more members. Furthermore, unless otherwise indicated or contradicted by the context, the term "subset" in the context of a corresponding set does not necessarily mean a proper subset of the corresponding set, but rather that a subset and the corresponding set can be equal.

[0109] Unless explicitly stated otherwise or clearly contradicted by the context, connective language (such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C") is otherwise understood, along with the context, as generally used to represent any non-empty subset of a set, such as items, terms, etc., that can be A or B or C, or A and B and C. For example, in an illustrative example of a set with three members, the connective phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Therefore, such connective language is generally not intended to imply that certain embodiments require the existence of at least one of A, at least one of B, and at least one of C. Additionally, unless otherwise indicated by or contradicted by the context, the term "multiple" indicates a state of multiple (e.g., "multiple items" indicates many items). Multiple means at least two items, but can be more when explicitly indicated or indicated by the context. Furthermore, unless otherwise stated or clearly implied by the context, the phrase “based on” means “at least partially based on” rather than “based on only”.

[0110] Unless otherwise indicated herein or clearly contradicted by the context, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, processes such as those described herein (or variations and / or combinations thereof) are executed under the control of one or more computer systems configured with executable instructions and are implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that executes jointly on one or more processors. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that does not include transient signals (e.g., propagation of transient electrical or electromagnetic transmissions) but includes non-transitory data storage circuitry (e.g., buffers, caches, and queues) within a transceiver that includes transient signals. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory computer-readable storage media (or other memory for storing executable instructions) that, when executed by one or more processors of a computer system (i.e., due to being executed), cause the computer system to perform the operations described herein. In at least one embodiment, the set of non-transitory computer-readable storage media comprises a plurality of non-transitory computer-readable storage media, and one or more of the various non-transitory storage media lack all the code, while the plurality of non-transitory computer-readable storage media collectively store all the code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors; i.e., for example, the non-transitory computer-readable storage media store the instructions, and the main CPU executes some of the instructions, while the GPU executes others. In at least one embodiment, different components of the computer system have separate processors, and different processors execute different subsets of instructions.

[0111] Therefore, in at least one embodiment, the computer system is configured to implement one or more services that individually or collectively perform the processes described herein, and such a computer system is configured with applicable hardware and / or software capable of performing the operations. Further, the computer system implementing at least one embodiment of this disclosure is a single device, and in another embodiment, it is a distributed computer system comprising multiple devices that operate in different ways such that the distributed computer system performs the operations described herein, and that a single device does not perform all the operations.

[0112] The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended only to better illustrate embodiments of this disclosure and, unless otherwise required, does not constitute a limitation on the scope of the disclosure. No language in the specification should be construed as indicating that any unclaimed element is essential for implementing this disclosure.

[0113] All references cited herein, including publications, patent applications and patents, are incorporated herein by reference to the same extent that each reference is separately and specifically indicated to be incorporated by reference and fully elaborated herein.

[0114] The terms “coupled” and “connected” and their derivatives may be used in the specification and claims. It should be understood that these terms are not intended to be synonyms with each other. Rather, in specific examples, “connected” or “coupled” can be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. “Coupled” can also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0115] Unless otherwise explicitly stated, it should be understood throughout this specification that terms such as “processing,” “computing,” “calculating,” “determining,” etc., refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulate and / or transform data representing physical (such as electronic) quantities in the registers and / or memory of the computing system into other data representing physical quantities in the memory, registers, or other such information storage, transmission, or display devices of the computing system.

[0116] Similarly, the term "processor" can refer to any device or part of a device that processes electronic data from registers and / or memory and transforms that electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" can be a CPU or a GPU. A "computing platform" can include one or more processors. As used herein, a "software" process can include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Furthermore, each process can refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. The terms "system" and "method" are used interchangeably herein, provided that a system can embody one or more methods and a method can be considered a system.

[0117] This document describes the process of acquiring, obtaining, receiving, or inputting analog or digital data into a subsystem, computer system, or computer implementation machine. Acquiring, obtaining, receiving, or inputting analog and digital data can be accomplished in various ways, such as by receiving data as a parameter to a function call or a call to an application programming interface (API). In some implementations, the process of acquiring, obtaining, receiving, or inputting analog or digital data can be accomplished by transmitting data via a serial or parallel interface. In another implementation, the process of acquiring, obtaining, receiving, or inputting analog or digital data can be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. Reference can also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be accomplished by transmitting data as an input or output parameter to a function call, an API, or an inter-process communication mechanism.

[0118] While the foregoing discussion illustrates exemplary implementations of the described technologies, other architectures may also be used to implement the aforementioned functionality and are intended to fall within the scope of this disclosure. Furthermore, although specific assignments of responsibilities have been defined above for discussion purposes, various functions and responsibilities may be distributed and divided in different ways depending on the circumstances.

[0119] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms for implementing the claims.

Claims

1. A computing system, comprising: Multiple network adapters; as well as A host device, comprising a processing device and a memory for storing instructions, which, when executed by the processing device, provide virtual bridge and accelerated routing services to route packets through multiple accelerated data planes of each of the plurality of network adapters, wherein: The accelerated routing service is used to exchange control traffic with other accelerated routing services executed by multiple host devices; The accelerated routing service is used to configure the virtual bridge based on the control traffic using a first set of multi-plane routing rules, wherein the first set of multi-plane routing rules specifies a first set of available data planes for each of the plurality of host devices; The virtual bridge is used to configure registers associated with the plurality of network adapters using the first set of multiplane routing rules; and The virtual bridge is used to receive a first packet directed to a first target host device among the plurality of host devices, and to route the first packet to an available data plane in the first set of available data planes for the first target host device according to the first set of multi-plane routing rules.

2. The computing system as described in claim 1, wherein, The accelerated routing service is used for: The control flow is used to determine the fault of the first data plane in the first group of available data planes to the second target host device among the plurality of host devices; as well as Based on the fault, the first set of multi-plane routing rules is modified to obtain a second set of multi-plane routing rules. This second set of multi-plane routing rules specifies a second set of available data planes for the second target host device, wherein the second set of available data planes does not include the first data plane, and wherein the virtual bridge is used for: Configure the register using the second set of multiplane routing rules; Receive the second packet directed to the second target host device; and According to the second set of multi-plane routing rules, the second packet is routed to one of the available data planes in the second set of available data planes for the second target host device.

3. The computing system as described in claim 2, wherein, The first packet is received before the failure of the first data plane, and the second packet is received after the failure of the first data plane, wherein the virtual bridge is used for: Perform an Internet Protocol IP address lookup on the first packet to identify the ECMP group identifier associated with the first group of available data planes for the first target host device; The ECMP group identifier is hashed to identify any one of the first group of available data planes; Perform an IP address lookup on the second packet to identify the ECMP group identifier; and The ECMP group identifier is hashed to identify any of the second group of available data planes.

4. The computing system as described in claim 2, wherein, In order to determine a fault in the first data plane, the accelerated routing service receives a fault notification indicating a fault in the first data plane from one of the other accelerated routing services.

5. The computing system as described in claim 2, wherein, The accelerated routing service is used for: The control flow is used to determine the recovery from the first data plane to the second target host device; Based on the restoration, the second set of multi-plane routing rules is modified to obtain the first set of multi-plane routing rules, which specifies the set of available data planes for the second target host device, wherein the first set of available data planes includes the first data plane; and wherein the virtual bridge is used for: Configure the register using the first set of multiplane routing rules; Receive the third packet directed to the second target host device; and According to the first set of multi-plane routing rules, the third packet is routed to one of the available data planes in the first set of available data planes for the second target host device.

6. The computing system as claimed in claim 1, wherein, The multiple network adapters are multiple network interface controllers (NICs), each NIC being coupled to one of the multiple leaf switches.

7. The computing system as claimed in claim 1, wherein, The multiple network adapters are multiple data processing units (DPUs), and each NIC is coupled to one of the multiple leaf switches.

8. The computing system as claimed in claim 1, wherein, The plurality of network adapters includes at least one of four, eight, or sixteen network adapters, and wherein the accelerated routing service is configured, based on the control traffic, to support at least one of four, eight, or sixteen accelerated data planes, each accelerated data plane corresponding to a logical port, wherein the number of logical ports configured by the accelerated routing service is greater than the number of the plurality of network adapters.

9. The computing system as claimed in claim 1, wherein, When executed by the processing device, the instructions are also used to provide an orchestration system for installing, deploying, and configuring the accelerated routing service, wherein the virtual bridge is used to run middleware between the accelerated routing service and the driver and firmware, wherein the driver and firmware are used to expose the registers to the virtual bridge.

10. The computing system of claim 1, wherein, Each of the available data planes in the set of available data planes to the first target host device provides an independent path to the first target host device, and wherein the virtual bridge is configured to perform an equal cost multipath (ECMP) operation in response to each packet to be routed to the first target host device.

11. A method comprising: Control traffic is exchanged with other accelerated routing services performed by multiple host devices through the accelerated routing service executed by the host device; Based on the control traffic, a virtual bridge executed by the host device is configured using a first set of multi-plane routing rules, wherein the first set of multi-plane routing rules specifies a first set of available data planes for each of the plurality of host devices; Using the virtual bridge, registers associated with multiple network adapters are configured using the first set of multiplane routing rules; At the virtual bridge, a first packet is received that is directed to a first target host device among the plurality of host devices; as well as According to the first set of multi-plane routing rules, the virtual bridge is used to route the first packet to one of the first set of available data planes for the first target host device.

12. The method of claim 11, further comprising: The accelerated routing service and the control traffic are used to determine the fault from the first data plane in the first group of available data planes to the second target host device among the plurality of host devices; as well as Based on the fault, the first set of multiplane routing rules is modified to obtain a second set of multiplane routing rules. The second set of multiplane routing rules specifies a second set of multiplane routing rules for a second set of available data planes for the second target host device, wherein the second set of available data planes does not include the first data plane. Configure the register using the second set of multiplane routing rules via the virtual bridge; The virtual bridge receives a second packet directed to the second target host device; and Using the virtual bridge, the second packet is routed to one of the available data planes in the second set of available data planes for the second target host device, according to the second set of multiplane routing rules.

13. The method of claim 12, wherein, The first packet is received before the failure of the first data plane, and the second packet is received after the failure of the first data plane, wherein the method further includes: Perform an Internet Protocol IP address lookup on the first packet to identify the ECMP group identifier associated with the first group of available data planes for the first target host device; The ECMP group identifier is hashed to identify any one of the first group of available data planes; Perform an IP address lookup on the second packet to identify the ECMP group identifier; and The ECMP group identifier is hashed to identify any of the second group of available data planes.

14. The method of claim 12, wherein, Determining a fault in the first data plane includes receiving a fault notification from one of the other accelerated routing services indicating the fault in the first data plane.

15. The method of claim 12, further comprising: The accelerated routing service and the control traffic are used to determine the recovery from the first data plane to the second target host device; Based on the recovery modification of the second group of multiplane routing rules, the first group of multiplane routing rules is obtained, which specifies the set of available data planes for the second target host device, wherein the first group of available data planes includes the first data plane; Configure the register using the first set of multiplane routing rules via the virtual bridge; Receives a third packet directed to the second target host device at the virtual bridge; and Using the virtual bridge, the third packet is routed to one of the available data planes in the first set of available data planes for the second target host device, according to the first set of multiplane routing rules.

16. A host device, comprising: One or more processors; as well as A memory for storing instructions, which, when executed by the one or more processors, are used to provide accelerated routing services and virtual bridges to perform operations including: Use the accelerated routing service to exchange control traffic with other accelerated routing services performed by multiple host devices; The virtual bridge is configured based on the control traffic using a first set of multi-plane routing rules, wherein the first set of multi-plane routing rules specifies a first set of available data planes for each of the plurality of host devices; Using the virtual bridge, registers associated with multiple network adapters are configured using the first set of multiplane routing rules; At the virtual bridge, a first packet is received that is directed to a first target host device among the plurality of host devices; as well as According to the first set of multi-plane routing rules, the virtual bridge is used to route the first packet to one of the first set of available data planes for the first target host device.

17. The host device as claimed in claim 16, wherein, The operation also includes: Using the accelerated routing service and the control traffic, a fault is determined between the first data plane in the first set of available data planes and the second target host device among the plurality of host devices; and Based on the fault, the first set of multiplane routing rules is modified to obtain a second set of multiplane routing rules. The second set of multiplane routing rules specifies a second set of multiplane routing rules for a second set of available data planes for the second target host device, wherein the second set of available data planes does not include the first data plane. Configure the register using the second set of multiplane routing rules via the virtual bridge; The virtual bridge receives a second packet directed to the second target host device; and Using the virtual bridge, the second packet is routed to one of the available data planes in the second set of available data planes for the second target host device, according to the second set of multiplane routing rules.

18. The host device as claimed in claim 17, wherein, The first packet is received before the failure of the first data plane, and the second packet is received after the failure of the first data plane, wherein the operation further includes: Perform an Internet Protocol IP address lookup on the first packet to identify the ECMP group identifier associated with the first group of available data planes for the second target host device; The ECMP group identifier is hashed to identify any one of the first group of available data planes; Perform an IP address lookup on the second packet to identify the ECMP group identifier; and The ECMP group identifier is hashed to identify any of the second group of available data planes.

19. The host device as claimed in claim 17, wherein, Determining the fault in the first data plane includes receiving a fault notification from one of the other accelerated routing services indicating the fault in the first data plane.

20. The host device as claimed in claim 17, wherein, The operation also includes: The accelerated routing service and the control traffic are used to determine the recovery from the first data plane to the second target host device; Based on the recovery modification of the second group of multiplane routing rules, the first group of multiplane routing rules is obtained, which specifies the set of available data planes for the second target host device, wherein the first group of available data planes includes the first data plane; Configure the register using the first set of multiplane routing rules via the virtual bridge; Receives a third packet directed to the second target host device at the virtual bridge; and Using the virtual bridge, the third packet is routed to one of the available data planes in the first set of available data planes for the second target host device, according to the first set of multiplane routing rules.

21. The host device as claimed in claim 16, wherein, The operation also includes: Using the accelerated routing service and the control traffic, a fault is determined between the first data plane in the first set of available data planes and the second target host device among the plurality of host devices; and Based on this fault, the hardware selection of the first data plane by the host device is replaced with the selection of the second data plane from the remaining available data planes of the second target host; and The virtual bridge is used to route the second packet to the second data plane.

Images