Low-latency RDMA acceleration system based on memory registration

Abstract

The invention belongs to the field of computer systems, and provides a low-latency RDMA (Remote Direct Memory Access) acceleration system based on memory registration, which comprises the following steps of: registering a memory region applied by an application program by utilizing a memory pin technology in a kernel; receiving a remote direct memory access (RDMA) work request initiated by an application program, and packaging information comprising a source virtual address and a target virtual address in the request to form a work queue element; the assembly line is used for processing data receiving from a remote system and sending of local data, and hardware logic used for table look-up, QoS detection and message processing is embedded in the assembly line; the server manages the working queue, the data transmission state and the abnormal information processing in a unified manner, and is used for adjusting the transmission parameters of the RDMA acceleration system in real time according to the received context signal; a standardized software calling interface is provided, and cooperative control between software and hardware is achieved.

Description

Technical Field

[0001] The present invention belongs to the field of computer systems, and in particular relates to a low-latency RDMA acceleration system based on memory registration. Background Art

[0002] The exponential growth of data volume and business complexity in data centers has placed higher demands on low-latency, high-bandwidth data transmission capabilities between server nodes. Traditional data communication models based on the TCP / IP protocol stack require frequent context switches between kernel and user modes, as well as redundant multi-level data replication operations. This significantly increases CPU load and makes it difficult to reduce end-to-end transmission latency, severely restricting the overall performance of data center systems.

[0003] Remote Direct Memory Access (RDMA) technology, with its advantages of "zero copy," "low latency," and "low CPU utilization," has become a critical data transfer mechanism in data centers, cloud computing platforms, and high-performance computing systems. RDMA bypasses the operating system kernel and maps network interfaces directly into user space, enabling end-to-end high-speed communication between application processes. However, to ensure the security and correctness of RDMA data flows, the user memory areas involved must be registered before data transmission, their physical memory locations must be fixed, and a mapping between virtual addresses (VAs) and physical addresses (PAs) must be established.

[0004] In existing technologies, the memory registration process that RDMA relies on is usually completed by the operating system or software protocol stack. This involves traversing and managing page tables, resulting in high call overhead, poor real-time performance, and high CPU usage. Especially in high-concurrency scenarios, frequent registration and deregistration operations will further increase transmission latency and affect system throughput. Summary of the Invention

[0005] In order to solve the problems in the prior art, the present invention provides a low-latency RDMA acceleration system based on memory registration, characterized in that the system includes the following modules:

[0006] A memory registration module is used to register the memory area requested by the application using the memory pin technology in the kernel, ensuring that the memory area is fixed and cannot be swapped out, and to generate a mapping relationship table between the virtual address and the physical address of the memory area. The mapping relationship table is stored inside the DPU chip;

[0007] An RDMA work request processing module is configured to receive a remote direct memory access (RDMA) work request initiated by an application, encapsulate the information in the request, including the source virtual address and the target virtual address, into a work queue element, transmit the information to the DPU via the host channel adapter, and convert the virtual address into a physical address based on the mapping relationship table;

[0008] The data transmission pipeline module includes an inbound pipeline and an outbound pipeline, which are used to process data received from remote systems and sent to local systems, respectively. The pipelines are embedded with hardware logic for table lookup, QoS detection, and message processing to perform data transmission rate control and network congestion management according to preset policies.

[0009] A control unit module, including an address management unit, a QoS policy unit, and a congestion control unit, is used to uniformly manage the work queue, data transmission status, and exception information processing, and is used to adjust the transmission parameters of the RDMA acceleration system in real time based on the received context signal to ensure low latency and high throughput data transmission performance;

[0010] The system interface and software collaboration module is used to provide a standardized software call interface, enabling user applications or virtualization platforms to quickly register memory and initiate RDMA requests through the interface. It is also used to coordinate the operating status and information feedback between the software layer and the memory registration module, RDMA work request processing module, and control unit module, realizing collaborative control between software and hardware.

[0011] Furthermore, the memory registration module includes:

[0012] The memory pinning submodule is used to call the operating system kernel interface to pin the memory pages requested by the application in the physical memory through the memory pin technology to prevent them from being swapped out during DMA transfer;

[0013] An address mapping submodule, configured to call an operating system page table management mechanism to perform a one-to-one mapping between a virtual address and a physical address of the memory page;

[0014] A mapping upload submodule is used to write the mapping relationship table into a high-speed storage unit inside the DPU chip and use hash indexing or TCAM logic to support high-speed queries;

[0015] The address verification and release submodule is used to release the mapping table and unlock the corresponding memory page after the memory is no longer used, ensuring timely resource recovery and system security.

[0016] Furthermore, the RDMA work request processing module includes:

[0017] The request receiving submodule is used to receive the RDMA request initiated by the application through the host channel adapter HCA;

[0018] A WQE construction submodule is used to encapsulate the operation type, source virtual address, target virtual address, data length and connection identifier contained in the request into a work queue element WQE;

[0019] An address conversion submodule, configured to perform physical address mapping on the source address and the target address in the WQE based on a VA-PA mapping relationship table stored in the DPU;

[0020] The trigger scheduling submodule is used to pass the WQE that completes address resolution to the data transmission pipeline module, triggering the DMA engine to perform data read and write operations.

[0021] Furthermore, the RDMA work request processing module includes:

[0022] The historical request learning submodule is used to collect and analyze WQE generation data in the past cycle and build access frequency histograms and address heat models;

[0023] A WQE pre-construction submodule is used to predict possible future request patterns based on the historical request learning submodule and construct a WQE structure in advance;

[0024] The pre-decoding mapping submodule is used to map the virtual address contained in the pre-built WQE into a physical address in advance and store it in the pre-decoding pool;

[0025] A matching and correction submodule is used to perform structural matching with the WQE in the pre-decoding pool when the actual request arrives. If the difference is within the tolerance range, some fields are corrected to complete the fast matching;

[0026] The fast trigger scheduling submodule is used to send the successfully matched WQE directly to the data transmission pipeline, skipping the standard construction and table lookup process to reduce processing latency.

[0027] Furthermore, the data transmission pipeline module includes:

[0028] The inbound protocol parsing submodule is used to perform protocol decoding on received data packets, including UDP / IP layer and RDMA layer field parsing;

[0029] The address location submodule is used to call the table lookup logic to obtain the physical address corresponding to the target virtual address from the MTT table;

[0030] QoS feedback control submodule, which monitors the status of the receiving path buffer and sends congestion notifications to the peer end when the load exceeds the threshold;

[0031] The data delivery submodule is used to write the received data payload into the located target physical address space;

