Switch, switch cabinet, and data exchange method

Abstract

The present application provides a switch, a switch cabinet, and a data exchange method. The switch specifically comprises at least two interface modules, a switching module, and an uplink packet processing module, wherein the at least two interface modules comprise a first interface and a second interface; the first interface is configured to send and receive a first packet based on a first protocol; and the second interface is configured to send and receive a second packet based on a second protocol; the interface modules are used for acquiring a packet to be forwarded, and said packet is one of the first packet and the second packet; the uplink packet processing module is used for receiving said packet from the interface modules and acquiring first indication information corresponding to said packet, and the first indication information is used for indicating a destination interface corresponding to said packet; the switching module is used for receiving said packet and the first indication information from the uplink packet processing module, and on the basis of the first indication information, sending said packet to the corresponding destination interface.

Description

Switch, switch cabinet and data exchange method

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on July 4, 2023, with application number 202310814632.0 and invention name “A switch, switch cabinet and data exchange method”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of electronic information, and in particular to a switch, a switch cabinet, and a data exchange method. Background Art

[0003] With the prevalence of cloud computing and high-performance computing, more and more applications and data are migrating to data centers. The volume of business and data processed by data centers is exploding, placing greater demands on data center computing power. However, constrained by Moore's Law and slowing processor performance, Domain-Specific Architecture (DSA) is becoming a trend, with more heterogeneous processors and accelerators being introduced into data centers. Furthermore, due to the memory wall, single-server memory, both in terms of capacity and bandwidth, has become a bottleneck for high-performance processors. Consequently, the concept of a distributed data center (DC) is being promoted, pooling key resources such as heterogeneous processors, accelerators, and memory to meet the growing demand for computing power and memory. In this architecture, communication latency and bandwidth between different types of resources limit the performance of high-performance processors.

[0004] Summary of the Invention

[0005] The present application provides a switch, a switch cabinet, and a data exchange method, the purpose of which is to optimize the networking within the switch cabinet and improve the utilization of resources within the cabinet.

[0006] The first aspect of the present application provides a switch, specifically including at least two interface modules, a switching module and an uplink message processing module; wherein, the at least two interface modules include a first interface and a second interface, the first interface is configured to send and receive a first message based on a first protocol, and the second interface is configured to send and receive a second message based on a second protocol; the interface module is used to obtain a message to be forwarded, and the message to be forwarded is one of the first message and the second message; the uplink message processing module is used to receive a message to be forwarded from the interface module and obtain first indication information corresponding to the message to be forwarded, and the first indication information is used to indicate a destination interface corresponding to the message to be forwarded; the switching module is used to receive the message to be forwarded and the first indication information from the uplink message processing module, and send the message to be forwarded to the corresponding destination interface according to the first indication information.

[0007] By configuring the switch with multiple interfaces supporting different protocols, an uplink message processing module supporting at least one protocol exchange, and a switching module supporting different protocols, it is possible to receive, process, exchange, and forward messages of multiple different protocols, reducing the cost and power consumption of the switch equipment. In addition, local resources (memory, hard drives, accelerators, etc.) originally configured in the server and experiencing overflow can be externalized in the cabinet as pooled resources, and data can be transmitted through the bus and ToR switches supporting multiple protocol exchanges, further saving system cost and power consumption. It also removes the restriction that local resources are only available to the server, improves resource utilization, enables flexible resource configuration, and enables a variety of new services.

[0008] In one implementation, the switch further includes a downlink message processing module that receives the message to be forwarded and the first indication information from the switching module and sends the message to be forwarded to the interface module, where the interface module includes the destination interface.

[0009] In one implementation, an uplink message processing module in a switch is configured to connect to at least two interfaces, including the first interface and the second interface. By enabling the uplink message processing module to operate with different protocols, the number of uplink message processing modules required in the switch is reduced, thereby saving system cost and power consumption.

[0010] In one implementation, a downlink packet processing module in a switch is configured to connect to at least two interfaces, including the first interface and the second interface. By enabling the downlink packet processing module to operate with different protocols, the number of downlink packet processing modules required in the switch is reduced, thereby saving system cost and power consumption.

[0011] The second aspect of the present application provides a switch, comprising at least two interface modules, a first switching module, an uplink message processing module, and a multi-protocol conversion module, wherein the at least two interface modules include a first interface and a second interface, the first interface is configured to send and receive a first message based on a first protocol, and the second interface is configured to send and receive a second message based on a second protocol; the interface module is used to obtain a message to be forwarded, which is one of the first message and the second message; the multi-protocol conversion module is used to receive the message to be forwarded and convert the message to be forwarded into a third message according to the configuration, wherein the third message and the aforementioned message to be forwarded are messages based on different protocols; the first switching module is used to receive the third message and corresponding indication information, and send the received third message to the destination interface according to the indication information; the aforementioned indication information is generated by the uplink message processing module and is used to indicate the destination interface corresponding to the received message, and the uplink message processing module is used to obtain the indication information corresponding to the received message.

