Network card-based RDMA set communication offloading device and equipment

Abstract

The application discloses a network card-based RDMA collection communication offloading device and equipment, and belongs to the technical field of computer networks.The device comprises a PCIe interface, a descriptor processing component, a collection communication offloading engine, a DMA component, an RDMA protocol processing component and a network interface.The descriptor processing component is used for submitting the metadata of a collection communication task written by a host to the collection communication offloading engine.The collection communication offloading engine is connected with the host through the PCIe interface.The collection communication offloading engine is connected with the RDMA protocol processing component and the network interface.The DMA component is connected with the PCIe interface, the collection communication offloading engine and the RDMA protocol processing component.The application aims to realize flexible and efficient collection communication offloading and performance improvement in a multi-collection communication concurrent scenario.

Description

Technical Field

[0001] This invention relates to digital information transmission technology in the field of computer communication, specifically to a network interface card-based computer-network converged RDMA aggregated communication offloading device and equipment. Background Technology

[0002] The aggregated communication offloading mechanism is to migrate the communication scheduling, data processing and other tasks originally undertaken by the host CPU to the network hardware. It can be divided into three types of offloading schemes based on switches, data processing units (DPUs) and network cards. The existing aggregated communication hardware offloading mechanism based on network cards can be divided into two implementation methods: solid aggregated communication hardware circuit and integrated lightweight aggregated communication computing core. (1) The solid aggregated communication hardware circuit implementation method completes the aggregated communication offloading by solidifying the application-specific integrated circuit (ASIC) in the network card, and all communication scheduling, data transmission and protocol calculation components are handed over to the hardware circuit to be executed, completely free from software intervention. The paper "EasyNet: 100 Gbps Network for HLS" by HE Z et al., published in the proceedings of the 31st International Conference on Field-Programmable Logic and Applications in 2021 (pp. 197-203), tracks the available data in FIFOs in the TCP / IP stack of each connection. The reducer reduces the data stored in the FIFOs in a cyclic manner, but the message size is limited by the FIFO capacity, and only static collection communication offloading is implemented, resulting in high hardware implementation costs for extended operations. SMI (the paper "Streaming message interface: high-performance distributed memory programming on reconfigurable hardware" by DE MATTEIS T et al., published in the proceedings of the 2019 Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (pp. 1-33)) implements broadcast and reduction units separately on an FPGA, directly initiating collections through a streaming collection interface, but still through static hardware logic. NetFPGA (the paper titled "Offloading Collective Operations to Programmable Logic" by ARAP O et al., published in IEEE Micro, Vol. 37, No. 5, pp. 52-60, 2017) supports MPI offloading requests through predefined UDP ports and reduces and routes data through a static collection processing engine.The Tianhe Interconnect Network Interface (a paper titled "A Dimensional Triggering Mechanism and Data Caching Method for Hardware Offloading of Aggregate Communication" published by Xu Jinbo et al., in the Journal of National University of Defense Technology, Vol. 47, No. 6, pp. 13-23, 2025) designed a trigger-based communication offloading mechanism. Aggregate communication operations are offloaded to the interconnect network for autonomous triggering and execution. The computational logic components in the interconnect network interface can support reduction operations, but the supported message granularity is small. (2) The implementation method of integrating a lightweight aggregate communication computing core is to add an embedded processor (such as MicroBlaze) to the network card and control the aggregate communication execution process by software programming. The software flexibility makes up for the functional limitations of pure hardware. The Myrinet network interface (as described in the paper "Performance benefits of NIC-based barrier on Myrinet / GM" by BUNTINAS D et al., published in the 2001 Proceedings of the Workshop on Communication Architecture for Clusters (CAC), page 166) includes an embedded processor, supporting the offloading of specific cluster communication operations, but updating cluster communication operations requires changes to the control program running on the network interface. TMD-MPI (as described in the paper "MPI as a Programming Model for High-Performance Reconfigurable Computers" by Saldaña M et al., published in 2010 ACM Transactions on Reconfigurable Technology and Systems, Vol. 3, No. 4, pp. 1-29) relies on the software implementation of the embedded processor MicroBlaze for both cluster communication and point-to-point operations, providing flexibility in offloading, but its performance improvement is limited by the processor frequency.Christgau S et al. (in their paper "A First Steptowards Support for MPI Partitioned Communication on SYCL-programmed FPGAs", published in the 2022 IEEE / ACM International Workshop on Heterogeneous High-performance Reconfigurable Computing proceedings, pp. 9-17) used a soft-core processor (Intel's Nios II soft core) on the FPGA to coordinate and manage communication operations. They utilized SYCL, a high-level heterogeneous programming model based on C++, to implement the mapping of complete MPI communication primitives on the FPGA. The soft core was responsible for parsing communication requests, managing data transmission processes, and executing communication operations using the FPGA's parallel processing capabilities. ACCL+ (the paper titled "ACCL+: an FPGA-based collective engine for distributed applications" by HE Z et al., published in the 2024 Proceedings of the 18th USENIX Symposium on Operating Systems Design and Implementation, pp. 1-19) provides a set of MPI-like collective communication primitives on the Xilinx Runtime (XRT) platform and the Coyote shared memory platform, respectively. It provides collective communication semantics through the embedded microcontroller MicroBlaze, offloading the protocol to hardware implementation. Based on the RDMA / UDP / TCP protocol stack, it supports communication operations with various message sizes and performs algorithm optimizations under the Eager and Rendezvous protocols. While existing network interface card (NIC)-based collective communication hardware offloading mechanisms can effectively improve communication efficiency, providing a flexible hardware design that allows for the selection of different collective communication types and message sizes at runtime, while supporting efficient non-blocking execution, is a key challenge in achieving efficient collective communication offloading. Summary of the Invention

[0003] The technical problem to be solved by the present invention is as follows: In view of the above-mentioned problems of the prior art, the present invention provides a network interface card-based computing and network convergence RDMA aggregated communication offloading device and equipment, which aims to achieve flexible and efficient aggregated communication offloading and improve performance in multi-aggregated communication concurrent scenarios.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0005] A network interface card (NIC)-based converged computing and networking RDMA (Recursive Direct DMA) offloading device includes a PCIe interface, a descriptor processing unit, a unified communication offloading engine, a DMA (Distributed DMA) unit, an RDMA protocol processing unit, and a network interface. The descriptor processing unit submits the metadata of the unified communication task written by the host to the unified communication offloading engine. The unified communication offloading engine is connected to the host through the PCIe interface and is connected to the network interface through the RDMA protocol processing unit. The DMA unit is connected to the PCIe interface, the unified communication offloading engine, and the RDMA protocol processing unit.

[0006] Optionally, the aggregated communication offloading engine includes an aggregated communication core component, an aggregated communication context component, an event handling component, an aggregated communication data management component, an aggregated communication execution processing component, and a protocol calculation component. The aggregated communication execution processing component is used to parse the control command words issued by the aggregated communication core component. If the control command word is a data forwarding operation, it initiates DMA and RDMA requests, establishes a direct path to the DMA component or caches it to the RDMA protocol processing component, and completes the data reception and forwarding operations of the aggregated communication task. If the control command word is a calculation operation, it initiates a protocol calculation request to the protocol calculation component, performs aggregation operations on the input data stream through the protocol calculation component, stores the results in the cache, and finally writes it back to the host through a DMA request or directly forwards it to the network through an RDMA request. The aggregated communication core component is connected to the aggregated communication context component, the event handling component, and the aggregated communication data management component. The aggregated communication context component is used to record the communication context of the aggregated communication task. The event handling component sets up an event queue, and each event queue corresponds to the event type of different stages of aggregated communication to support event processing at different stages of aggregated communication. The aggregated communication data management component is used to manage the cache of the aggregated communication task data.