[0032] WQE decoding submodule, used to extract the operation type, address and length information in WQE;

[0033] The address retrieval submodule is used to perform address lookup on the source VA and the target VA in the outgoing path;

[0034] QoS rate shaping submodule, used to reduce the packet sending rate when the network load is too high;

[0035] The message generation and sending submodule is used to complete the message encapsulation, CRC check and output to the network interface.

[0036] Furthermore, the data transmission pipeline module further includes:

[0037] Heterogeneous processing node pool, including semantic recognition nodes, table lookup nodes, QoS nodes, rate shaping nodes, and lightweight compression nodes, each with independent configuration parameters;

[0038] The task semantic parsing submodule is used to generate the transmission semantic descriptor TSD according to the fields in the WQE;

[0039] The structure scheduling graph generation submodule is used to generate the structure scheduling graph SDG based on TSD and the current system status;

[0040] On-chip switch grid configuration submodule, used to configure the connection paths between nodes according to SDG, realizing the dynamic combination of node-level pipeline order and connection status;

[0041] The path learning and updating submodule is used to record the path performance indicators after the task is completed and update the scheduling template priority to improve the subsequent scheduling effect.

[0042] Furthermore, the control unit module includes:

[0043] The address registration submodule is used to query or register the newly appeared virtual address mapping in the MTT table;

[0044] Mapping maintenance submodule, used to regularly refresh mapping entries and verify mapping consistency;

[0045] Conflict detection submodule, used to identify and prevent multiple VAs from being mapped to the same PA or repeated registration mapping conflicts;

[0046] The task classification submodule is used to identify the task type based on the fields in the WQE;

[0047] The policy configuration submodule is used to allocate QoS channels, delay budgets, and rate caps;

[0048] Real-time policy adjustment submodule, used to modify task scheduling parameters in real time based on network feedback information;

[0049] Buffer monitoring submodule, used to monitor queue length and traffic burst indicators;

[0050] Flow control feedback submodule, used to trigger congestion feedback packets;

[0051] The exception handling submodule is used to handle mapping failure, transmission interruption and retransmission exception events.

[0052] Furthermore, the system interface and software collaboration module includes:

[0053] The software interface encapsulation submodule is used to provide standard calling interfaces, including rdma_register_memory() for memory registration, rdma_post_send() for sending RDMA requests, and rdma_query_status() for querying system status;

[0054] The protocol translation and scheduling submodule is used to encapsulate the calling interface parameters into a standard message structure, including an operation code, a parameter array and a token identifier, and send it to the target module.

[0055] Furthermore, the system interface and software collaboration module further includes:

[0056] The status feedback coordination submodule is used to monitor the status events generated by the control module and return them to the software interface in the form of an event structure, including MTT registration failure, WQE execution error, and network congestion upgrade information. It also supports two feedback mechanisms: active polling and passive callback.

[0057] Furthermore, the system interface and software collaboration module further includes:

[0058] The virtualization adapter module is used to allocate vRDMA interfaces to each virtual machine in a virtualized environment and map host DPU resources to the virtual machine through the SR-IOV or VFIO mechanism to achieve RDMA isolation and access support in a multi-tenant environment.

[0059] The present invention provides a low-latency RDMA acceleration system based on memory registration. By integrating five functional modules—memory registration, request processing, data pipelining, and control and interface collaboration—into the DPU chip, the system significantly optimizes the performance and deployment capabilities of the RDMA system in multiple dimensions. Specific beneficial effects include:

[0060] Kernel-level memory pin technology is used to pin application memory pages and build a VA-PA mapping table inside the DPU, avoiding operating system intervention and multi-level address mapping processes, achieving nanosecond address resolution, and effectively improving system throughput and transmission consistency.

[0061] The RDMA request is directly encapsulated by the WQE and address table lookup by the DPU internal module without CPU intervention, avoiding frequent switching between user mode and kernel mode, and significantly reducing the average response time from request submission to transmission start.

[0062] A predictive reconstruction mechanism based on request pattern learning is introduced, and a pre-decoding WQE pool is constructed using historical request statistics. Address resolution and WQE generation are completed in advance in prediction scenarios. Direct and rapid matching and scheduling can be achieved upon request arrival, making it suitable for high-density structured access and further compressing critical path latency.

[0063] Build a dynamically orchestrated data transmission pipeline structure, provide heterogeneous processing node pools and scheduling graph-driven pipeline structure reconstruction capabilities, implement personalized processing paths under different task types, enhance the system's processing capabilities for sudden loads and multi-type services, and improve system adaptability and resource utilization.

[0064] A multi-dimensional control unit is set up to achieve unified management of QoS, congestion and anomalies. By collecting data path status in real time, the rate and channel configuration are dynamically adjusted according to task priority and feedback information to avoid congestion spread and data blocking, ensuring the stability and high reliability of the system under complex network conditions.

[0065] It provides standardized software interfaces to achieve software-hardware collaboration and virtualization support, and offers a unified API that supports functions such as rdma_register_memory and rdma_post_send, simplifying the development process. It also implements fault awareness through a status feedback mechanism and supports vRDMA deployment on virtualization platforms such as KVM and Xen, improving system versatility and deployment flexibility.

[0066] In summary, the system of the present invention realizes structural optimization, latency reduction, dynamic resource scheduling and virtualization adaptation of the RDMA acceleration path, and has the advantages of high performance, high compatibility, and high controllability. It is suitable for application scenarios with extremely high requirements for data transmission performance, such as supercomputing centers, cloud platforms, high-frequency trading, and large-model training. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0068] Figure 1 It is a system diagram of the method of the present invention. DETAILED DESCRIPTION

[0069] Below, the invention is preferably described with reference to the accompanying drawings and specific embodiments.

[0070] This embodiment solves the above problem through the following steps:

[0071] In one embodiment, reference Figure 1 The present invention provides a low-latency RDMA acceleration system based on memory registration. By introducing a hardware-level memory registration mechanism in the remote direct memory access (RDMA) transmission process, it can achieve fast fixation of user-mode memory and efficient mapping of virtual addresses to physical addresses. The mapping information is embedded in the internal logic resources of the acceleration chip (such as the DPU built on FPGA). Combined with the pipelined data path and the intelligent scheduling control module, it completes the high-speed parsing and direct addressing of RDMA work requests, thereby achieving zero-copy high-throughput and microsecond-level low-latency transmission of application data between the network interface and the main memory. It is suitable for scenarios with strict requirements on low latency and high concurrent transmission performance in high-performance computing, data center networks and virtualization environments. The system specifically includes the following modules:

[0072] The memory registration module is used to register the memory area requested by the application using the memory pin technology in the kernel, ensuring that the memory area is fixed and cannot be swapped out, and generating a mapping relationship table between the virtual address and the physical address of the memory area. The mapping relationship table is stored inside the DPU chip.

[0073] In the RDMA system, in order to achieve high throughput and low latency data transmission, the multi-level copy link between the data path from user state to the device must be compressed into In traditional systems, the operating system allows page frames to be swapped out during operation for greater flexibility in memory management. This makes the physical address unfixed and makes it difficult to support the physical addressing requirements of the DMA engine.

[0074] To this end, the system's memory registration module uses kernel-level memory pinning technology to pin the memory pages accessed by applications to physical memory and establish a static mapping between virtual addresses (VA) and physical addresses (PA). This mapping table is embedded in high-speed logic resources within the DPU (such as an FPGA), ensuring that RDMA requests can quickly perform table lookups and complete physical address location, completely bypassing operating system and CPU intervention. This design is the key foundation for achieving zero-copy RDMA and microsecond latency.

[0075] In the present invention, memory pin refers to a mechanism provided by the operating system kernel for pinning a memory page corresponding to a certain virtual address in the main memory to prevent it from being swapped out or moved during DMA.

[0076] A virtual address (VA) refers to the logical address used by user space programs to access memory, and the actual physical address can only be obtained through address mapping.

[0077] A physical address (PA) is the actual address that a processor or DMA engine uses to access physical memory.

[0078] The VA-PA mapping table is a data structure that records the mapping relationship between virtual addresses and their corresponding physical addresses, and is used to accelerate address translation.

[0079] DPU (Data Processing Unit) refers to a programmable hardware unit with network processing capabilities that can carry protocol stack offload and data plane logic, such as an acceleration chip implemented by FPGA.

[0080] In a specific implementation, the memory registration module can be further divided into the following submodules:

[0081] The memory fixing submodule is used to call the kernel interface (such as mlock(), get_user_pages() or equivalent interface) to fix the transfer memory requested by the user application.

[0082] Specifically, let the starting address of the memory area requested by the application be VA start The page size is P, with a total of N pages, and the following process is traversed:

[0083] for i=0toN-1:lock_page(VA start +i·P)

[0084] The address mapping submodule is used to call the operating system page table management function to obtain the physical address corresponding to each virtual page.

[0085] For each page:

[0086] PA i =translate(VA start +i·P)

[0087] Finally, a mapping table is formed:

[0088] MAP={(VA i ,PA i )|i=1,...,N}

[0089] The mapping upload submodule is used to write the above mapping table into the DPU chip, such as the BRAM resource of the FPGA, for subsequent RDMA work request calls.

[0090] An indexing mechanism such as a hash table or Ternary CAM can be set to implement O(1) level table lookup.

[0091] The address check and release submodule performs the VA-PA mapping revocation and physical page unlocking operations after the task is completed to release system resources and maintain data security.

[0092] By preregistering memory within the DPU and solidifying the VA-to-PA mapping, this module avoids operating system intervention during each RDMA data transfer, eliminating scheduling jitter and address translation delays caused by CPU intervention. Compared to traditional RDMA implementations that use a software stack for address resolution and mapping, this invention significantly reduces latency in the data path while improving throughput efficiency, making it a key foundational module for implementing high-performance RDMA services at the data center level.

[0093] Specifically, taking host A as an example, if a user program needs to use a memory segment for an RDMA write operation, the system performs the following process:

[0094] The user registers memory with the RDMA system by calling the API rdma_register_mem(ptr,size);

[0095] The DPU triggers a kernel call to pin the segment from VA = 0x10000000 to VA = 0x10010000 (size 64KB) to main memory;

[0096] Generate the mapping:

[0097] 0x10000000→0x3FA00000

[0098] 0x10001000→0x3FA01000 ...

[0100] 0x1000F000→0x3FA0F000

[0101] Storing the mapping table in the T-CAM module in the DPU;

[0102] When an RDMA request arrives, the DPU quickly retrieves the PA corresponding to the target address from the mapping table and initiates DMA transfer;

[0103] Data is written directly from the physical memory of host A to the physical memory of host B. The entire process bypasses kernel state and CPU copying, achieving end-to-end data write latency of <5μs.

[0104] The RDMA work request processing module is used to receive remote direct memory access (RDMA) work requests initiated by applications, encapsulate the information including the source virtual address and the target virtual address in the request into a work queue element, transmit it to the DPU through the host channel adapter, and convert the virtual address into a physical address based on the mapping relationship table.

[0105] In the RDMA system, implementation Efficient direct data exchange relies on the application explicitly specifying memory addresses as the data source and destination. However, the application layer holds virtual addresses (VA), while DMA transfers require physical addresses (PA), so the system must complete address translation before data transfer.

[0106] To avoid context switching and call delays caused by the operating system's involvement in address translation, the present invention uses hardware offload to deploy the RDMA work request processing module inside the DPU to achieve the following goals:

[0107] Receive RDMA requests from the application layer;

[0108] Extract the address and operation information from the request and encapsulate it into a work queue element (WQE);

[0109] Call the MTT mapping table to quickly complete the VA→PA conversion;

[0110] Trigger the pipeline module to perform DMA transfer to ensure the establishment of a low-latency, high-throughput communication path.

[0111] This module is the core scheduling and initiation module of the RDMA acceleration system, which determines the resource utilization efficiency and real-time response capability of the entire system.

[0112] In the present invention, a WQE (Work Queue Element) is a data structure used to describe all information required for an RDMA operation, including operation type (write / read), source address, target address, data length, etc.

[0113] The Host Channel Adapter (HCA) serves as a bridge between the application process and the DPU hardware, and is responsible for sending user-mode requests to the DPU.

[0114] The MTT table (Memory Translation Table) is a pre-built VA→PA mapping lookup table in the DPU.

[0115] Physical address translation is the process of mapping a virtual address (VA) to a physical address (PA) for the DMA engine to locate physical memory pages.

[0116] In a specific implementation, the RDMA work request processing module can be divided into the following submodules:

[0117] The request receiving submodule is used to monitor RDMA initiation instructions from the application and send the request to the DPU through the HCA. The request format includes:

[0118] Req=(Opcode,Src_VA,Dst_VA,Length,Conn_ID)

[0119] in:

[0120] Opcode represents the operation code (read / write);

[0121] Src_VA is the source virtual address;

[0122] Dst_VA is the target virtual address;

[0123] Length is the length of data transmission bytes;