[0012] By configuring the switch with multiple interfaces supporting different protocols, an uplink message processing module supporting at least one protocol exchange, a switching module supporting one protocol, and a multi-protocol conversion module for protocol conversion, conversion between protocols within the cabinet and between different cabinets is achieved, eliminating the need to deploy a multi-protocol conversion module on each server, saving system cost and power. Furthermore, the switch can also be used to update new networking methods within the cabinet, allowing servers to access multiple pooled resources within the cabinet, including but not limited to memory, hard drives, accelerators, etc., using only a single bus protocol, further reducing the cost and power consumption of system interconnection.

[0013] In one implementation, the interface module in the switch is connected to the uplink message processing module, and the uplink message processing module is connected to the multi-protocol conversion module.

[0014] In one implementation, the interface module in the switch is connected to the multi-protocol conversion module, and the multi-protocol conversion module is connected to the uplink message processing module.

[0015] In one implementation, the switch further includes a second switching module, the interface module is connected to the uplink message processing module, the uplink message processing module is connected to the second switching module, and the second switching module is connected to the multi-protocol conversion module.

[0016] In one implementation, the switch further includes a downlink message processing module that receives the message to be forwarded and the first indication information from the switching module and sends the message to be forwarded to the interface module, where the interface module includes the destination interface.

[0017] The third aspect of the present application provides a switch cabinet, comprising the switch of the first aspect, at least one server electrically connected to the switch, and at least one resource pool electrically connected to the switch, wherein the resource pool includes at least one of multiple memory resources, multiple hard disk resources, and multiple accelerator resources.

[0018] In one implementation, the switch cabinet further includes a multi-protocol conversion device, which is electrically connected to the switch.

[0019] The fourth aspect of the present application provides a switch cabinet, comprising the switch of the second aspect, at least one server electrically connected to the switch, and at least one resource pool electrically connected to the switch, wherein the resource pool includes at least one of multiple memory resources, multiple hard disk resources, and multiple accelerator resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG1 is a diagram of a cabinet structure provided in an embodiment of the present application;

[0021] FIG2 is a diagram of a cabinet architecture for partial resource sharing provided by an embodiment of the present application;

[0022] FIG3 is a diagram of a cabinet structure provided in an embodiment of the present application;

[0023] FIG4 is an architecture diagram of a switch provided in an embodiment of the present application;

[0024] FIG5 is a flow chart of message processing of a switch provided in an embodiment of the present application;

[0025] FIG6 is an architecture diagram of another switch provided in an embodiment of the present application;

[0026] FIG7 is an architecture diagram of another switch provided in an embodiment of the present application;

[0027] FIG8 is an architecture diagram of another switch provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] To make the objectives, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this application.

[0029] The terms "first," "second," and the like in the description, embodiments, claims, and drawings of this application are used solely for descriptive purposes and are not to be construed as indicating or implying relative importance or order. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions, such as, for example, inclusion of a series of steps or units. A method, system, product, or apparatus is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0031] The rapid development of technologies such as cloud computing, big data, and artificial intelligence has placed higher demands on data center networks that carry data traffic. Businesses are demanding high throughput, high reliability, low latency, and adaptability to server virtualization. To meet these demands, more and more enterprises are choosing to build their own data centers or lease public clouds to carry the growing business traffic. Modern data centers are equipped with physical racks, each containing at least one physical server. Each physical server is equipped with at least a central processing unit (CPU), as well as localized resources such as memory, solid-state drives (SSDs), accelerators (exemplarily including GPUs), and network interface cards.

[0032] As data centers scale, multiple physical racks can be placed in a cabinet, and the physical servers in these racks can communicate with each other through switches. Based on the switch's placement within the cabinet (or the server's access method), physical architectures are generally categorized as TOR (Top of Rack) and EOR (End of Row) / MOR (Middle of Row).

[0033] Top of Rack (TOR) refers to deploying one or two switches in each server cabinet. Servers are directly connected to the switches in the cabinet, interconnecting the servers and switches within the cabinet. Generally speaking, placing switches at the top of the cabinet is most convenient for cabling, making this the most common architecture.

[0034] In contrast, the End of Row (EOR) architecture provides a unified network access point at the end of each row of cabinets. The Middle of Row (MOR) architecture is an improvement on the EOR architecture, also providing a unified network access cabinet for servers. However, the MOR architecture requires the network cabinet to be placed in the middle of the row of cabinets, which shortens the distance between the server cabinet and the network cabinet and simplifies cable management and maintenance.

[0035] Figure 1 illustrates a typical rack architecture, housing multiple servers and at least one ToR switch. Each server's CPU and local resources are dedicated to that server and cannot be shared. These servers can connect to the ToR switch via Ethernet. Furthermore, the ToR switch can connect to spine switches via Ethernet, forming a data center network that can scale to meet larger scale requirements.