[0007] Optionally, the reduction calculation component includes a calculation control module and an arithmetic logic unit array connected to each other. The arithmetic logic unit array supports arithmetic logic operations including some or all of the reduction semantics such as SUM, MAX, MIN, AND, OR, and XOR.

[0008] Optionally, the aggregated communication data management component includes a data buffer, a shared buffer queue management module, and a shared buffer queue. The shared buffer queue includes multiple cache entries. The aggregated communication data management component caches the data of the aggregated communication task in the cache entries and retrieves the cached data from the cache entries into the data buffer to realize the data processing of the aggregated communication task. The fields in each record in the cache entry include the transaction number JobID, the message sequence number SeqID, the cache validity signal Valid, the cache block address Address, and the cache block size Size.

[0009] Optionally, the aggregated communication offloading engine performs the compute-network converged RDMA aggregated communication offloading by including the following steps:

[0010] S101, initialize the set communication descriptor queue CCD, the operation completion status queue OCS, and the handshake message queue RM; the set communication descriptor queue CCD is used to record the descriptors of set communication tasks, the operation completion status queue OCS is used to record the completion status of set communication tasks, and the handshake message queue RM is used to record the handshake information with other nodes in the set communication task.

[0011] S102, if the operation completion status queue OCS is not empty, extract the transaction number JobID of the set communication task from the operation completion status queue OCS, decrement the operand Op_num of the set communication task corresponding to the transaction number JobID by 1. If the operand Op_num after decrementing by 1 is zero, return the completion status of the set communication task corresponding to the transaction number JobID and jump to step S105; if the operand Op_num after decrementing by 1 is not zero, directly jump to step S105; if the operation completion status queue OCS is empty, proceed to the next step.

[0012] S103, if the handshake message queue RM is not empty, extract the transaction number JobID and message type Type of the collective communication task from the handshake message queue RM; if the message type Type is "Initiate handshake RendzInit", construct and issue control command words for the collective communication task corresponding to the transaction number JobID to start the processing of the collective communication task, and jump to step S105; if the message type Type is "Handshake completed RendzDone", decrement the operand Op_num of the collective communication task corresponding to the transaction number JobID by 1. If the operand Op_num after decrementing by 1 is zero, return the completion status of the collective communication task corresponding to the transaction number JobID, and jump to step S105; if the operand Op_num after decrementing by 1 is not zero, directly jump to step S105; if the handshake message queue RM is empty, proceed to the next step.

[0013] S104. If the collection communication descriptor queue CCD is not empty, extract the descriptor from the collection communication descriptor queue CCD, parse the descriptor and obtain the transaction number JobID and collection communication type Collective_Type, then create a communication context for the collection communication task corresponding to the transaction number JobID, execute the corresponding collection communication task according to the collection communication type Collective_Type, and save the communication context of the collection communication task, and then jump to step S105.

[0014] S105, determine whether the reset signal RESET is valid. If the reset signal RESET is valid, end and exit; otherwise, jump to step S102 to continue the iteration.

[0015] Optionally, in step S104, when executing the corresponding collective communication task according to the Collective_Type, the execution includes suspending the current collective communication task and switching to the execution of other collective communication tasks to achieve concurrent processing of multiple collective communication tasks when the external event that the current collective communication task is waiting for is not ready, and resuming the execution of the current collective communication task when the external event that the current collective communication task is waiting for is ready, until the current collective communication task is completed and the result is written back to the host through DMA operation.

[0016] Optionally, in step S104, when parsing the descriptor and obtaining the transaction number JobID and the collection communication type Collective_Type, the parsed collection communication type Collective_Type is one of eight collection communication types: Broadcast collection communication, Scatter collection communication, Gather collection communication, AllGather collection communication, Reduce collection communication, ReduceScatter collection communication, AllReduce collection communication, and AlltoAll collection communication.

[0017] Optionally, each record in the Operation Completion Status Queue (OCS) includes the transaction number JobID and operand Op_num of the collective communication task. The JobID distinguishes different collective communication tasks, and the Op_num records the number of uncompleted operations for the collective communication task, initialized to the total number of operations for the task. Each record in the Handshake Message Queue (RM) includes the transaction number JobID and message type Type of the collective communication task. The message type Type records the message type of the handshake message, including RendzInit (initiating handshake) and RendzDone (handshake completed). Each record in the Collective Communication Descriptor Queue (CCD) includes the transaction number JobID, Collective Communication Type Collective_Type, Data Count, Communicator Address Communicator, Destination Rank, and Reduction Type. The set of parameters includes Type, Source Operand 0 Address (Op0_Address), Source Operand 1 Address (Op1_Address), and Result Address (Result_Address). The Collective Communication Type (Collective_Type) identifies different types of collective communication operations. The Data Count records the number of messages in the collective communication task. The Communicator Address records the address of the communicator used by the collective communication task. The Destination Rank records the communication target of the collective communication task. The Reduction Type records the type of reduction operation used by the collective communication task. The Source Operand 0 Address (Op0_Address) and Source Operand 1 Address (Op1_Address) record the memory addresses of the source operands in the collective communication task. The Result Address (Result_Address) records the memory address of the operation result of the collective communication task.

[0018] Optionally, the communication context of the collective communication task includes some or all of the following: JobID, communication group member information, data buffer address, source address, destination address, message size, current progress, and valid bits.

[0019] The present invention also provides a computer device, including a microprocessor and a network communication device that are interconnected, wherein the network communication device is the network interface card-based computing-network converged RDMA aggregated communication offloading device.

[0020] Compared with existing technologies, the present invention mainly achieves the following beneficial effects: The computing-network converged RDMA aggregated communication offloading device of the present invention includes a PCIe interface, a descriptor processing unit, an aggregated communication offloading engine, a DMA unit, an RDMA protocol processing unit, and a network interface. The descriptor processing unit is used to submit the metadata of the aggregated communication task written by the host to the aggregated communication offloading engine. The aggregated communication offloading engine is connected to the host through the PCIe interface. The aggregated communication offloading engine is connected to the network interface through the RDMA protocol processing unit. The DMA unit is connected to the PCIe interface, the aggregated communication offloading engine, and the RDMA protocol processing unit respectively. The present invention can support flexible and efficient aggregated communication offloading and achieve performance improvement in multi-aggregated communication concurrent scenarios. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the basic structure of the device according to an embodiment of the present invention.

[0022] Figure 2 This is a schematic diagram of the structure of the collection communication execution processing unit in an embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of the structure of the collection communication data management component in an embodiment of the present invention.

[0024] Figure 4 This is a schematic diagram of the structure of the buffer item in an embodiment of the present invention.