[0124] Conn_ID is the connection identifier.

[0125] The WQE construction submodule is used to encapsulate the above request content into a work queue element WQE and write it into the send queue (Send Queue). The structure of WQE is as follows:

[0126] WQE=[Opcode,Src_VA,Dst_VA,Length]

[0127] And cooperate with the QP table (Queue Pair) to maintain the connection status.

[0128] The address translation submodule searches the MTT table inside the DPU based on the source and destination addresses:

[0129] PA src =MTT_lookup(Src_VA),PA dst =MTT_lookup(Dst_VA)

[0130] If the address page spans or is not registered, an error status is fed back to the control unit.

[0131] The scheduling submodule is triggered. After the address resolution is completed, the physical address and data length are transmitted to the data transmission pipeline module to initiate DMA writing or reading.

[0132] By moving the entire WQE construction and address mapping process to the DPU hardware and combining it with a high-speed VA→PA mapping table lookup mechanism, this significantly reduces the preparation time for RDMA operations, improves the number of requests processed per second (IOPS), and eliminates the performance overhead caused by frequent context switches between user mode and kernel mode. Compared to traditional solutions where the CPU assists with WQE encapsulation and address resolution, this approach achieves lower request initiation latency and higher RDMA throughput efficiency.

[0133] Specifically and illustratively:

[0134] Host A registers a 64KB memory block starting at VA = 0x10000000 and completes the VA→PA mapping. Now the application initiates the following RDMA write operation on Host A:

[0135] The application calls the API:

[0136] rdma_write(remote_conn_id,0x10000000,0x20000000,65536)

[0137] The request format is as follows:

[0138] Req=(WRITE,0x10000000,0x20000000,65536,Conn01)

[0139] HCA encapsulates the request as a WQE:

[0140] WQE=[WRITE,0x10000000,0x20000000,65536]

[0141] DPU is obtained through the MTT table:

[0142] VA 0x10000000→PA 0x3FA00000

[0143] VA 0x20000000→PA 0x4FB00000

[0144] The DMA engine is scheduled to read data from PA 0x3FA00000 and write data to PA 0x4FB00000 in host B.

[0145] The entire transmission does not require CPU participation, and the end-to-end delay is controlled within 3 to 5 microseconds, which is far superior to the traditional TCP / IP protocol stack mode.

[0146] RDMA request processing is passive. Only after the application explicitly initiates a work request does the DPU receive the request, parse the parameters, construct a WQE, perform a table lookup to decode the address, and finally initiate the data transfer. While this model is superior to the software approach, it is still a synchronous processing mechanism and cannot break the sequential dependency of "WQE construction - address decoding - transfer initiation." Furthermore, for high-performance systems with highly concentrated and regular access behavior, this processing flow still has room for optimization.

[0147] To further overcome this limitation, this embodiment proposes a predictive reconfiguration mechanism based on request pattern learning. By learning historical WQE distribution, access timing, and address locality, it proactively constructs a WQE structure and decodes address mappings in advance before all new requests arrive at the DPU, forming a pre-decoded WQE pool. When an actual request arrives, only a few parameters need to be modified to schedule the transmission directly, significantly reducing control path latency.

[0148] Specifically, the predictive reconstruction mechanism based on request pattern learning is implemented through the following modules:

[0149] The historical request learning submodule is used to count and analyze the WQE generation sequence within a period of time and extract its characteristics such as address distribution heat, access interval period, operation type, etc.

[0150] For example, to construct a frequency histogram:

[0151]

[0152] And establish a priority prediction model.

[0153] The WQE pre-construction submodule predicts the upcoming WQE structure based on historical statistical results and generates:

[0154] WQE=[Opcode,Src_VA,Dst_VA,Length]

[0155] The pre-decoding mapping submodule maps the VA in the predicted WQE to PA in advance:

[0156] PA src =MTT(Src_VA),PA dst =MTT(Dst_VA)

[0157] And (WQE,PA src ,PA dst ) is stored in the "pre-decoding WQE pool".

[0158] In the matching and correction submodule, when an actual request arrives, the DPU first performs a fuzzy match with the "pre-decoding WQE pool":

[0159] min i ||WQE i -Req new ||<

[0160] If the match is successful, you only need to modify 1 to 2 parameters (such as length, target address) and it can be delivered directly.

[0161] The scheduling submodule is quickly triggered to push the successfully matched WQE to the DMA engine immediately, eliminating the need for a complete build and mapping path, thus shortening the path latency.

[0162] Compared to the traditional WQE synchronous build-table lookup-transmission scheduling process, this embodiment introduces prediction, pre-build, pre-decoding, and rapid correction mechanisms to pre-build "semi-finished WQEs" for possible future requests, enabling rapid connection to actual requests. This significantly reduces average request processing latency in scenarios with high hit rates, especially in scenarios with highly regular access patterns such as data centers, AI inference tasks, and graph databases.

[0163] The data transmission pipeline module includes an inbound pipeline and an outbound pipeline, which are respectively used to handle data reception from remote systems and transmission of local data. The pipeline is embedded with hardware logic for table lookup, QoS detection and message processing to perform data transmission rate control and network congestion management according to preset strategies.

[0164] In an RDMA system, data must flow quickly through multiple processing stages, including address resolution, protocol decoding, cache integration, QoS control, and ultimately, transmission / reception. If all these processing steps are serially executed in a non-pipelined fashion, system throughput bottlenecks will result. This is especially true in scenarios with high-concurrency RDMA requests, where accumulated delays and queue congestion can easily occur, ultimately impacting overall performance.

[0165] To address this issue, the present invention proposes a data transmission pipeline module. This module divides the data transmission path into two main paths: an inbound pipeline and an outbound pipeline, responsible for receiving remote data and sending local data, respectively. Table lookup logic, QoS detection logic, and message processing logic are embedded within the pipeline, creating an efficient "multi-stage parallel, time-sharing" path. This architecture enables precise control of transmission rates and network status while maintaining high-speed data forwarding, and is the core mechanism that supports RDMA's microsecond-level communication performance.

[0166] In the present invention:

[0167] The inbound pipeline refers to processing data packets received from the remote system and sending them to the target address through stages such as protocol analysis, address location, and transmission scheduling.

[0168] The outbound pipeline processes RDMA data packets sent from the local host to the remote end, performing operations such as packaging, QoS scheduling, and network encapsulation.

[0169] Table lookup logic refers to the high-speed VA-PA mapping retrieval unit embedded in the pipeline, which is usually implemented based on TCAM or parallel hash table.