[0036] Each server in Figure 1 is generally equipped with at least one CPU, memory (e.g., DDR DRAM), SSD, and accelerator GPU. External data can be transmitted from the switch to the server via the Ethernet interface, and further transmitted to different localized resources for processing or storage via the server's internal bus and different interfaces. For example, the Ethernet interface can be connected to the CPU, GPU, and SSD via the Peripheral Component Interconnect Express (PCIe) bus. When the CPU performs data processing, it stores the data in the memory via the DDR IO interface.

[0037] Because the ratio of internal computing power to localized resources in a physical server is fixed when it leaves the factory or is configured, resources can be configured based on the maximum capacity of the relevant business preset at the time of shipment or configuration. This not only results in wasted resources, but also in the case of new businesses requiring greater capacity, a single server may not be able to provide sufficient resources to meet the needs of these new businesses. New businesses include remote data servers (Redis), databases, and artificial intelligence (AI) computing, and these new businesses often have higher requirements for memory and hard drive capacity.

[0038] Based on these changing business needs, we can address this by adding interfaces to servers and implementing partial resource pooling within the cabinet. Figure 2 shows a cabinet architecture with partial resource sharing. This cabinet contains multiple servers, at least one ToR switch, at least one resource switch, a memory pool, and an SSD pool. The memory and SSD pools within the cabinet are shared by all servers within the cabinet.

[0039] ToR switches not only enable communication between multiple servers, but can also connect to spine switches through Ethernet interfaces to form data center networks and meet larger scale requirements.

[0040] The resource switch enables data interaction between the server and the memory pool or SSD pool by supporting communication protocols such as Compute Express Link (CXL) and unified buffer (UB).

[0041] Each server is equipped with an Ethernet port for communication with the ToR switch and at least one port for data transmission with the resource switch using protocols such as CXL or UB. In addition, the server is equipped with a CPU and some local resources, such as GPUs, network cards, and local DRAM. The local DRAM and the memory pool within the cabinet can form a memory structure with different tiers. These local resources are specific to the server and cannot be shared.

[0042] With the explosion of data brought about by the development of the internet and the advancement of virtualization technology, cloud computing and high-performance computing have become increasingly popular. This has brought with it greater challenges to the computing power of data centers and the need to further optimize the layout and resources within existing cabinets. Therefore, a new switch architecture is urgently needed to improve resource utilization within the cabinet, optimize computing and switching rates, and meet new business needs.

[0043] Figure 3 shows a cabinet architecture containing multiple servers, at least one switch, and various resource pools. These pools include, but are not limited to, memory pools (e.g., DDR DRAM pools), disk pools (e.g., SSD pools), accelerator pools (e.g., GPU pools), and network cards. The switch, which can be a ToR switch, End of Runtime (EoR) switch, or MoR switch, is used for internal cabinet communication and for data communication between cabinets and external cabinets. The following examples use ToR switches.

[0044] The ToR switch is equipped with an internal switching interface that supports internal data interconnection protocols, such as the CXL protocol or the UB protocol. Through this internal switching interface, the ToR switch connects the servers within the cabinet to various resource pools, making the aforementioned memory pool, disk pool, accelerator pool, and network interface cards shared by all servers within the cabinet.

[0045] By centralizing local server resources into rack-specific resource pools and enabling ToR switches to connect servers to these resource pools, this decouples the relationship between service requirements and the resource capacity limits configured at the time of factory shipment or configuration. This improves resource utilization and enables flexible resource allocation for various services. Furthermore, the transfer of local server resources reduces the number of CPU bus interconnects within the server, saving system cost and power.

[0046] Furthermore, the ToR switch is also equipped with a standard Ethernet interface, through which it can be connected to the spine switch outside the cabinet, thereby forming a data center network and meeting larger scale requirements.

[0047] The server in the cabinet is also configured with an internal switching interface that supports an internal data interconnection protocol, exemplarily including the CXL protocol or the UB protocol, etc. In addition, the server also has a CPU that is connected to the ToR switch through the internal switching interface.

[0048] Optionally, the server is also configured with internal memory resources. Through local memory resources and the shared memory pool in the rack, a two-tier memory architecture is implemented to balance performance and capacity, so that large memory-intensive businesses can be solved at a lower cost.

[0049] To implement the aforementioned rack structure, Figure 4 provides a ToR switch architecture, which includes a multifunctional interface module, an uplink packet processing unit, a downlink packet processing unit, and a multiprotocol switching unit. The multifunctional interface module is connected to at least one uplink packet processing unit and one downlink packet processing unit, and the multiprotocol switching unit is connected to all uplink and downlink packet processing units.

[0050] A multifunctional interface module, also known as multifunctional integrated facility management (MIFM), includes a media access control (MAC) layer, a physical coding sublayer (PCS) and a physical layer (PHY), and supports at least one data interconnection protocol within a rack, including but not limited to a standard Ethernet protocol, a standard CXL protocol, a standard UB protocol or other bus protocols. The multifunctional interface module can support multiple data interconnection protocols. After configuration, it works in one of the multiple data interconnection protocols mentioned above, that is, a multifunctional interface module simultaneously receives and / or sends messages based on the same protocol. For example, the first MIFM module can be configured to work in a standard Ethernet protocol, which can be connected to a spine switch outside the cabinet; the second MIFM module can be configured to work in a standard CXL protocol, which can be connected to a server in the cabinet, and the data exchange of the memory pool is based on the standard CXL protocol.