[0025] Figure 5 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0026] Figure 6 This is a schematic diagram of the field structure of the Collection Communication Descriptor Queue (CCD) in an embodiment of the present invention.

[0027] Figure 7 This document compares the end-to-end message latency of different collection communication operation types in this embodiment of the invention, where (a) is the end-to-end message latency of Broadcast operation; (b) is the end-to-end message latency of Scatter operation; (c) is the end-to-end message latency of Gather operation; (d) is the end-to-end message latency of AllGather operation; (e) is the end-to-end message latency of Reduce operation; (f) is the end-to-end message latency of ReduceScatter operation; (g) is the end-to-end message latency of AllReduce operation; and (h) is the end-to-end message latency of AlltoAll operation.

[0028] Figure 8This invention presents a comparison of end-to-end message latency in a multi-operation concurrent scenario, where (a) represents the end-to-end message latency of an 8-way Gather operation; (b) represents the speedup ratio of an 8-way Gather operation; (c) represents the end-to-end message latency of an 8-way AlltoAll operation; (d) represents the speedup ratio of an 8-way AlltoAll operation; (e) represents the end-to-end message latency of an 8-way Reduce operation; (f) represents the speedup ratio of an 8-way Reduce operation; (g) represents the end-to-end message latency of an 8-way AllReduce operation; and (h) represents the speedup ratio of an 8-way AllReduce operation.

[0029] Figure 9 The comparison of node scale expansion test results in the embodiments of the present invention is shown, where (a) is the end-to-end message latency of 8-way Gather operation; (b) is the node scale of 8-way Gather operation; (c) is the end-to-end message latency of 8-way Reduce operation; and (d) is the node scale of 8-way Reduce operation. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0031] like Figure 1 As shown, the network interface card-based computing-network converged RDMA aggregated communication offloading device in this embodiment includes a PCIe interface, a descriptor processing unit, an aggregated communication offloading engine, a DMA unit, an RDMA protocol processing unit, and a network interface. The descriptor processing unit is used to submit the metadata of the aggregated communication task written by the host to the aggregated communication offloading engine. The aggregated communication offloading engine is connected to the host through the PCIe interface. The aggregated communication offloading engine is connected to the network interface through the RDMA protocol processing unit. The DMA unit is connected to the PCIe interface, the aggregated communication offloading engine, and the RDMA protocol processing unit, respectively.

[0032] like Figure 1 As shown, in this embodiment, the aggregate communication offloading engine interacts with the host through the PCIe interface. The descriptor processing unit receives point-to-point communication and aggregate communication descriptors from the host through the PCIe interface. The aggregate communication offloading engine processes the aggregate communication descriptors and executes aggregate communication operations. The DMA unit is used to access host memory and achieves efficient memory access through registration. The RDMA protocol processing unit encapsulates data into RDMA packets. It supports standard RDMA Verbs, including one-sided operation WRITE and two-sided operation SEND. At the same time, the RDMA protocol processing unit integrates interfaces for RDMA commands, memory access, and data transmission. The network interface is responsible for sending and receiving network packets, which is implemented through the optical module interface.

[0033] like Figure 1 and Figure 2 As shown, the aggregate communication offloading engine in this embodiment includes an aggregate communication core component, an aggregate communication context component, an event handling component, an aggregate communication data management component, an aggregate communication execution processing component, and a reduction calculation component. The aggregate communication core component, as the control center of the aggregate communication offloading engine, runs a lightweight daemon program and constructs standard aggregate communication semantics. The implementation of aggregate communication semantics is an ordered combination of RDMA communication, data caching, and reduction calculation components between different nodes, realizing various aggregate communication semantics such as Broadcast, Gather, Reduce, AllReduce, and AlltoAll. It supports Eager and Rendezvous message synchronization protocols and flexibly supports various message sizes. Extending aggregate communication types has low development costs and minimal hardware overhead, improving scalability. The aggregate communication core component can asynchronously and concurrently process events from multiple hardware queues. Through the unified scheduling, context switching, and event triggering mechanism of the aggregate communication core component, it can coordinate the non-blocking execution of aggregate operations issued by the aggregate communication core component without blocking subsequent operations, effectively improving communication efficiency.

[0034] In this embodiment, the core component of the collective communication system is implemented based on a RISC-V core or MicroBlaze. The Daemon executable for this core component is written in standard C language. The code is compiled and linked using a cross-compilation toolchain to generate an executable binary object file. Finally, the compiled program image is stored on the on-chip memory of the RISC-V core. The speed of program calls and instruction execution is determined by the RISC-V core's clock frequency. Adopting a decoupling approach between control and execution significantly reduces development cycle and debugging difficulty. The customizable nature of the RISC-V core allows for flexible adjustment of the resource consumption of the collective communication core component, resulting in a lightweight design. The collective communication core component reduces hardware implementation costs, maximizing hardware resource savings while meeting functional requirements. The core component primarily performs the parsing and processing of the collective communication descriptor and the triggering of collective communication events through the Daemon program. Its execution flow is as follows: Figure 5As shown, the Daemon program first executes the initialization function Init() to configure system resources and the event queue, and then enters the while main loop, using a three-level priority mechanism to poll and process events. The highest priority check is performed on the Operation Completion Status Queue (OCS). If the queue is not empty, the JobID is extracted, and the operation count Op_num in the context[JobID] is decremented by 1. When Op_num is detected to be zero, Finalize(JobID) is called to complete task cleanup and return the status value RV. The next priority check is performed on the Handshake Message Queue (RM). If it is not empty, the JobID and message type Type are extracted. When Type is RendzInit, ExecutionCommandProcess(JobID) is called to construct and issue the execution command word to start the data path. When Type is RendzDone, Op_num is decremented and it is determined whether task completion has been triggered. The lowest priority check is performed on the Collection Communication Descriptor Queue (CCD). If it is not empty, the JobID and Collection Operation Type Collective Type are extracted. After obtaining the context, specific collection communication operations such as Broadcast, Gather, or AllReduce are executed through case branch scheduling. After the operation is completed, the updated context information is saved to maintain the task status. If all queues are empty and there is no reset signal, continue is executed to enter the next round of loop, thereby realizing efficient collection communication task management based on event-driven and priority scheduling. The parsing and processing of the collective communication descriptor is based on the semantic implementation of RDMA collective communication, mainly including the construction and parsing of handshake messages and the construction of control command words of the collective communication execution processing unit. The contents of these two parts will be described in detail below. (1) Before the collective communication data transmission, the Daemon program performs handshake message construction and parsing. This embodiment supports two message synchronization protocols, Eager and Rendezvous, which can be specified by the host or flexibly selected by the collective communication core component at runtime according to the message size and number of nodes. This embodiment uses bilateral RDMASEND for Rendezvous handshake and unilateral RDMA WRITE for actual data message transmission, without the intervention of the receiving collective communication core component. The Daemon program implements the construction and parsing of handshake information for the Rendezvous mechanism, providing a standard unified interface for various collective communication operations. After the sender's handshake message is encapsulated, it is sent to the destination node through the RDMA component; after the receiving handshake message arrives, the corresponding fields are extracted and verified. If the collective communication operation matching the handshake is not ready, the handshake message is temporarily stored. The hierarchical design of handshake message processing and collective communication semantics was realized, which effectively standardized the interaction process of RDMA collective communication. (2) After the Daemon program completes the handshake synchronization, it constructs the control command word of the collective communication execution processing unit to perform corresponding operations on the collective communication data.The core component of the aggregate communication system controls the aggregate communication execution processing component to manage the data of the executed operations by using operation execution command words. It also receives the operation completion status returned by the aggregate communication execution processing component to determine whether the aggregate communication operation is complete. The aggregate communication execution processing component dynamically configures the data path for each aggregate operation step through specific control command words, enabling data caching and computation, result writing back, and network transmission, and returns the execution completion status to the core component. The control command word contains fields such as transaction number (JobID), operation type, message size, address information, and channel configuration, defining the operating parameters and specific operations of the DMA, RDMA, and reduction calculation components. The core component of the aggregate communication system encodes and encapsulates each field of the control command word, generates a unified control command word, and sends it to the aggregate communication execution processing component to schedule and transmit the data stream, and performs completion checks to ensure that each operation conforms to the semantics of aggregate communication. The Daemon's triggering and execution process for aggregate communication events is as follows: The Daemon program checks whether each event queue is empty according to a fixed priority; if not empty, it retrieves an event and triggers its execution. The event priorities, from highest to lowest, are: set operation completion status, RDMA handshake message, and set communication descriptor. When the set communication execution processing unit returns an execution completion status, it determines whether all operations required for the set communication have been completed based on the corresponding context information. When the RDMA unit receives a handshake message, it determines the handshake information type, extracts metadata information, and performs corresponding operations. If none of the above events are triggered and a new set communication descriptor is available, the descriptor is retrieved, parsed, and processed to construct context information and call the corresponding set communication semantic implementation.