[0170] QoS detection logic is used to determine indicators such as current bandwidth usage, packet loss rate, queue length, and adjust the sending rhythm as needed.

[0171] Message processing logic refers to operations such as message header verification, reassembly, and CRC verification, and is a mechanism to ensure the correctness of data transmission.

[0172] In a specific implementation, the data transmission pipeline module can be subdivided into the following submodule structures:

[0173] The inbound protocol parsing submodule is used to parse the network layer (UDP / IP) and RDMA layer (BTH, RETH, etc.) header fields of the received message and extract the WQE matching parameters;

[0174] Parse(Pkt)={Opcode,Dst_VA,Length}

[0175] The address positioning submodule calls the table lookup logic module, inputs the target virtual address Dst_VA, and outputs the target physical address PA:

[0176] PA = MTT_lookup(Dst_VA)

[0177] The QoS feedback control submodule is used to judge the receiving queue depth, buffer utilization, etc. If it is higher than the threshold, it will feedback the Congestion Notification Packet (CNP) to the remote end or suppress the ACK response.

[0178] The data delivery submodule is used to write the received payload data to the corresponding physical address to complete DMA reception.

[0179] The WQE decoding submodule is used to extract the data transmission request from the local WQE pool and parse the required parameters.

[0180] The address retrieval submodule is used to query the local MTT table and convert the source VA and target VA into PA respectively;

[0181] PA src=MTT(Src_VA),PA dst =MTT(Dst_VA)

[0182] QoS rate shaping submodule, used to determine the current sending rate R s and QoS limit value R max Compare, if R s >R max , execute the delayed scheduling strategy:

[0183] R adj =min(R s ,R max -δ)

[0184] Among them, δ is the feedback adjustment amount, which comes from real-time flow control information.

[0185] The message generation and sending submodule is used to encapsulate the RDMA message (with RETH / BTH header), add the IP / UDP header, calculate the CRC checksum, and send it to the network interface module for transmission.

[0186] This module effectively improves system processing concurrency and module decoupling by constructing a bidirectional parallel pipeline structure. Key steps such as table lookup, QoS, and packet processing are explicitly parallelized and phased, ensuring a stable flow of packets through the system, eliminating the need for repeated queuing between processing units and fundamentally reducing average latency. Furthermore, QoS detection logic provides real-time feedback to the remote end based on queue status, forming a "self-adjusting transmission path" that delivers high-throughput, adaptive, and scalable network processing capabilities.

[0187] In a specific example:

[0188] Example of host A transferring 64KB of data to host B via RDMA:

[0189] Outbound process:

[0190] After the application layer registers the memory, the DPU generates a WQE:

[0191] WQE=[WRITE,0x10000000,0x20000000,65536]

[0192] Extract WQE from the outbound pipeline and query:

[0193] 0x10000000→0x3FA00000,0x20000000→0x4FB00000

[0194] The QoS module detects that the current network is idle and allows sending;

[0195] Packet Packaging:

[0196] Pkt=IP+UDP+BTH+Payload 64KB

[0197] The message is sent to host B through the Ethernet port.

[0198] Inbound process (host B):

[0199] The inbound pipeline receives the message and parses it to obtain the write operation and target VA;

[0200] Get the target PA by looking up the table and write it directly into the target memory;

[0201] If the receive buffer is close to the upper limit, the QoS module triggers CNP feedback to slow down the sending rate of host A.

[0202] Through this pipeline processing method, the entire 64KB data packet takes less than 5μs from request initiation to writing completion, which is far superior to the traditional non-pipelined processing model.

[0203] The structure of RDMA data transmission pipeline modules is typically static, meaning that the processing steps (such as table lookup → QoS determination → packet encapsulation) are pre-set during system design and fixed to a logical path. While this approach works well for certain types of data loads, it is prone to path redundancy, processing bottlenecks, resource waste, and difficulty in effective regulation when faced with sudden task switching in multiple scenarios, high-frequency load fluctuations, and fused data structures.

[0204] To address this structural rigidity, this embodiment further proposes a dynamically orchestrated pipeline architecture (DOPA). By introducing a module-level swappable scheduler and heterogeneous processing nodes, the pipeline's processing stage sequence, depth, granularity, and state retention method can be dynamically configured at runtime. The system generates the optimal pipeline orchestration structure based on the current task type, data characteristics, and timing window, enabling "instant reconstruction" of the processing path. This is achieved through the following steps:

[0205] 1. Build a heterogeneous processing node pool

[0206] Multiple processing nodes with different functions are pre-deployed in the DPU chip logic area. Each node has standardized input / output interfaces (such as AXI-Stream) and configurable status registers, including but not limited to:

[0207] LUT_Node: performs VA→PA high-speed table lookup mapping;

[0208] DQoS_Node: performs multi-dimensional quality detection, such as real-time bandwidth usage and priority factor analysis;

[0209] Shaper_Node: Dynamically adjusts the transmission rate;

[0210] Semantic_Node: identifies the data packet content type;

[0211] LightCompress_Node: Performs lightweight compression to reduce network load.

[0212] The behavior of each node is controlled by the Control Status Word (CSW), which has the following form:

[0213] CSW i ={Mode,Enable,Thresholds,RoutingID}

[0214] in:

[0215] Mode indicates the node operation mode;

[0216] Enable indicates whether the node is enabled;

[0217] Thresholds represent adjustment parameters such as rate and priority;

[0218] RoutingID indicates the node ID, which is used for routing mapping.

[0219] 2. Receive and parse the Transport Semantics Descriptor (TSD)

[0220] The DPU work request processing module compresses the high-level information corresponding to each RDMA request into TSD:

[0221] TSD={T type ,S size ,P priority ,D dest ,C class}

[0222] For example:

[0223] T_type:WRITE

[0224] S_size:2048

[0225] P_priority:HIGH

[0226] D_dest:Host B

[0227] C_class:STRUCTURED

[0228] The TSD takes the incoming scheduler (Scheduler Core) as the basis for path construction.

[0229] 3.Structural scheduling diagram construction phase

[0230] The scheduler jointly analyzes the TSD and the current state of the system, calls the path template matching logic, and builds the structural scheduling graph (SDG) of the task:

[0231] The system maintains a set of template graph sets (Template Graph Set), such as:

[0232] Template A (structured packet):

[0233] Semantic Node→LUT Node→DQoS Node

[0234] Template B (streaming package):

[0235] LUT Node→Shaper Node→LightCompress Node

[0236] By comparing similarity functions:

[0237]

[0238] in:

[0239] f j Indicates the field matching function (e.g. whether it is high priority, whether it is structured);

[0240] w j Indicates the weight of each field;