[0051] Each multifunctional interface module is connected to an uplink message processing module and a downlink message processing module.

[0052] The uplink message processing module (Ingress Processing, IP) is connected to at least one multi-function interface module and is used to process uplink messages from the multi-function interface module, including but not limited to forwarding processing such as data aggregation, parsing, table lookup, routing, editing, etc., and supports at least one intra-rack data forwarding protocol, including but not limited to the standard Ethernet protocol (specifically including the standard Ethernet Layer 2 / Layer 3 forwarding protocol, standard Ethernet tunnel processing), the standard CXL protocol, the standard UB protocol, or other bus-type protocols. Preferably, the uplink message processing module can support multiple data forwarding protocols and can simultaneously support the forwarding of messages of multiple protocols. When the IP module is connected to two or more MIFM modules, since the two or more MIFM modules can be configured to operate in different data interconnection protocols, the IP module can simultaneously receive and / or send messages of multiple protocols.

[0053] The downlink message processing module (EP) is connected to at least one multi-function interface module and processes downlink messages from the multi-function interface module. This includes, but is not limited to, data parsing, table lookup, encapsulation, editing, and distribution. It supports at least one intra-rack data forwarding protocol, including but not limited to standard Ethernet protocols (including standard Ethernet Layer 2 / Layer 3 forwarding protocols and standard Ethernet tunneling), standard CXL protocols, standard UB protocols, or other bus protocols. Similar to the uplink message processing module, the downlink message processing module can also support multiple data forwarding protocols, i.e., it can simultaneously forward messages from multiple protocols.

[0054] The Multi-Function Switching (MFS) module connects all uplink and downlink message processing modules and performs switching processing on the various protocol messages from the uplink message processing modules, including but not limited to data caching, switching, queuing, scheduling, and Quality of Service (QoS) management. The various protocols it supports include but are not limited to standard Ethernet protocols (specifically, standard Ethernet Layer 2 / Layer 3 switching protocols and standard Ethernet tunnel switching), standard CXL protocols, standard UB protocols, and other bus protocols. Similar to the uplink message processing module, the MFS module supports the switching of multiple protocol messages simultaneously.

[0055] Because the ToR switch is equipped with multiple interfaces supporting different protocols (for example, a first interface in a MIFM module supporting the standard Ethernet protocol and a second interface in a MIFM module supporting the standard CXL protocol), as well as an uplink message processing module, a downlink message processing module, and a multi-protocol switching module that support multi-protocol switching, the ToR switch can receive, process, switch, and forward messages of multiple protocols without requiring at least two switches each supporting different protocols, thus reducing the cost and power consumption of the switch equipment. The servers in the cabinet can not only receive and send conventional messages based on standard Ethernet, but can also store messages based on standard CXL or standard UB in the cabinet's pooled resources. Therefore, local resources (memory, hard drives, accelerators, etc.) originally configured in the server and experiencing overflow can be externalized within the cabinet as pooled resources, and data can be transmitted via the bus and the ToR switch supporting multi-protocol switching. This further reduces system cost and power consumption, removes the limitation that local resources are only available to the server, improves resource utilization, enables flexible resource configuration, and enables a variety of new services.

[0056] Optionally, the ToR switch can also be connected to a multi-protocol converter, such as a network card, to achieve rapid protocol conversion of messages, such as converting messages based on the standard Ethernet protocol into messages based on the standard CXL, thereby improving message exchange efficiency and expanding storage acceleration services.

[0057] FIG5 provides a message processing flow of a ToR switch as shown in FIG4 .

[0058] Step 1. Receive the data stream through the serializing / deserializing circuitry (SerDes).

[0059] The data flow is based on a first protocol, which is one of multiple protocols supported by the multi-function interface module and the multi-protocol switching module in the ToR switch. The ToR switch is connected to servers or local pooled resources in the cabinet via a SerDes, including but not limited to a memory pool, a storage pool, and an accelerator pool.

[0060] For example, a ToR switch receives a data stream from a server in a cabinet and needs to store the data in an SSD pool. The data stream may be a data stream based on a standard CXL protocol.

[0061] Step 2. Receive the data stream through the multi-function interface module, generate a first message and send it to the uplink message processing module.

[0062] Specifically, the operations performed by the MIFM module on the data stream include decoding, error correction, framing, error checking, retransmission, etc. Exemplarily, when the MIFM module is configured to operate in a standard CXL mode, the first message is a standard CXL message.

[0063] Step 3. The uplink message processing module receives the first message and forwards the first message and control information to the multi-protocol switching module.