[0035] In this embodiment, the aggregated communication context component is the core data structure for implementing non-blocking aggregated communication offloading, fully encapsulating the runtime state information required for a single aggregated communication task to execute within the network interface card. The aggregated communication context component includes the transaction number (JobID), communication group member information, data buffer address, source address, destination address, message size, current progress, and valid bits. During the initialization phase of aggregated communication, the host sends the node information within the communication domain of the current aggregated communication transaction to the aggregated communication core component. The core component encapsulates this information and records it in the aggregated communication context component. When establishing the aggregated communication context, the core component matches the node information within the communication domain with the context information. When parsing the descriptor issued by the host, the core component creates or reuses the corresponding context structure in the context cache pool based on the transaction number (JobID) in the descriptor and initializes all its state fields. The same aggregated communication transaction can directly reuse cached entries, reducing cache resource overhead and communication startup overhead. During the execution of aggregated communication, whenever an external event needs to be waited for (such as the arrival of a remote node handshake message, completion of the local protocol calculation unit, or the end of DMA transfer), the core component of aggregated communication saves the current context state and switches to the context of another ready task to continue execution, thereby achieving concurrent scheduling of multiple operations. To support efficient context switching and lookup, this embodiment designs a fast retrieval mechanism based on the transaction number JobID. When the triggering condition of an event is met, the core component of aggregated communication can quickly locate the corresponding context based on the transaction number JobID carried in the event, restore its saved execution state, and continue to execute subsequent operations until the task is completed and the host is notified. In addition, the context supports error handling and retry mechanisms for aggregated communication. If an abnormal operation state occurs during communication, the core component of aggregated communication can attempt to recover or re-initiate the relevant sub-operations through the state information saved in the context, enhancing fault tolerance.

[0036] In this embodiment, non-blocking set communication offloading is implemented based on an event-triggered mechanism. By decoupling the execution flow of set communication from event notifications, it achieves the scheduling and execution of multiple concurrent operations. The set communication execution processing unit handles various asynchronous events that occur during set communication execution in a unified manner, realizing event buffering and priority scheduling, thereby maximizing the overlap between communication and computation under the premise of limited hardware resources. This embodiment focuses on three types of events: set operation completion status, handshake messages, and set communication descriptors. The event processing unit sets up event queues, each queue corresponding to the event type of different stages of set communication. The core set communication component uses a polling strategy based on fixed priorities to check and process the event queues, ensuring that high-priority events are responded to in a timely manner. At the same time, since high-priority events are usually waiting events of the set communication that are executed first, they will not block the execution of subsequent descriptors when their events are not triggered. The three types of event queues and their processing logic will be described in order of priority below. (1) The event queue buffer for the completion status of the collective communication operation comes from the completion status of each collective operation returned by the collective communication execution processing unit, including events such as completed RDMA transmission, data forwarding and reduction calculation units. Each event encapsulates the transaction number JobID and execution result status code of the corresponding operation. When the collective communication execution processing unit completes the operation, it packages the execution result into an event and puts it into the queue. When the core component of the collective communication detects that the queue is not empty, it will take out the event at the head of the queue for parsing, retrieve the corresponding collective communication context unit according to the transaction number JobID, and update the execution progress of the task according to the event type. If all sub-operations have been completed, the process of writing the result back to the host is triggered, and the context and cache resources occupied by the task are released; if there are still uncompleted operations, it continues to wait for subsequent events. (2) The event queue buffer for the handshake message comes from the RDMA handshake message from the remote node. After receiving a handshake event, the core component of the collective communication will execute the corresponding response logic according to the transaction number JobID and message type (such as RendzInit or RendzDone) in the message: if it is an initial handshake, the corresponding control command word will be generated and sent to the collective communication execution processing component to start data transmission; if it is a completion confirmation, the context state will be updated and the next stage operation may be triggered. For tasks that are not yet ready, the handshake message can be temporarily stored in the queue and processed after its context is created, thereby avoiding data loss or protocol deadlock. (3) The collective communication descriptor event queue is used to receive the collective communication descriptors issued by the descriptor processing component. If there is no operation completion event and Rendezvous handshake message event from the collective communication execution processing component, it indicates that there is no executable collective communication operation at present. Then, a new descriptor is taken out from the descriptor queue and executed, its operation type, communication domain, data address and other parameters are parsed, the corresponding collective communication context component is created, and the corresponding collective communication semantics are called to execute the operation.Through a queue buffering mechanism, the network card can receive and cache multiple communication requests simultaneously.

[0037] In this embodiment, the aggregated communication execution processing unit is the core data processing component of the network interface card (NIC) for implementing aggregated communication offloading functionality. It mainly includes command parsing, operation execution control, and completion checking, and its structure is as follows: Figure 2 As shown. The aggregated communication execution processing unit parses the control command words issued by the aggregated communication core unit, and coordinates with the DMA unit, RDMA protocol processing unit, buffer management module, and protocol calculation unit to complete a series of operations such as data reception, forwarding, calculation, and transmission. Simultaneously, it checks the completion status of each operation to ensure the correctness of each communication operation. Operation execution control is the core module that executes corresponding operations on the data of each aggregated communication. It receives and parses the control command words issued by the aggregated communication core unit and controls the various components to coordinate and complete a data operation. This command word encapsulates all control information for a single-step operation, including the transaction number JobID, operation type, message size, source / destination address, channel configuration parameters, and protocol type. After parsing the command word, the corresponding data path is dynamically configured according to the operation type: if it is a data forwarding operation, a DMA request and an RDMA request are initiated, and a direct path from DMA to RDMA or from buffer to RDMA is established; if it is a calculation operation, a buffer allocation request and a calculation request are initiated, controlling the protocol calculation unit to perform aggregation operations on the input data stream and storing the result in the buffer; if it is the final result, a DMA or RDMA request is initiated to write back to the host or forward directly. When no allocable cache resources are available, the operation execution control will block subsequent collection communication descriptors (such as AllReduce) that contain reduction computation components. If cache resources are available, the cache management module will return a cache item information and allocate it to the operation. After execution, the operation execution control collects and checks the completion response status of each component. After the check is complete, the completion status is packaged into an operation completion status event and returned to the collection communication core component. The collection communication core component determines the completion of this collection communication operation by checking the return value of the collection operation data management component.