[0241] If the maximum similarity > the threshold, the corresponding template is selected to construct the SDG.

[0242] SDG is essentially a directed graph structure:

[0243] SDG=(V,E),V={N1,N2,...,N k},E={(N i ,N j )}

[0244] Each node contains running instructions and address configuration, which are passed to the subsequent orchestrator.

[0245] 4. Orchestrated Switching Mesh Configuration Phase

[0246] Physically connect the required nodes by configuring the MUX / DEMUX paths in the on-chip switch matrix:

[0247] For each node N i , assign input / output port numbers:

[0248] Portin (N i ),Port out (N i )

[0249] Configure the port wiring logic in the switching mesh as follows:

[0250]

[0251] This process is accomplished by switching configuration tables, for example:

[0252] Path_ID=21

[0253] Step 1:Route Semantic_Node.Out→LUT_Node.In

[0254] Step 2:Route LUT_Node.Out→DQoS_Node.In

[0255] The scheduler writes the CSW_i parameter to each node at the same time to activate the node working state.

[0256] 5. Data processing and scheduling stage

[0257] After the pipeline is established, the data packet enters the pipeline and is processed in multiple nodes in a stage-by-stage manner:

[0258] Semantic recognition: Determine the data structure and decide whether to perform variable-length adaptation or redundancy detection;

[0259] Address lookup table: output PA according to VA lookup table;

[0260] QoS judgment: Comprehensively consider the current network usage, peer congestion feedback, and task priority, and output control instructions.

[0261] All nodes operate in a stream processing mode, and data frames carrying metadata flow through each node, and can also be accompanied by interrupt signals returned to the control module.

[0262] 6. Path evaluation and self-learning stage

[0263] After each treatment is completed, the control unit will record:

[0264] The average delay of the path

[0265] Processing time of each node

[0266] QoS feedback frequency

[0267] Exception / interruption information

[0268] The system updates the performance score of the template based on these indicators, giving priority to paths with better results in subsequent similar tasks, forming a self-learning path selection mechanism.

[0269] Specifically and illustratively:

[0270] Host A sends a batch of small structured data packets:

[0271] The system recognizes TSD as a structured high-priority packet;

[0272] Construction path: Semantic Node→LUT Node→DQoS Node;

[0273] The actual configuration of the path is as follows

[0274] MUX0:Semantic.Out→Switch_A.0

[0275] Switch_A.0→LUT.In

[0276] LUT.Out→Switch_B.1

[0277] Switch_B.1→DQoS.In

[0278] DQoS.Out→NetIF

[0279] The entire path establishment time is 120ns, and the average processing delay is 450ns / packet;

[0280] The control module evaluates that the path performance is good and updates its Template priority to level 1.

[0281] The control unit module includes an address management unit, a QoS policy unit, and a congestion control unit, which are used to uniformly manage the work queue, data transmission status, and exception information processing, and to adjust the transmission parameters of the RDMA acceleration system in real time according to the received context signal to ensure low latency and high throughput data transmission performance.

[0282] The transmission path of the RDMA acceleration system has achieved hardware offload and high-speed pipeline processing, but data transmission is not a static linear process. In real data center operations, the following problems often occur:

[0283] Instantaneous congestion caused by network traffic bursts;

[0284] Resource conflicts between different work queues;

[0285] Delays in important tasks caused by imbalanced QoS policies;

[0286] Operational anomalies such as address mapping anomalies and MTT table update conflicts.

[0287] Without a unified dispatching and control center, these dynamic states cannot be perceived and responded to in a timely manner, causing the entire system to fall into a dangerous state of soaring delays or transmission interruptions.

[0288] Therefore, setting up a control unit module to perceive the transmission status in real time, manage key resources, receive feedback signals and automatically adjust system parameters is a necessary means to ensure that the RDMA system has stability, adaptability and intelligent transmission control capabilities.

[0289] In a specific implementation, the control unit module can be disassembled into the following three core submodules, each of which is further divided into functional components:

[0290] The address management unit specifically includes:

[0291] Address registration submodule: used to receive the source / destination VA in the WQE, initiate a table lookup request, or register in case of a miss:

[0292] If VA is not in MTT:

[0293]

[0294] Mapping maintenance submodule: used to periodically update mapping relationships, handle page failures, etc.

[0295] For each PA update, check the mapping consistency:

[0296] Check:Δ(PA old ,PA new )<∈ addr

[0297] Conflict detection submodule: prevents two VAs from being mapped to the same PA at the same time or the same VA from being registered repeatedly.

[0298] QoS policy unit, specifically including:

[0299] Task classification submodule: Identify task types based on fields in WQE:

[0300] Determine the task type:

[0301] Class(WQE)=f(T type ,S size ,P priority )

[0302] Policy configuration submodule: Set the following QoS parameters for different tasks:

[0303] Maximum rate R max

[0304] Maximum delay budget D max

[0305] Priority channel Q class

[0306] Real-time policy adjustment submodule: Dynamically receives status feedback information from the network (such as RTT jitter and number of CNPs) and adjusts parameters:

[0307] If the current delay > D max ,but:

[0308] R new =R old ×γ,0<γ<1

[0309] Congestion control unit, including:

[0310] Buffer monitoring submodule: monitors the queue length Q of the inbound / outbound buffer len , if it exceeds the threshold, it is marked as congested.

[0311] Flow control feedback submodule: If congestion is detected, it sends a CNP (Congestion Notification Packet) or adjusts the local sending rate:

[0312] Congestion Factor C f Defined as:

[0313]

[0314] If C f >θ, trigger rate reduction feedback:

[0315] R adj =R current ·(1-αC f )

[0316] Exception handling submodule: If memory mapping failure, data transmission timeout, data packet retransmission, etc. are found, an alarm will be reported to the upper layer or a soft restart process will be triggered.

[0317] By integrating the control unit module into the DPU, the system has the following advantages:

[0318] Centralized management of address mapping, resource scheduling, QoS policies, and exception responses prevents isolated module operations. Highly adaptable transmission paths: Rates and priorities are adjusted based on contextual signals, enabling flexible adaptation to network environments and service loads. Real-time detection and processing of operational anomalies prevent cascading failures and ensure stable system operation. Scheduling strategies based on priority and queue load optimize the allocation of core resources (such as MTT tables and caches).

[0319] In a specific example:

[0320] Host A continuously sends multiple 64KB structured data packets to host B. The control module operates as follows:

[0321] AMU receives VA = 0x10000000, searches for MTT hit, and continues transmission;

[0322] QPU identifies the task as a high-priority WRITE type and sets R max =10Gbps,D max =5μs;