[0064] Specifically, the operations performed by the IP module on the first message include message parsing, table lookup, forwarding, editing, etc. It determines the destination MIFM module corresponding to the first message according to a pre-stored routing table, which is carried by the aforementioned control information.

[0065] Exemplarily, when the first message is a standard CXL message, the IP module operates in a standard CXL mode, thereby processing the first message.

[0066] In a possible implementation, the IP module is connected to multiple MIFM modules and switches working modes according to received messages to process messages of different protocols.

[0067] Step 4. The multi-protocol switching module receives the first message and the control information, and switches the first message to the corresponding destination MIFM module according to the control information.

[0068] In one possible implementation, the multi-protocol switching module stores the first message in a built-in cache, stores the control information in a corresponding queue according to the destination MIFM module of the first message indicated by the control information, then schedules the control information from the queue, reads the first message from the cache, and exchanges them together to the corresponding destination MIFM module.

[0069] Exemplarily, when the first message is a standard CXL message, the MFS module operates in a standard CXL mode, thereby forwarding the first message.

[0070] Step 5. The downlink message processing module receives the first message and control information from the multi-protocol switching module, and sends the first message to the connected destination MIFM module according to the control information.

[0071] Specifically, the operations performed by the EP module on the first message include data parsing, table lookup, encapsulation, editing, distribution, etc.

[0072] Exemplarily, when the first message is a standard CXL message, the EP module operates in a standard CXL mode, thereby processing the first message.

[0073] In one possible implementation, the EP module switches working modes according to received messages and control information to process messages of different protocols; it is also connected to multiple MIFM modules and forwards messages to corresponding destination MIFM modules according to control information from the MFS module.

[0074] Step 6. The destination MIFM module receives the first message and control information, and sends the data stream outward through Serdes.

[0075] Specifically, the processing of the first message by the MIFM module includes segmentation, encoding and other processing.

[0076] For example, the destination MIFM module operates in standard CXL mode and is connected to the SSD pool. The ToR switch completes data exchange between the server and the SSD pool.

[0077] Through the above processing flow, the ToR switch completes processing of the data flow from the server or cabinet resource pool and forwards it to another server or other cabinet resource pool.

[0078] Furthermore, the ToR switch can also be connected to a network card module, which implements multi-protocol conversion of messages. Exemplarily, the network card module is connected to at least two MIFM modules of the ToR switch, including a first MIFM module working in standard Ethernet mode and a second MIFM module working in standard CXL mode. When the ToR switch exchanges data with the Spine switch outside the cabinet through standard Ethernet messages, and the ToR switch exchanges data with the server inside the cabinet through standard CXL messages, the standard Ethernet messages from the Spine switch outside the cabinet can be converted into standard CXL messages through the network card module to be forwarded to the server.

[0079] Figure 6 provides another architecture of a ToR switch. Similar to the switch architecture in Figure 4, there are also multi-function interface modules, uplink message processing modules, downlink message processing modules, and multi-protocol switching modules. In addition, a multi-protocol conversion module is added to enable the ToR switch to process messages based on multiple protocols. In the switch architecture of Figure 6, the multi-function interface module, uplink message processing module, and downlink message processing module only support one of the multiple protocols and will not be changed after configuration is completed. The multi-protocol switching unit supports the exchange of multiple protocols. The above-mentioned multiple protocols include but are not limited to standard Ethernet protocols, standard CXL protocols, standard UB protocols, or other bus-type protocols.

[0080] The newly added multi-protocol conversion module (Cross-Function Bridge, CFB) is used to convert messages based on the first protocol into messages based on the second protocol, thereby realizing communication between different bus data transmissions through only one ToR switch. Specifically, it includes data caching, protocol parsing, protocol conversion, reordering, segment reassembly, data verification, data retransmission and other processing.

[0081] By integrating a multi-protocol conversion module into the switch, conversion between protocols within and between cabinets is achieved, eliminating the need to deploy a multi-protocol conversion module on each server, saving system cost and power. Furthermore, the switch can be used to update new in-cabinet networking methods, allowing servers to access multiple pooled resources within the cabinet, including but not limited to memory, hard drives, and accelerators, using only a single bus protocol, further reducing system interconnection costs and power consumption.

[0082] In one achievable embodiment, the multi-protocol conversion module is connected to the uplink message processing module and / or the downlink message processing module. The multi-protocol conversion module can be referred to as a distributed cross-function bridge (DCFB). Optionally, each distributed multi-protocol conversion module is connected to an uplink message processing module and a downlink message processing module. That is, there are N groups of uplink message processing modules and downlink message processing modules, and accordingly, N distributed multi-protocol conversion modules should also be configured. Optionally, at least one distributed multi-protocol conversion module can be configured for each of the N groups of uplink message processing modules and downlink message processing modules based on pre-configuration. The DCFB module supports multiple protocol message conversions simultaneously.