[0038] The reduction computation unit is the core hardware module for achieving efficient data aggregation, specifically designed for reduction computation operations in aggregated communication operations such as AllReduce and Reduce. It can perform aggregation operations on data from multiple nodes, thereby avoiding data round trips to the host CPU, effectively reducing communication latency and freeing up host computing resources. During execution, based on the operation execution control request configuration information, data from multiple operations are asynchronously input into the reduction computation unit, realizing the computation of multiple reduction tasks in a non-blocking manner. Communication overlaps, and the execution completion status is returned. In terms of hardware design, this component employs a vectorized parallel processing unit, improving computational throughput. Specifically, the reduction computation component in this embodiment includes interconnected computation control modules and an arithmetic logic unit array (ALU array). The ALU array supports some or all of the reduction semantics, including summation (SUM), maximum value (MAX), minimum value (MIN), bitwise AND, bitwise OR, and bitwise XOR. To meet different precision and type computational needs, the ALU array incorporates dedicated ALUs that can efficiently process integer (e.g., int32, int64) and floating-point (e.g., float32, float64) data, ensuring computational accuracy and efficiency in scientific computing and deep learning scenarios.

[0039] like Figure 3 As shown, the collective communication offloading engine in this embodiment also includes a collective communication data management component for caching data of collective communication tasks. This component includes a data buffer, a shared buffer queue management module, and a shared buffer queue. The shared buffer queue contains multiple cache items. The collective communication data management component caches the data of collective communication tasks in the cache items and retrieves the cached data from the cache items into the data buffer to process the data of the collective communication tasks. The collective communication data management component is used for cache allocation and reclamation of data from multiple operations. A queue-based approach is used for cache management, caching intermediate results from reduction computation components (such as AllReduce) and data from other nodes. This structure mainly includes dequeue / enqueue queue control and a cache item queue. The head pointer management module is responsible for allocating the head pointer of the cache item queue; the tail pointer management module is responsible for reclaiming released cache areas. The head pointer represents the first free address, and the position it points to stores the next free address. The tail pointer is the last free address, and the position it points to is used to store the most recently released cacheable address. When an operation execution control request allocates cache items, a free item is retrieved from the head of the queue and allocated; after the operation is completed, the corresponding cache item is released and reinserted into the tail of the queue. Cache usage information is recorded in the cache item, such as... Figure 4As shown, in this embodiment, each record in the cache item includes the following fields: JobID (transaction number), SeqID (message sequence number), Valid (cache valid signal), Address (cache block address), and Size (cache block size). Especially under the Eager protocol, the data cache address does not need to be specified before transmission, but is dynamically allocated after the data arrives. When a data packet is received, the JobID is used to check the cache queue, and the data is stored in the corresponding position of the cache according to the cache item information. Since messages may arrive interleaved, the SeqID of the network packet needs to be recorded in the cache item to facilitate the splicing of the complete message when reading it out. For the protocol operation set communication data management component, two types of buffers are allocated: (1) data receiving buffer, which stores data from other nodes; (2) intermediate result buffer, which caches the intermediate results of the protocol calculation component. For the protocol calculation component of multiple nodes, two intermediate result buffers are allocated for alternating use, that is, the buffer is used as both the result and the input for the next calculation, and vice versa.

[0040] In this embodiment, the aggregate communication offloading engine implements a non-blocking execution flow: after the host writes the descriptor into the network interface card's (NIC) descriptor queue, the aggregate communication core component extracts and parses the aggregate communication descriptor, creates a communication context for it, and saves its runtime state. The existence of the communication context allows operations to be suspended while waiting for events such as data arrival, handshake messages, and protocol calculation. The aggregate communication core component can immediately switch contexts and handle other ready operations, enabling concurrency of multiple operations. Subsequently, the aggregate communication core component initiates RDMA communication, data reduction, or forwarding operations by issuing control command words to the data management component. After each hardware component completes its execution, it generates a completion event and returns it to the corresponding queue. The aggregate communication core component resumes the execution of the corresponding context based on the event type and task ID (i.e., transaction number JobID) until the task is completed and the result is DMA-written back to the host. The descriptor processing process includes: the descriptor is constructed by the host-side aggregate communication library and written into the NIC's descriptor processing component queue through the driver. When the parsed descriptor indicates point-to-point communication, the information is directly extracted and handed over to the RDMA engine for inter-node message synchronization. After reading the data from the host memory through the DMA data path, it is encapsulated into a network packet and sent to other nodes. When the parsed descriptor indicates set communication, it is obtained and parsed by the set communication core component. If the descriptor buffer queue is not empty, a descriptor is taken from the queue and parsed. The set communication type is determined according to the set communication type Collective_Type, and the corresponding set communication semantic implementation is called. The context is constructed based on the descriptor information, and the corresponding set operation is executed.

[0041] To verify the performance advantages of the RDMA aggregated communication offloading device in this embodiment, a multi-node joint simulation experimental environment for hardware logic simulation and distributed communication simulation was constructed. This environment can accurately reproduce the entire process of aggregated communication hardware behavior and inter-node communication interaction. The configuration and testing scheme are as follows: The simulation host is deployed with the Ubuntu 20.04 LTS operating system. The experiment adopts a collaborative simulation architecture of RTL simulation + ZeroMQ: At the hardware level, the core hardware modules are modeled based on Xilinx Vivado 2022.2, and the logic simulation of this embodiment is completed at a frequency of 250MHz; at the software level, the ZeroMQ message queue framework is introduced to build a high-speed communication link between simulation nodes. Through its reliable transmission mechanism, node interaction in a distributed environment is simulated to realize the transmission of key messages such as RDMA handshake signals and data arrival notifications, supporting the simulation of multi-node communication scenarios. The two interact through the Vivado simulation library interface. The hardware simulation results are encapsulated through the interface and transmitted to the software layer through ZeroMQ. The communication instructions and status feedback of the software layer synchronously drive the hardware logic state update to ensure the consistency of software and hardware behavior. The experiment selected ACCL+, a cutting-edge solution in the field of RDMA cascaded communication offloading, as the benchmark. This embodiment built a simulation environment based on its open-source code, which includes complete cascaded communication operation support and has clear comparability. The core test metric is defined as cascaded communication latency, which covers the latency of parsing requests, communication scheduling, data transmission, local protocol, and result synchronization. To ensure data reliability, each test scenario (fixed message size and node scale) was executed 1000 times consecutively. After removing the maximum and minimum values, the average value was taken as the final result, effectively reducing the error caused by random interference.