[0323] When data flows through the pipeline, CCU monitors the output buffer Q len >0.8Q max , calculate the congestion factor C f =0.82, triggering flow control;

[0324] The QPU adjusts the current sending rate based on the feedback:

[0325] R adj =10·(1-0.5·0.82)=5.9Gbps

[0326] If the next batch of data packets is of low priority, the QPU automatically switches to the policy channel;

[0327] The AMU finds that the VA in the new task is not registered, triggers the registration process, and expands the MTT table.

[0328] Through this control unit, the system implements closed-loop control of transmission status, QoS adaptive adjustment, and address security verification, ensuring that RDMA's low latency and high throughput goals can be maintained even in the event of sudden network fluctuations.

[0329] The system interface and software collaboration module is used to provide a standardized software call interface, enabling user applications or virtualization platforms to quickly register memory and initiate RDMA requests through the interface. It is also used to coordinate the operating status and information feedback between the software layer and the memory registration module, RDMA work request processing module, and control unit module, realizing collaborative control between software and hardware.

[0330] Although the core processing logic of the RDMA acceleration system (such as memory registration, address mapping, pipeline transmission, and control scheduling) has been fully embedded in the DPU chip and implemented in hardware, the initiation of RDMA still needs to be driven by the user application or the virtualization platform software stack, including operations such as memory registration requests, WQE creation, connection management, and status query.

[0331] If a unified system interface is not provided, users need to directly operate the underlying hardware registers and complex control logic. Not only will the interface be fragmented and the usage threshold high, but it may also cause problems such as state asynchrony, request confusion, and resource conflicts.

[0332] Therefore, a system interface and software collaboration module are introduced. Through a standardized calling interface, software running status perception, and a status channel linkage mechanism with the DPU, bidirectional collaboration between "software → hardware" and "hardware → software" is achieved, ensuring that the RDMA acceleration system can operate with high performance, be safe, controllable, and integrate at low cost.

[0333] In a specific implementation, the system interface and software collaboration module can be subdivided into the following functional submodules:

[0334] Software interface definition and encapsulation submodule, which is used to define a standardized user-mode programming interface and encapsulate the underlying complex logic.

[0335] Specifically include:

[0336] rdma_register_memory(void*buf,size_t size)

[0337] Function: Register user space memory to the DPU system.

[0338] Internal logic: Call the system call ioctl (RDMA_IOCTL_MEM_REGISTER) → pass in VA → SIU encapsulates the task and sends it to the memory registration module → returns the registration handle.

[0339] rdma_post_send(RdmaDescriptor*desc)

[0340] Function: Initiate RDMA write request.

[0341] Internal logic: Encapsulate WQE → Send to DPU → Wait for receipt from control module.

[0342] rdma_query_status(RdmaStatus*status)

[0343] Function: Query system status.

[0344] Internal logic: Requests the status register in the control unit → returns MTU, latency, WQE queue length, etc.

[0345] The protocol translation and scheduling submodule is deployed in kernel mode or DPU middleware to translate software API calls into control commands and parameter structures that can be understood by the DPU in the form of a unified message structure:

[0346] Request={OpCode,Arg1,Arg2,...,Token}

[0347] in:

[0348] OpCode: Operation code (such as register, send, query)

[0349] Arg_n: parameter field

[0350] Token: unique identifier used to track asynchronous request status

[0351] The scheduler inserts the request into the interface buffer of the control unit or memory registration module according to the priority and task type.