[0083] Optionally, each DCFB module is connected in series between the MIFM module and a group of IP modules and EP modules. In one possible implementation, the MIFM module connected to the DCFB operates in a first protocol, while the group of IP modules and EP modules connected to the DCFB operate in a second protocol. For messages received from the MIFM module based on the first protocol, the DCFB module first performs protocol conversion before sending messages based on the second protocol to the IP module for forwarding. Similarly, the DCFB module can also receive messages from the EP module, complete protocol conversion, and then send them to the MIFM module.

[0084] Optionally, each DCFB module is connected in series between a group of IP modules, EP modules, and MFS modules. Messages sent from the IP module to the MFS module undergo protocol conversion via the DCFB module before being sent to the MFS module. Messages sent from the MFS module to the EP module undergo protocol conversion via the DCFB module before being sent to the EP module.

[0085] Optionally, each MIMF module is connected to a group of IP modules and EP modules, and the IP modules and EP modules are connected to a corresponding DCFB module.

[0086] Exemplarily, the DCFB module can be any of the following: a network interface card (NIC), a smart network interface card (Smart NIC), a data processing unit (DPU), etc. When the IP module or EP module is connected to multiple servers, preferably, the DCFB supports multi-host mode and can be shared by multiple servers.

[0087] In one implementable manner, the multi-protocol conversion module is only connected to the MFS module, and the multi-protocol conversion module can be called a centralized multi-protocol conversion module (Centralized Cross-Function Bridge, CCFB).

[0088] After a message is sent to the MFS module through the IP module, the MFS module sends the message requiring protocol conversion to the CCFB module. After completing the protocol conversion, the CCFB module sends the message back to the MFS module. The MFS module ultimately switches the message to the destination MIMF.

[0089] Exemplarily, the CCFB module can be the following: Macro NIC, Macro SmartNiC, Macro DPU. In the case where the IP module or EP module is connected to multiple servers, preferably, CCFB supports multi-host mode and can be shared by multiple servers.

[0090] Optionally, both the DCFB module and the CCFB module can be configured to convert multi-protocol messages. Specifically, depending on different service requirements, messages from different interface modules can be processed by either the DCFB or CCFB module. For reference, the DCFB module is configured to handle message conversion for simpler, high-bandwidth services, while the CCFB module is configured to handle message conversion for complex services.

[0091] For example, consider a ToR switch equipped with a DCFB module, which is connected between an MFS module and a set of IP and EP modules. The packet processing flow for this ToR switch is as follows:

[0092] Step 1. Receive the data stream through the serializing / deserializing circuitry (SerDes).

[0093] Step 2. The MIFM module performs decoding, error correction, framing, error checking, and retransmission on the data stream to generate and send the first message.

[0094] Step 301: The IP module performs message parsing, table lookup, forwarding, editing, and other processing on the received first message, determines the destination MIFM module corresponding to the received message according to the pre-stored routing table, and sends the first message and control information.

[0095] Step 302: According to pre-configuration, the DCFB module determines that protocol conversion needs to be performed on the first message, converts the first message based on the first protocol into a second message based on the second protocol, and sends the second message to the multi-protocol switching module.

[0096] Step 4. The MFS module receives the second message and control information, and switches the message to the corresponding destination MIFM module according to the control information.

[0097] Step 5. The downlink message processing module receives the second message, performs data parsing, table lookup, packaging, editing, distribution and other operations, and then sends the first message to the connected destination MIFM module.

[0098] In a possible implementation, the downlink message processing module is connected to multiple MIFM modules, and the downlink message processing module forwards the first message to the destination MIFM module according to the control information sent by the multi-protocol switching module.

[0099] Step 6. The destination MIFM module receives the message, completes processing such as segmentation and encoding, and then sends the recovered data stream outward through Serdes.

[0100] Optionally, the DCFB module may also be configured between the MIFM module and a group of IP and EP modules.

[0101] Optionally, the multi-protocol conversion module can be a CCFB module, which is connected to the MFS module. After receiving messages, the MFS module first sends all received messages to the CCFB module, or sends some messages to the CFB module based on the configuration. The CCFB module receives messages from the MFS module, completes protocol conversion, and then sends the converted messages back to the MFS module.

[0102] In one implementation, the IP module and EP module can be configured in single-protocol mode. The supported single protocols include, but are not limited to, standard Ethernet protocols, standard CXL protocols, standard UB protocols, or other bus-type protocols. The protocol mode supported by the IP module and EP module should be configured based on the location of the DCFB module, the MIFM module, and the type of external resources connected through the MIFM module.

[0103] For example, the MIFM module is connected to an SSD pool that supports the standard CXL protocol. When the DCFB module is configured between the MIFM module and the IP module or EP module, the IP module or EP module can be configured to use the standard Ethernet protocol. The DCFB module converts packets from standard Ethernet to the standard CXL protocol, thereby implementing packet forwarding.

[0104] For example, the MIFM module is connected to an SSD pool that supports the standard CXL protocol. When the DCFB module is configured between the MFS module and the IP module or EP module, the IP module or EP module can be configured to use the standard CXL protocol to prevent message forwarding failures caused by a mismatch between the protocol configured on the IP module or EP module and the protocol connected to the MIFM module.