[0042] like Figure 5 As shown, in this embodiment, the collective communication offloading engine performs RDMA collective communication offloading, which includes:

[0043] S101, initialize the collective communication descriptor queue (CCD), the operation completion status queue (OCS), and the handshake message queue (RM); the collective communication descriptor queue (CCD) is used to record the descriptors of the collective communication tasks, the operation completion status queue (OCS) is used to record the completion status of the collective communication tasks, and the handshake message queue (RM) is used to record the handshake information with other nodes in the collective communication tasks; in this embodiment, the network interface card (NIC) based computing-network converged RDMA collective communication offloading method is implemented through a Daemon (background) program, and initializing the Daemon program is equivalent to initializing the collective communication descriptor queue (CCD), the operation completion status queue (OCS), and the handshake message queue (RM);

[0044] S102, if the operation completion status queue OCS is not empty, extract the transaction number JobID of the set communication task from the operation completion status queue OCS, decrement the operand Op_num of the set communication task corresponding to the transaction number JobID by 1. If the operand Op_num after decrementing by 1 is zero, return the completion status of the set communication task corresponding to the transaction number JobID and jump to step S105; if the operand Op_num after decrementing by 1 is not zero, directly jump to step S105; if the operation completion status queue OCS is empty, proceed to the next step.

[0045] S103, if the handshake message queue RM is not empty, extract the transaction number JobID and message type Type of the collective communication task from the handshake message queue RM; if the message type Type is "Initiate handshake RendzInit", construct and issue control command words for the collective communication task corresponding to the transaction number JobID to start the processing of the collective communication task, and jump to step S105; if the message type Type is "Handshake completed RendzDone", decrement the operand Op_num of the collective communication task corresponding to the transaction number JobID by 1. If the operand Op_num after decrementing by 1 is zero, return the completion status of the collective communication task corresponding to the transaction number JobID, and jump to step S105; if the operand Op_num after decrementing by 1 is not zero, directly jump to step S105; if the handshake message queue RM is empty, proceed to the next step.

[0046] S104. If the collection communication descriptor queue CCD is not empty, extract the descriptor from the collection communication descriptor queue CCD, parse the descriptor and obtain the transaction number JobID and collection communication type Collective_Type, then create a communication context for the collection communication task corresponding to the transaction number JobID, execute the corresponding collection communication task according to the collection communication type Collective_Type, and save the communication context of the collection communication task, and then jump to step S105.

[0047] S105, determine whether the reset signal RESET is valid. If the reset signal RESET is valid, end and exit; otherwise, jump to step S102 to continue the iteration.

[0048] In step S104 of this embodiment, when executing the corresponding collective communication task according to the Collective_Type, the following steps are included: when the external event that the current collective communication task needs to wait for is not ready, suspending the current collective communication task and switching to the execution of other collective communication tasks to achieve concurrent processing of multiple collective communication tasks; and when the external event that the current collective communication task is waiting for is ready, resuming the execution of the current collective communication task until the current collective communication task is completed and the result is written back to the host through DMA operation.

[0049] In step S104 of this embodiment, when parsing the descriptor and obtaining the transaction number JobID and the collection communication type Collective_Type, the parsed collection communication type Collective_Type is one of eight collection communication types: Broadcast collection communication, Scatter collection communication, Gather collection communication, AllGather collection communication, Reduce collection communication, ReduceScatter collection communication, AllReduce collection communication, and AlltoAll collection communication.

[0050] In this embodiment, each record in the Operation Completion Status Queue (OCS) includes the transaction number JobID and the operand Op_num of the set communication task. The transaction number JobID is used to distinguish different set communication tasks, and the operand Op_num is used to record the number of operations that the set communication task has not yet completed. The operand Op_num is initialized to the total number of operations of the set communication task.

[0051] In this embodiment, each record in the handshake message queue RM includes the transaction number JobID of the collection communication task and the message type Type. The message type Type is used to record the message type of the handshake message, including initiating handshake RendzInit and handshake completing RendzDone.

[0052] like Figure 6As shown in this embodiment, each record (descriptor) in the Collective Communication Descriptor Queue (CCD) includes the following fields: JobID, Collective Communication Type, Data Count, Communicator Address, Destination Rank, Reduction Type, Source Operand 0 Address (Op0_Address), Source Operand 1 Address (Op1_Address), and Result Address (Result_Address). The descriptor format contains detailed information about this collective communication task, and the core component of collective communication executes the corresponding collective communication operation by parsing the descriptor. The Collective_Type is used to identify different types of collective communication operations (such as AllReduce, AlltoAll, etc.), Count is used to record the number of messages in the collective communication task, Communicator is used to record the address of the communicator required by the collective communication task, Destination_Rank is used to record the communication target of the collective communication task, Reduction_Type is used to record the type of reduction operation used by the collective communication task (such as SUM, MAX, MIN, AND, OR, XOR, etc.), Op0_Address (source operand 0) and Op1_Address (source operand 1) are used to record the memory addresses of the source operands of the collective communication task, and Result_Address (result) is used to record the memory address of the operation result of the collective communication task.

[0053] In this embodiment, the communication context of the collective communication task includes the transaction number JobID, communication group member information, data buffer address, source address, destination address, message size, current progress, and valid bits.

[0054] To verify the message latency of the computing-network converged RDMA aggregated communication offloading device in this embodiment under different aggregated communication types and message sizes, this experiment tested the message latency of eight typical aggregated communication types (Broadcast, Scatter, Gather, AllGather, Reduce, ReduceScatter, AllReduce, and AlltoAll) and different message sizes ranging from 128 bytes to 32KB. Figure 7The end-to-end message latency comparison for each collection communication type is shown in the same experimental environment with 16 nodes, where (a) is the end-to-end message latency of Broadcast operation; (b) is the end-to-end message latency of Scatter operation; (c) is the end-to-end message latency of Gather operation; (d) is the end-to-end message latency of AllGather operation; (e) is the end-to-end message latency of Reduce operation; (f) is the end-to-end message latency of ReduceScatter operation; (g) is the end-to-end message latency of AllReduce operation; and (h) is the end-to-end message latency of AlltoAll operation. First, Figure 7 Experimental results show that the computing-network converged RDMA aggregated communication offloading device of this embodiment exhibits superior performance compared to software aggregated communication in eight typical aggregated communication scenarios, demonstrating the performance advantage of the computing-network converged RDMA aggregated communication offloading device in aggregated communication offloading. This verifies that the computing-network converged RDMA aggregated communication offloading device of this embodiment can flexibly adapt to different communication semantics, and its lightweight design and unified scheduling mechanism can effectively coordinate various hardware components to complete the corresponding aggregated operations. Secondly, from... Figure 7 As can be observed from the latency curves, in the small message range of less than 4KB, the latency of this embodiment remains relatively stable. This is because this embodiment supports a larger message granularity for concurrent processing. Secondly, in the message range of more than 4KB, thanks to the lightweight core's decoupling of collection communication control and operation execution, the overhead of the collection communication core component accounts for a small proportion of the operation execution and data transmission path. However, because messages larger than 4KB need to be processed in blocks and split into multiple data packets for transmission, the latency shows a linear growth trend. This verifies the efficiency of the collection communication execution processing component and cache management strategy in this embodiment, which can flexibly support different message sizes.