[0352] The state feedback coordination submodule is activated whenever the internal state of the DPU changes (for example:

[0353] MTT registration failed;

[0354] WQE handles exceptions;

[0355] Congestion feedback level increases;

[0356] The control unit packages the status into a feedback event and returns the following status structure:

[0357] Event={Type,Code,ModuleID,Timestamp}

[0358] The software performs polling or asynchronous callback monitoring through the rdma_get_event(Event*ev) interface.

[0359] The virtualization adapter module allocates a virtual RDMA interface (vRDMA) to each guest VM in virtualization environments such as KVM and Xen, and uses a VFIO-like method to map host RDMA resources to VM space.

[0360] The process includes:

[0361] Hypervisor forwards vRDMA API to the host;

[0362] The host directs tasks to the DPU through SR-IOV or API distribution;

[0363] The DPU returns the result and transmits it back to the VM layer.

[0364] This mechanism ensures the compatibility and security of RDMA on the cloud platform.

[0365] Through the design of this module, the system achieves seamless integration and coordinated control from "user state" to "hardware state." Users do not need to understand the complexities of the underlying hardware; they can access it simply through the API. A state synchronization mechanism ensures consistency between software and DPU states, avoiding conflicts. Adapting to modern cloud platforms, it implements vRDMA and zero-copy communication, ensuring elastic scalability. A state feedback mechanism allows the software to quickly identify and respond to hardware anomalies.

[0366] Specific examples:

[0367] The service process of host A initiates an RDMA write request. The operation process is as follows:

[0368] The user calls at the application layer:

[0369] void*buffer=malloc(65536);

[0370] rdma_register_memory(buffer,65536); / /

[0371] The software interface module sends the request to the SIU, encapsulated as:

[0372] {OpCode:REGISTER,Arg1:0x10000000,Arg2:65536,Token:1122}

[0373] SIU dispatches to memory registration module → mapping table generation → control module records status;

[0374] User call:

[0375] RdmaDescriptor desc={WRITE,buffer,remote_addr,65536};

[0376] rdma_post_send(&desc);

[0377] DPU receives request → builds WQE → looks up table → data transfer → controls write-back status;

[0378] If the target host network is detected to be congested, the DPU will respond with the following event:

[0379] {Type:Congestion,Code:3,ModuleID:QPU,Timestamp:T1}

[0380] After receiving feedback, the software prompts the user to delay sending the next request or switch paths.

[0381] Through this mechanism, users only need to focus on business logic, and the system automatically completes memory registration, address mapping, data scheduling and status synchronization, reflecting the high maturity of this invention in engineering implementation and application availability.

[0382] The prior art mentioned in the above background technology section and specific embodiments section of the present invention can be regarded as part of the present invention and used to understand the meaning of some technical features or parameters.

Claims

1. A low-latency RDMA acceleration system based on memory registration, characterized in that: The system includes the following modules: A memory registration module is used to register the memory area requested by the application using the memory pin technology in the kernel, ensuring that the memory area is fixed and cannot be swapped out, and to generate a mapping relationship table between the virtual address and the physical address of the memory area. The mapping relationship table is stored inside the DPU chip; An RDMA work request processing module is configured to receive a remote direct memory access (RDMA) work request initiated by an application, encapsulate the information in the request, including the source virtual address and the target virtual address, into a work queue element, transmit the information to the DPU via the host channel adapter, and convert the virtual address into a physical address based on the mapping relationship table; The data transmission pipeline module includes an inbound pipeline and an outbound pipeline, which are used to process data received from remote systems and sent to local systems, respectively. The pipelines are embedded with hardware logic for table lookup, QoS detection, and message processing to perform data transmission rate control and network congestion management according to preset policies. A control unit module, including an address management unit, a QoS policy unit, and a congestion control unit, is used to uniformly manage the work queue, data transmission status, and exception information processing, and is used to adjust the transmission parameters of the RDMA acceleration system in real time based on the received context signal to ensure low latency and high throughput data transmission performance; The system interface and software collaboration module is used to provide a standardized software call interface, enabling user applications or virtualization platforms to quickly register memory and initiate RDMA requests through the interface. It is also used to coordinate the operating status and information feedback between the software layer and the memory registration module, RDMA work request processing module, and control unit module, realizing collaborative control between software and hardware.

2. The low-latency RDMA acceleration system based on memory registration according to claim 1 is characterized in that: The memory registration module includes: The memory pinning submodule is used to call the operating system kernel interface to pin the memory pages requested by the application in the physical memory through the memorypin technology to prevent them from being swapped out during DMA transmission; An address mapping submodule, configured to call an operating system page table management mechanism to perform a one-to-one mapping between a virtual address and a physical address of the memory page; A mapping upload submodule is used to write the mapping relationship table into a high-speed storage unit inside the DPU chip and use hash indexing or TCAM logic to support high-speed queries; The address verification and release submodule is used to release the mapping table and unlock the corresponding memory page after the memory is no longer used, ensuring timely resource recovery and system security.

3. The low-latency RDMA acceleration system based on memory registration according to claim 1 is characterized in that: The RDMA work request processing module includes: The request receiving submodule is used to receive the RDMA request initiated by the application through the host channel adapter HCA; A WQE construction submodule is used to encapsulate the operation type, source virtual address, target virtual address, data length and connection identifier contained in the request into a work queue element WQE; An address conversion submodule, configured to perform physical address mapping on the source address and the target address in the WQE based on a VA-PA mapping relationship table stored in the DPU; The trigger scheduling submodule is used to pass the WQE that completes address resolution to the data transmission pipeline module, triggering the DMA engine to perform data read and write operations.

4. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The RDMA work request processing module includes: The historical request learning submodule is used to collect and analyze WQE generation data in the past cycle and build access frequency histograms and address heat models; A WQE pre-construction submodule is used to predict possible future request patterns based on the historical request learning submodule and construct a WQE structure in advance; The pre-decoding mapping submodule is used to map the virtual address contained in the pre-built WQE into a physical address in advance and store it in the pre-decoding pool; A matching and correction submodule is used to perform structural matching with the WQE in the pre-decoding pool when the actual request arrives. If the difference is within the tolerance range, some fields are corrected to complete the fast matching; The fast trigger scheduling submodule is used to send the successfully matched WQE directly to the data transmission pipeline, skipping the standard construction and table lookup process to reduce processing latency.

5. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The data transmission pipeline module includes: The inbound protocol parsing submodule is used to perform protocol decoding on received data packets, including UDP / IP layer and RDMA layer field parsing; The address location submodule is used to call the table lookup logic to obtain the physical address corresponding to the target virtual address from the MTT table; QoS feedback control submodule, which monitors the status of the receiving path buffer and sends congestion notifications to the peer end when the load exceeds the threshold; The data delivery submodule is used to write the received data payload into the located target physical address space; WQE decoding submodule, used to extract the operation type, address and length information in WQE; The address retrieval submodule is used to perform address lookup on the source VA and the target VA in the outgoing path; QoS rate shaping submodule, used to reduce the packet sending rate when the network load is too high; The message generation and sending submodule is used to complete the message encapsulation, CRC check and output to the network interface.

6. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The data transmission pipeline module further includes: Heterogeneous processing node pool, including semantic recognition nodes, table lookup nodes, QoS nodes, rate shaping nodes, and lightweight compression nodes, each with independent configuration parameters; The task semantic parsing submodule is used to generate the transmission semantic descriptor TSD according to the fields in the WQE; The structure scheduling graph generation submodule is used to generate the structure scheduling graph SDG based on TSD and the current system status; On-chip switch grid configuration submodule, used to configure the connection paths between nodes according to SDG, realizing the dynamic combination of node-level pipeline order and connection status; The path learning and updating submodule is used to record the path performance indicators after the task is completed and update the scheduling template priority to improve the subsequent scheduling effect.

7. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The control unit module includes: The address registration submodule is used to query or register the newly appeared virtual address mapping in the MTT table; Mapping maintenance submodule, used to regularly refresh mapping entries and verify mapping consistency; Conflict detection submodule, used to identify and prevent multiple VAs from being mapped to the same PA or repeated registration mapping conflicts; The task classification submodule is used to identify the task type based on the fields in the WQE; The policy configuration submodule is used to allocate QoS channels, delay budgets, and rate caps; Real-time policy adjustment submodule, used to modify task scheduling parameters in real time based on network feedback information; Buffer monitoring submodule, used to monitor queue length and traffic burst indicators; Flow control feedback submodule, used to trigger congestion feedback packets; The exception handling submodule is used to handle mapping failure, transmission interruption and retransmission exception events.

8. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The system interface and software collaboration module includes: The software interface encapsulation submodule is used to provide standard calling interfaces, including rdma_register_memory() for memory registration, rdma_post_send() for sending RDMA requests, and rdma_query_status() for querying system status; The protocol translation and scheduling submodule is used to encapsulate the calling interface parameters into a standard message structure, including an operation code, a parameter array and a token identifier, and send it to the target module.

9. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The system interface and software collaboration module further includes: The status feedback coordination submodule is used to monitor the status events generated by the control module and return them to the software interface in the form of an event structure, including MTT registration failure, WQE execution error, and network congestion upgrade information. It also supports two feedback mechanisms: active polling and passive callback.

10. The low-latency RDMA acceleration system based on memory registration according to claim 1, characterized in that: The system interface and software collaboration module further includes: The virtualization adapter module is used to allocate vRDMA interfaces to each virtual machine in a virtualized environment and map host DPU resources to the virtual machine through the SR-IOV or VFIO mechanism to achieve RDMA isolation and access support in a multi-tenant environment.

Images