[0105] Through the above processing flow, the ToR switch completes processing of the data flow from the server or cabinet resource pool and forwards it to another server or other cabinet resource pool.

[0106] Figure 7 provides an alternative ToR switch architecture. This switch architecture includes not only the aforementioned MIFM module, IP module, EP module, MFS module, and multi-protocol conversion module, but also a second MFS module. In this architecture, the multi-protocol conversion module is placed between two MFS modules, enabling protocol conversion between packets exchanged between the two MFS modules. This allows the ToR switch to support multi-protocol packet exchange. This architecture allows the aforementioned modules (except the multi-protocol conversion module) to support only a single protocol exchange, reducing component requirements and costs.

[0107] In one implementation, the multi-protocol conversion module can be at least one DCFB module, which is installed in parallel between two MFS modules. The DCFB module receives messages from either MFS module, completes protocol conversion, and then sends them to the other MFS module. The number of DCFB modules to be installed can be determined based on the total number of services or interfaces.

[0108] In another implementation, the multi-protocol conversion module can be at least one CCFB module. If multiple CCFB modules are used, they are connected in parallel between two MFS modules. A CCFB module receives messages from either MFS module, completes protocol conversion, and then sends them to the other MFS module. The number of CCFB modules to be configured can be determined based on the total number of services or interfaces.

[0109] The packet processing flow of the ToR switch is as follows:

[0110] Step 1. Receive the data stream through the serializing / deserializing circuitry (SerDes).

[0111] Step 2. The multi-function interface MIFM module performs decoding, error correction, framing, error checking, and retransmission on the data stream, and generates a first message that is sent to the uplink message processing module.

[0112] Step 3. The IP module performs message parsing, table lookup, forwarding, editing, and other processing on the first message, determines the destination MIFM module corresponding to the first message according to the pre-stored routing table, and sends the first message and control information to the first MFS module.

[0113] In a possible implementation, the uplink message processing module is connected to multiple MIFM modules.

[0114] Step 4. The first MFS module receives the first message and control information, determines the switching path, and sends them to the multi-protocol conversion module corresponding to the switching path.

[0115] The first MFS module operates in a first protocol corresponding to the first message.

[0116] Step 5. The multi-protocol conversion module converts the first message based on the first protocol into a second message based on the second protocol and sends it to the second MFS module;

[0117] Step 6. The second MFS module switches the second message to the corresponding destination MIFM module according to the control information.

[0118] The second MFS module operates in a second protocol corresponding to the second message.

[0119] Step 7. The downlink message processing module receives the second message from the multi-protocol switching module, performs data parsing, table lookup, encapsulation, editing, distribution and other operations, and then sends the second message to the connected destination MIFM module.

[0120] Step 8. The destination MIFM module receives the second message, completes processing such as segmentation and encoding, and then sends the recovered data stream outward through Serdes.

[0121] Figure 8 provides an alternative ToR switch architecture. In this switch architecture, the functions of the IP module and EP module are merged into the multiprotocol switching module. Therefore, in addition to performing inter-protocol conversion, the multiprotocol switching module also needs to process upstream messages, including but not limited to data aggregation, parsing, table lookup, routing, editing, and other forwarding processes. It also needs to process downstream messages, including but not limited to data parsing, table lookup, encapsulation, editing, and distribution. In this architecture, the MFS module only supports switching of a single protocol, thus reducing the component requirements for the MFS module and lowering the cost and component requirements of the switch.

[0122] Optionally, the functions of all IP modules and EP modules can be integrated into at least one multi-protocol switch module, with each MIFM module connected to a corresponding MFS module. Alternatively, the functions of some IP modules and EP modules can be integrated into at least one multi-protocol switch module, with some MIFM modules connected to corresponding MFS modules and the remaining MIFM modules connected to corresponding IP modules and EP modules. For example, these MIFM modules can be connected to all servers in a cabinet.

[0123] In one implementation, the at least one multi-protocol conversion module can be a DCFB module, which is arranged in parallel between the two MFS modules. The DCFB module receives messages from either MFS module, completes protocol conversion, and then sends them to the other MFS module. The number of DCFB modules to be configured can be determined based on the total number of services or interfaces.

[0124] In another implementation, the multi-protocol conversion module can also be at least one CCFB module. If multiple CCFB modules are used, they are connected in parallel between the two MFS modules. The CCFB module receives messages from either MFS module, completes protocol conversion, and then sends them back to the MFS module. The number of CCFB modules to be configured can be determined based on the total number of services or interfaces.

[0125] For example, a ToR switch configured with the DCFB module only for the MIFM module connected to the server handles the message as follows:

[0126] Step 1. Receive a data stream from a server via a serializing / deserializing circuitry (SerDes). The data stream is based on a first protocol, which is one of multiple protocols supported by the multi-function interface module and the multi-protocol switching module in the ToR switch.