[0055] This embodiment also provides a computer device, including a microprocessor and a network communication device that are interconnected. The network communication device is the network interface card-based RDMA aggregated communication offloading device in this embodiment.

[0056] To verify the effectiveness of the non-blocking execution mechanism of the computing network converged RDMA collection communication offloading device in this embodiment under multi-operation concurrent scenarios, this experiment designed an experimental scenario with 16 nodes and 8-way operation concurrency. The latency of Gather, AlltoAll, Reduce and AllReduce operations was tested with message sizes ranging from 128B to 32KB, and the existing accelerator ACCL+ was used as a comparison. Figure 8This invention presents a comparison of end-to-end message latency in a multi-operation concurrent scenario, where (a) represents the end-to-end message latency of an 8-way Gather operation; (b) represents the speedup ratio of an 8-way Gather operation; (c) represents the end-to-end message latency of an 8-way AlltoAll operation; (d) represents the speedup ratio of an 8-way AlltoAll operation; (e) represents the end-to-end message latency of an 8-way Reduce operation; (f) represents the speedup ratio of an 8-way Reduce operation; (g) represents the end-to-end message latency of an 8-way AllReduce operation; and (h) represents the speedup ratio of an 8-way AllReduce operation. Figure 8 The test results of 8-way Gather operation concurrency shown in (a) and (b) in this embodiment demonstrate that the RDMA aggregated communication offloading device in this embodiment achieves a speedup of 2.93 times under 8KB messages, while the speedup ratio gradually decreases for messages smaller than 8KB and larger than 8KB. The former is due to the increased overhead of the core components of aggregated communication under larger messages, while the latter is because the critical path under larger messages lies in memory access and network transmission. Figure 8 The test results for 8-way All-to-All concurrent operations shown in (c) and (d) demonstrate that the computing-network converged RDMA aggregated communication offloading device in this embodiment achieves a maximum speedup of 1.7 times in this most complex communication mode. For large messages exceeding 16KB, the performance improvement is significant, mainly due to the effective management of multiple concurrent connections by the communication context management mechanism. For example... Figure 8 The test results of 8-way Reduce operation concurrency shown in (e) and (f) in the figure show that the computing network converged RDMA aggregated communication offloading device in this embodiment can achieve a maximum speedup of 2.83 times in the Reduce test. Figure 8The test results for the concurrent 8-way Reduce operations shown in (g) and (h) demonstrate that the RDMA-based aggregated communication offloading device of this embodiment achieves a maximum speedup of 2.47 times in the AllReduce test. This indicates that the lightweight aggregated communication core component of the RDMA-based aggregated communication offloading device of this embodiment can effectively coordinate multi-stage hybrid operations. While executing the reduction calculation component, the network interface card can process subsequent descriptors and their corresponding operations, instead of blocking and waiting for the results of the reduction calculation component. Furthermore, the collaborative design of data management and the reduction calculation component unit enables efficient caching and computation of network data, avoiding additional data copying overhead. Comparative experiments with the existing ACCL+ scheme show that, compared with the ACCL+ blocking execution method, the RDMA-based aggregated communication offloading device of this embodiment achieves considerable speedup in Gather, Reduce, AllReduce, and AlltoAll operations, with the most significant performance improvement under medium message sizes. By using a non-blocking event-triggered mechanism and a collection of communication context components for management, this embodiment can effectively coordinate the data streams of multiple concurrent operations, achieve efficient overlap of computation and communication, and significantly reduce the resource idleness and waiting overhead caused by blocking execution.

[0057] To verify the scalability of the compute-network converged RDMA aggregated communication offloading device in this embodiment under different node scales, this experiment tested the change in aggregated communication latency as the number of participating nodes (from 2 nodes to 16 nodes) increased under a fixed message size (4KB). The experiment compared the node number scalability of the compute-network converged RDMA aggregated communication offloading device in this embodiment with the existing ACCL+ solution in 8-way concurrent Gather and Reduce operations. Figure 9 The comparison of node scale expansion test results in the embodiments of the present invention is shown, where (a) is the end-to-end message latency of 8-way Gather operation; (b) is the node scale of 8-way Gather operation; (c) is the end-to-end message latency of 8-way Reduce operation; and (d) is the node scale of 8-way Reduce operation. Figure 9 The node scaling test results for the 8-way concurrent Gather operation shown in (a) and (b) demonstrate that, compared to ACCL+, the speedup ratio of this embodiment is significantly improved as the number of nodes increases. This indicates that the computing-network converged RDMA aggregation communication offloading device in this embodiment has good scalability when handling multi-way concurrent Gather operations, and the more nodes there are, the more obvious the performance advantage becomes. Figure 9The node scaling test results for the 8-way concurrent Reduce operation shown in (c) and (d) demonstrate that the Reduce operation involves a reduction computation component. The compute-network converged RDMA aggregated communication offloading device in this embodiment allows the reduction computation component process and data transmission operations to be performed concurrently, thus maintaining a high computation-communication overlap rate. Experimental results show that as the number of nodes increases, the speedup ratio of the compute-network converged RDMA aggregated communication offloading device in this embodiment gradually increases from 1.6 times (2 nodes) to 2 times (16 nodes), reflecting the advantages of the non-blocking execution mechanism in large-scale concurrent scenarios. This indicates that the lightweight aggregated communication core component of the compute-network converged RDMA aggregated communication offloading device in this embodiment can achieve context switching without generating significant overhead between multiple concurrent operations. Simultaneously, the event triggering mechanism ensures timely response to high-priority events, reducing the accumulation of waiting time under large-scale concurrency. The node scaling test verifies the scalability of the compute-network converged RDMA aggregated communication offloading device in this embodiment in a large-scale distributed environment. The non-blocking execution mechanism effectively reduces the rate of increase in ensemble communication latency with the number of nodes, providing an effective hardware acceleration solution to support larger-scale distributed deep learning tasks and having significant practical value for the ever-expanding scale of AI training clusters.

[0058] In summary, addressing the shortcomings of existing hardware offloading mechanisms for aggregated communication (ACM) in terms of insufficient flexibility in supporting various ACM types and message sizes, as well as low concurrency efficiency, this embodiment of the compute-network converged RDMA ACM offloading device integrates lightweight and flexibly scalable ACM core components. This embodiment flexibly supports various ACM operation types and large message sizes. By combining the ACM context component with an event triggering mechanism, non-blocking concurrent execution is achieved, effectively improving the communication efficiency of concurrent tasks. Experimental results show that this embodiment of the compute-network converged RDMA ACM offloading device significantly outperforms existing solutions under various ACM operations and different message sizes, demonstrating performance advantages in multi-operation concurrent scenarios. It provides an effective hardware acceleration solution for overcoming the communication bottleneck in distributed deep learning.

[0059] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A network interface card (NIC)-based computing-network converged RDMA (Real-Time DMA) aggregated communication offloading device, characterized in that, The system includes a PCIe interface, a descriptor processing unit, a unified communication offload engine, a DMA unit, an RDMA protocol processing unit, and a network interface. The descriptor processing unit submits the metadata of the unified communication task written by the host to the unified communication offload engine. The unified communication offload engine is connected to the host via the PCIe interface and to the network interface via the RDMA protocol processing unit. The DMA unit is connected to the PCIe interface, the unified communication offload engine, and the RDMA protocol processing unit. The unified communication offload engine includes a unified communication core component, a unified communication context component, an event handling component, a unified communication data management component, a unified communication execution processing component, and a protocol calculation component. The unified communication execution processing component parses the control command words issued by the unified communication core component. If the control command word is a data forwarding operation, it initiates a DMA request and... An RDMA request establishes a direct path to the DMA component or caches the data to the RDMA protocol processing component, and completes the data reception and forwarding operations for the aggregated communication task. If the control command word is a calculation operation, a reduction calculation request is initiated to the reduction calculation component. The reduction calculation component performs aggregation operations on the input data stream, stores the results in a cache, and finally writes them back to the host by initiating a DMA request or forwards them directly to the network by initiating an RDMA request. The core components of the aggregated communication are connected to the aggregated communication context component, the event processing component, and the aggregated communication data management component. The aggregated communication context component records the communication context of the aggregated communication task. The event processing component sets up an event queue, with each event queue corresponding to the event type of different stages of the aggregated communication to support event processing at different stages of the aggregated communication. The aggregated communication data management component manages the cache of the aggregated communication task data. The collective communication offloading engine performs the RDMA collective communication offloading of the computing network convergence engine, including the following steps: S101, initialize the set communication descriptor queue CCD, the operation completion status queue OCS, and the handshake message queue RM; the set communication descriptor queue CCD is used to record the descriptors of set communication tasks, the operation completion status queue OCS is used to record the completion status of set communication tasks, and the handshake message queue RM is used to record the handshake information with other nodes in the set communication task. S102, if the operation completion status queue OCS is not empty, extract the transaction number JobID of the set communication task from the operation completion status queue OCS, decrement the operand Op_num of the set communication task corresponding to the transaction number JobID by 1. If the operand Op_num after decrementing by 1 is zero, return the completion status of the set communication task corresponding to the transaction number JobID and jump to step S105; if the operand Op_num after decrementing by 1 is not zero, directly jump to step S105; if the operation completion status queue OCS is empty, proceed to the next step. S103, if the handshake message queue RM is not empty, extract the transaction number JobID and message type Type of the collective communication task from the handshake message queue RM; if the message type Type is "Initiate handshake RendzInit", construct and issue control command words for the collective communication task corresponding to the transaction number JobID to start the processing of the collective communication task, and jump to step S105; if the message type Type is "Handshake completed RendzDone", decrement the operand Op_num of the collective communication task corresponding to the transaction number JobID by 1. If the operand Op_num after decrementing by 1 is zero, return the completion status of the collective communication task corresponding to the transaction number JobID, and jump to step S105; if the operand Op_num after decrementing by 1 is not zero, directly jump to step S105; if the handshake message queue RM is empty, proceed to the next step. S104. If the collection communication descriptor queue CCD is not empty, extract the descriptor from the collection communication descriptor queue CCD, parse the descriptor and obtain the transaction number JobID and collection communication type Collective_Type, then create a communication context for the collection communication task corresponding to the transaction number JobID, execute the corresponding collection communication task according to the collection communication type Collective_Type, and save the communication context of the collection communication task, and then jump to step S105. S105, determine whether the reset signal RESET is valid. If the reset signal RESET is valid, end and exit; otherwise, jump to step S102 to continue the iteration.

2. The network interface card-based computing-network converged RDMA aggregated communication offloading device according to claim 1, characterized in that, The reduction calculation component includes a calculation control module and an arithmetic logic unit array that are interconnected. The arithmetic logic unit array supports arithmetic logic operations including some or all of the reduction semantics, such as summation, maximum value, minimum value, bitwise AND, bitwise OR, and bitwise XOR.

3. The network interface card-based computing-network converged RDMA aggregated communication offloading device according to claim 1, characterized in that, The aggregate communication data management component includes a data buffer, a shared buffer queue management module, and a shared buffer queue. The shared buffer queue includes multiple cache entries. The aggregate communication data management component caches the data of the aggregate communication task in the cache entries and retrieves the cached data from the cache entries into the data buffer to realize the data processing of the aggregate communication task. The fields in each record in the cache entry include the transaction number JobID, the message sequence number SeqID, the cache validity signal Valid, the cache block address Address, and the cache block size Size.

4. The network interface card-based computing-network converged RDMA aggregated communication offloading device according to claim 1, characterized in that, In step S104, when executing the corresponding collection communication task according to the collection communication type Collective_Type, the current collection communication task is suspended and switched to the execution of other collection communication tasks to achieve concurrent processing of multiple collection communication tasks when the external event that the current collection communication task is waiting for is not ready. When the external event that the current collection communication task is waiting for is ready, the execution of the current collection communication task is resumed until the current collection communication task is completed and the result is written back to the host through DMA operation.

5. The network interface card-based computing-network converged RDMA aggregated communication offloading device according to claim 1, characterized in that, In step S104, when parsing the descriptor and obtaining the transaction number JobID and collection communication type Collective_Type, the parsed collection communication type Collective_Type is one of eight collection communication types: Broadcast collection communication, Scatter collection communication, Gather collection communication, AllGather collection communication, Reduce collection communication, ReduceScatter collection communication, AllReduce collection communication, and AlltoAll collection communication.

6. The network interface card-based computing-network converged RDMA aggregated communication offloading device according to claim 1, characterized in that, Each record in the Operation Completion Status Queue (OCS) includes the transaction ID (JobID) and operand count (Op_num) for the collective communication task. The JobID distinguishes different collective communication tasks, and the Op_num records the number of incomplete operations for the collective communication task, initialized to the total number of operations for that task. Each record in the Handshake Message Queue (RM) includes the transaction ID (JobID) and message type (Type) for the collective communication task. The Message Type (Type) records the message type of the handshake message, including "RendzInit" (initiating handshake) and "RendzDone" (handshake completion). Each record in the Collective Communication Descriptor Queue (CCD) includes the transaction ID (JobID), Collective Communication Type (Collective_Type), Data Count, Communicator Address, Destination Rank, and Reduction Type. The set of parameters includes Type, Source Operand 0 Address (Op0_Address), Source Operand 1 Address (Op1_Address), and Result Address (Result_Address). The Collective Communication Type (Collective_Type) identifies different types of collective communication operations. The Data Count records the number of messages in the collective communication task. The Communicator Address records the address of the communicator used by the collective communication task. The Destination Rank records the communication target of the collective communication task. The Reduction Type records the type of reduction operation used by the collective communication task. The Source Operand 0 Address (Op0_Address) and Source Operand 1 Address (Op1_Address) record the memory addresses of the source operands in the collective communication task. The Result Address (Result_Address) records the memory address of the operation result of the collective communication task.

7. The network interface card-based computing-network converged RDMA aggregated communication offloading device according to claim 1, characterized in that, The communication context of the collective communication task includes some or all of the following: JobID, communication group member information, data buffer address, source address, destination address, message size, current progress, and valid bits.

8. A computer device comprising a microprocessor and a network communication device interconnected, characterized in that, The network communication device is the network interface card-based computing-network converged RDMA aggregated communication offloading device according to any one of claims 1 to 7.

Images