[0127] Step 2. The multi-function interface MIFM module performs decoding, error correction, framing, error checking, and retransmission on the data stream, and generates a first message that is sent to the DCFB module.

[0128] Step 3. The DCFB module performs message parsing, table lookup, forwarding, and editing on the first message. If protocol conversion is required, the DCFB module converts the first message based on the first protocol into a second message based on the second protocol, and sends the second message and control information to the MFS module.

[0129] Step 4. The MFS module receives the second message and control information, and exchanges the second message to the corresponding destination MIFM module.

[0130] Step 5. The DCFB module corresponding to the destination MIFM module receives the second message from the multi-protocol switching module, performs data parsing, table lookup, encapsulation, editing, distribution and other operations, and then sends the second message to the connected destination MIFM module.

[0131] Step 6. The destination MIFM module receives the second message, completes processing such as segmentation and encoding, and then sends the recovered data stream outward through Serdes.

[0132] In some embodiments, the switch can be set in a chassis or cabinet of a distributed data center (Disaggregated Data Center) network, providing bus interfaces such as CXL / UB internally to interconnect all servers (i.e., their CPUs) and various pooled resources (accelerators, memory, storage, network cards, etc.) for mutual communication; and providing a standard Ethernet interface externally to connect to the spine switch to form a large-scale data center network.

Claims

1. A switch, characterized in that: The switch includes at least two interface modules, a switching module and an uplink message processing module, wherein: The at least two interface modules include a first interface and a second interface, wherein the first interface is configured to send and receive a first message, the first message is a message based on a first protocol, and the second interface is configured to send and receive a second message, the second message is a message based on a second protocol; The interface module is used to obtain a message to be forwarded, where the message to be forwarded is one of the first message and the second message; The uplink message processing module is used to receive the message to be forwarded from the interface module, and obtain the first indication information corresponding to the message to be forwarded, where the first indication information is used to indicate the destination interface corresponding to the message to be forwarded; The switching module is used to receive the message to be forwarded and the first indication information from the uplink message processing module, and send the message to be forwarded to the destination interface according to the first indication information.

2. The switch according to claim 1, characterized in that: The switch further includes a downlink message processing module, and the downlink message processing module is used to: Receiving the message to be forwarded and the first indication information from the switching module; The message to be forwarded is sent to the interface module, where the interface module includes the destination interface.

3. The switch according to claim 1, characterized in that: The uplink message processing module is used to connect at least two interfaces, and the at least two interfaces include the first interface and the second interface.

4. The switch according to claim 2, characterized in that: The downlink message processing module is used to connect at least two interfaces, and the at least two interfaces include the first interface and the second interface.

5. A switch, characterized in that: The switch includes at least two interface modules, a first switching module, an uplink message processing module and a multi-protocol conversion module, wherein: The at least two interface modules include a first interface and a second interface, wherein the first interface is configured to send and receive a first message, the first message is a message based on a first protocol, and the second interface is configured to send and receive a second message, the second message is a message based on a second protocol; The interface module is used to obtain a message to be forwarded, where the message to be forwarded is one of the first message and the second message; The multi-protocol conversion module is used to receive the message to be forwarded, and convert the message to be forwarded into a third message according to the configuration, wherein the third message and the message to be forwarded are messages based on different protocols; The first switching module is used to receive the third message and corresponding indication information, and send the received third message to the destination interface according to the indication information; The indication information is generated by the uplink message processing module, and the uplink message processing module is used to obtain the indication information corresponding to the received message, and the indication information is used to indicate the destination interface corresponding to the received message.

6. The switch according to claim 5, characterized in that: The interface module is connected to the uplink message processing module, and the uplink message processing module is connected to the multi-protocol conversion module.

7. The switch according to claim 5, characterized in that: The interface module is connected to the multi-protocol conversion module, and the multi-protocol conversion module is connected to the uplink message processing module.

8. The switch according to claim 5, characterized in that: The switch further includes a second switching module, the interface module is connected to the uplink message processing module, the uplink message processing module is connected to the second switching module, and the second switching module is connected to the multi-protocol conversion module.

9. The switch according to any one of claims 5 to 8, characterized in that: The switch further includes a downlink message processing module, and the downlink message processing module is used to: Receiving the message to be forwarded and the first indication information from the switching module; The message to be forwarded is sent to the interface module, where the interface module includes the destination interface.

10. A switch cabinet, characterized in that: It includes a switch as described in any one of claims 1 to 4, at least one server electrically connected to the switch, and at least one resource pool electrically connected to the switch, wherein the resource pool includes at least one of multiple memory resources, multiple hard disk resources, and multiple accelerator resources.

11. The switch cabinet according to claim 10, characterized in that: The switch cabinet also includes a multi-protocol conversion device, which is electrically connected to the switch.

12. A switch cabinet, characterized in that: It includes a switch as described in any one of claims 5 to 9, at least one server electrically connected to the switch, and at least one resource pool electrically connected to the switch, wherein the resource pool includes at least one of multiple memory resources, multiple hard disk resources, and multiple accelerator resources.

Images