Rdma read request packet cutting method and system based on window dynamic boundary
Patent Information
- Application Number
- CN202611020814.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-09
- Publication Date
- 2026-10-27
AI Technical Summary
这种等待完全违背了RDMA低延迟、高带宽的设计初衷,造成了:
[0051]在传统模式下,当请求数据量巨大而PSN窗口较小时,整个传输过程会被分割为多个完整的“请求-响应”周期。每个周期结束后,发送方必须等待接收方的ACK确认以滑动窗口,才能发起下一个READ请求。这期间,链路带宽会因等待而闲置。
Smart Images

Figure CN122994243A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network communication technology, and in particular to a method and system for RDMA read request message segmentation based on window dynamic boundaries. Background Technology
[0002] RDMA READ (Remote Direct Memory Access) is a one-sided operation within RDMA (Remote Direct Memory Access) operations. "One-sided" means that the entire operation requires only the active participation of the initiator, while the responder's CPU does not need to intervene in or be aware of this memory access. This is crucial for reducing CPU overhead on remote nodes and improving latency and bandwidth.
[0003] The core function of an RDMA READ request message is that the requesting party directly reads a piece of data from the specified memory address of the responding party and stores it in the specified memory address on the requesting party's local machine.
[0004] The requesting RNIC (Network Interface Card) constructs and sends a READ request message. Upon receiving the message, the responding RNIC, without waking its CPU, directly verifies access permissions based on the Remote Stag (a "key" representing a pre-registered memory region; only those holding this key have permission to access the corresponding remote memory) and the target memory information. If valid, it reads data from the corresponding memory address.
[0005] The responding RNIC encapsulates the read data in one or more RDMA READ response messages and sends them back to the requesting party. The response message also contains a PSN (Packet Sequence Number, a unique sequence number for each message to ensure reliable transmission and message order), which is associated with the PSN of the request message.
[0006] After receiving the READ response message, the requesting RNIC writes the data directly into the specified local memory and notifies the requesting application that the operation is complete.
[0007] The following conditions must be met before a READ request message can be sent:
[0008] 1. The PSN range of the message must correspond to the length of the data it requests to read;
[0009] 2. The PSN of the message must be within the currently allowed PSN window.
[0010] The window size is typically determined by hardware registers and the queue pair context (QP Context), and is dynamically adjusted based on the PSN of the messages processed by the responder.
[0011] The size of the new allowed PSN window is generally determined by register configuration and QP Context. In cases where flow control is required, it can be dynamically adjusted more flexibly using the CC algorithm. Its position is dynamically adjusted based on the PSN value of the message processed by the responder.
[0012] In theory, the RC protocol manages message sending and acknowledgment through a very large PSN space (usually 22 or 24 bits) and a sliding window mechanism. The size of its sending window (Tx Window) is defined by the upper limit of the protocol's PSN bit width. In this mode, unless there are extreme long delays or retransmission scenarios, it is extremely rare for a READ request message to be blocked because its PSN range exceeds this huge static window.
[0013] However, in modern data center networks, to cope with network congestion, avoid packet loss, and ensure fairness, RDMA protocols (such as RoCEv2) typically need to work in conjunction with window-based congestion control algorithms (such as DCQCN, HPCC, etc.). These CC algorithms respond to network conditions by dynamically adjusting the transmission rate.
[0014] One of its core mechanisms is the dynamic adjustment of the new allowed PSN window size for each queue pair (QP). This window is no longer a fixed, huge theoretical value, but a much smaller value dynamically calculated by the CC algorithm based on real-time network congestion feedback (such as ECN, CNP). Specifically:
[0015] Shrink: When network congestion occurs, the CC algorithm quickly reduces the New allowed PSN window to lower the transmission rate and alleviate network pressure.
[0016] Window growth: When the network is smooth, the CC algorithm will gradually increase the window size to improve throughput.
[0017] In this context, existing congestion control methods primarily focus on dynamically adjusting the sending window or sending rate to adapt to network conditions. For example, CN115665046A discloses a data flow control method, which includes: obtaining a first quantity, which is the number of data packets that can be sent at present; determining whether the first quantity is greater than a first preset threshold; if so, sending data packets to the receiving end and updating the first quantity in real time when the data packets are successfully sent; and pausing the sending of data packets to the receiving end when the updated first quantity is detected to be less than or equal to the first preset threshold. Compared to existing technologies that use complex mechanisms with high communication latency, such as sliding windows and congestion queues, this patent, while potentially solving the problem of increased communication latency caused by network congestion during network communication in existing technologies, focuses on controlling the sending rate rather than solving the problem of sending large-capacity request packets under a limited window.
[0018] The length of data (DMA_LEN) requested by an RDMA READ request message determines the range of PSNs it needs to use. When an application initiates a large data read request, the required PSN range can be very large.
[0019] In standard RC protocols, this is usually not a problem. However, in scenarios where dynamic congestion control is enabled, the CC algorithm immediately shrinks the sending window once the network experiences even slight congestion. At this time, a large READ request message waiting to be sent may require a PSN range ([PSN_NXT, READ_REQ_EOP_PSN]) that is much larger than the currently shrunken, smaller PSN_ALLOWED_MAX.
[0020] According to the protocol rules, the entire READ request message can only be sent when its PSN is completely within the currently allowed window. Therefore, the requesting RNIC can only pause sending, waiting for the responding party to process the old messages within the window and return an ACK, allowing the window to slide and PSN_UNACK to be updated before it can obtain sufficient window space. This waiting completely violates the design intent of RDMA—low latency and high bandwidth—leading to:
[0021] Insufficient link bandwidth utilization: Physical link bandwidth is wasted during idle periods while waiting for window updates.
[0022] Decreased transmission efficiency: The overall transmission time is lengthened, especially in large-scale data read / write or high-concurrency scenarios, where the performance degradation is particularly noticeable.
[0023] Stiff Congestion Response: Stagnation at the sending end prevents the CC algorithm from providing effective traffic load feedback, which may affect the accuracy and agility of congestion control.
[0024] Therefore, there is an urgent need for an intelligent method that can ensure the continuous and efficient sending of large READ requests under the constraints of dynamic small windows, thereby compensating for this side effect of dynamic congestion control mechanisms. Summary of the Invention
[0025] The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for RDMA read request message segmentation based on dynamic window boundaries. This method can segment large-capacity READ request messages into multiple sub-messages that conform to window constraints when the PSN window is limited, thereby enabling continuous transmission, improving bandwidth utilization and overall transmission performance.
[0026] To achieve the above objectives, the present invention adopts the following technical solution:
[0027] A window-based dynamic boundary-based RDMA read request message segmentation method, applied to the requesting device, includes:
[0028] S1. Obtain the read request message to be sent, wherein the read request message has a start message sequence number and an end message sequence number; S2. Obtain the maximum message sequence number value currently allowed to be sent;
[0029] S3. Get the current sending offset;
[0030] S4. Determine whether the end sequence number of the read request message is greater than the maximum allowed sequence number value. If so, divide the read request message into the first sub-message and the second sub-message using the maximum allowed sequence number value as the dividing boundary. If not, send the complete read request message directly.
[0031] S5. Send the first sub-message and update the sending offset according to the number of message sequence numbers occupied by the first sub-message;
[0032] S6. Take the second sub-message as the read request message to be sent, obtain the updated maximum allowed message sequence number value, and repeat steps S3-S6 until the sending offset is equal to the total number of message sequence numbers of the read request message.
[0033] Furthermore, the maximum allowed message sequence number value in step S2 includes the next pending message sequence number at the receiving end, and the number of currently allowed incomplete message sequence numbers.
[0034] Furthermore, in step S3, the initial value of the transmitted offset is zero.
[0035] Furthermore, in step S4, the sequence number range of the first sub-message is from the starting sequence number of the read request message to the maximum sequence number value currently allowed to be sent.
[0036] Furthermore, in step S4, the sequence number range of the second sub-message is from the maximum allowed sequence number value plus 1 to the end sequence number of the read request message.
[0037] Furthermore, the segmentation method is executed in the network card hardware firmware or host driver software on the RDMA requesting end.
[0038] Correspondingly, a window-based dynamic boundary RDMA read request message segmentation system is also provided for executing the window-based dynamic boundary RDMA read request message segmentation method. The segmentation system includes a processor, which is equipped with:
[0039] The first acquisition module is used to acquire the read request message to be sent, wherein the read request message has a start message sequence number and an end message sequence number;
[0040] The second acquisition module is used to acquire the maximum allowed message sequence number value currently being sent.
[0041] The third acquisition module is used to acquire the current sending offset;
[0042] The judgment module is used to determine whether the end sequence number of the read request message is greater than the maximum allowed sequence number value.
[0043] The segmentation module is used to segment the read request message into a first sub-message and a second sub-message, based on the current maximum allowed message sequence number as the segmentation boundary, when the output of the module is yes.
[0044] The sending module is used to send the first sub-message;
[0045] The offset management module is used to update the sending offset based on the number of message sequence numbers occupied by the first sub-message;
[0046] The loop module is used to treat the second sub-message as a new read request message to be sent, triggering the second acquisition module, judgment module, segmentation module, sending module, and offset management module to be executed repeatedly until the sending offset is equal to the total number of message sequence numbers of the read request messages.
[0047] Furthermore, the processor is connected to a memory for storing data or instructions.
[0048] Furthermore, the processor is connected to a transmission device for data transmission with external devices.
[0049] Furthermore, the processor is connected to an input / output device for inputting or outputting information.
[0050] Compared with the prior art, the present invention has the following beneficial effects:
[0051] In the traditional model, when the requested data volume is large and the PSN window is small, the entire transmission process is divided into multiple complete "request-response" cycles. After each cycle, the sender must wait for the receiver's ACK confirmation to slide the window before initiating the next READ request. During this period, the link bandwidth will be idle due to waiting.
[0052] This invention uses dynamic segmentation to break down a large READ request into smaller parts at the window boundary, allowing the sender to continuously send request segments using every currently allowed PSN without waiting for the entire request response to complete. It reduces the waiting time from "a full RTT (Round Trip Delay)" to "the time to process a window segment," significantly reducing link idle time. Attached Figure Description
[0053] Figure 1 This is a flowchart of the RDMA read request message segmentation method based on window dynamic boundaries provided in Embodiment 1;
[0054] Figure 2 This is a schematic diagram of message segmentation provided in Embodiment 1. Detailed Implementation
[0055] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.
[0056] The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for RDMA read request message segmentation based on window dynamic boundaries.
[0057] Example 1
[0058] This embodiment provides a method for RDMA read request packet segmentation based on dynamic window boundaries, such as... Figure 1 As shown, it includes:
[0059] S1. Obtain the read request message to be sent, wherein the read request message has a start message sequence number and an end message sequence number; S2. Obtain the maximum message sequence number value currently allowed to be sent;
[0060] S3. Get the current sending offset;
[0061] S4. Determine whether the end sequence number of the read request message is greater than the maximum allowed sequence number value. If so, divide the read request message into the first sub-message and the second sub-message using the maximum allowed sequence number value as the dividing boundary. If not, send the complete read request message directly.
[0062] S5. Send the first sub-message and update the sending offset according to the number of message sequence numbers occupied by the first sub-message;
[0063] S6. Take the second sub-message as the read request message to be sent, obtain the updated maximum allowed message sequence number value, and repeat steps S3-S6 until the sending offset is equal to the total number of message sequence numbers of the read request message.
[0064] This embodiment uses an RDMA reliable connection read operation between a requesting server and a responding server as an example. The requesting server is configured with a network interface card (NIC) that supports RDMA, hereinafter referred to as the requesting NIC. The responding server is configured with a NIC that supports RDMA, hereinafter referred to as the responding NIC. The two are connected via an Ethernet network that supports the RoCEv2 protocol.
[0065] The upper-layer application running on the requesting server needs to read data from a specified memory address on the responding server. The length of this read request is denoted as n. In this embodiment, n is greater than the maximum data transmission unit corresponding to a single message sequence number.
[0066] The requesting network card's driver layer pre-configures the maximum data transfer unit value for the queue pair and the initial window parameters required by the congestion control algorithm, which uses the DCQCN algorithm.
[0067] When the application at the requesting end initiates an RDMA read request, the request is added to the send queue. The network interface card (NIC) at the requesting end retrieves the request from the send queue, and the packet processing module in the NIC driver layer executes the dynamic segmentation method of this invention.
[0068] The upper-layer application is completely unaware of the packet segmentation process. After the application submits a complete read request, the network card driver layer automatically completes the segmentation, transmission, and iteration control. The application only needs to wait for the completion notification after the final data is written to local memory.
[0069] Each sub-packet received by the responding network card is an independent read request packet conforming to the reliable connection protocol. The responding CPU does not need to participate in the processing, thus maintaining the standard semantics of RDMA one-sided operation.
[0070] In step S1, a read request message to be sent is obtained, which has a start message sequence number and an end message sequence number.
[0071] The requesting network card receives the READ work request from the sending queue and obtains the read request message to be sent. The work request includes: the local memory buffer address, used to store the data read from the responding end; the responding end memory address, indicating the position on the responding end from which to start reading data; the length of the data to be read, denoted as n; and the remote memory key, used to verify access permissions.
[0072] The requesting network interface card resolves the queue context (QPC) to obtain the currently unacknowledged PSN (denoted as PSN_UNACK) and the next PSN to be sent (denoted as PSN_NXT). At this time, the start sequence number of the read request packet READ_REQ_SOP_PSN = PSN_NXT.
[0073] Based on the Maximum Data Transmission Unit (PMTU), the end sequence number of the read request message is READ_REQ_EOP_PSN = PSN_NXT + (n - 1) / PMTU
[0074] In this embodiment, assuming PSN_NXT is 100, the number of message sequence numbers corresponding to n is 100, and PMTU is 4096 bytes, then the starting message sequence number READ_REQ_SOP_PSN is 100, and the ending message sequence number READ_REQ_EOP_PSN is 199.
[0075] In step S2, the maximum allowed message sequence number value is obtained.
[0076] The requesting network card obtains the number of currently allowed incomplete packet sequence numbers from the congestion control module, denoted as the NewAllowed PSN window. This value is dynamically adjusted by the congestion control algorithm based on real-time network congestion feedback. When network congestion occurs, the window shrinks, and when the network is unobstructed, the window grows.
[0077] The requesting network card calculates the maximum allowed packet sequence number value PSN_ALLOWED_MAX = PSN_UNACK + New Allowed PSN window.
[0078] In this embodiment, assuming PSN_UNACK is 100 and New Allowed PSN window is 50, then PSN_ALLOWED_MAX is 150.
[0079] In step S3, the current transmission offset is obtained;
[0080] The send offset PSN_OFST is the number of packets that have been sent in the original request message. PSN_OFST = PSN_NXT - READ_REQ_SOP_PSN. It is initialized to 0.
[0081] In this embodiment, the initial value of PSN_OFST is 0.
[0082] In step S4, it is determined whether the end sequence number of the read request message is greater than the maximum allowed sequence number value. If so, the read request message is divided into a first sub-message and a second sub-message, using the maximum allowed sequence number value as the cutting boundary. If not, the complete read request message is sent directly. Figure 2 As shown.
[0083] The requesting network card determines whether the end sequence number of the read request packet, READ_REQ_EOP_PSN, is greater than the maximum allowed packet sequence number value, PSN_ALLOWED_MAX.
[0084] If READ_REQ_EOP_PSN is less than or equal to PSN_ALLOWED_MAX, it means that the PSN range of the entire read request packet falls completely within the currently allowed sending window. The requesting network card directly sends the complete read request packet without performing a segmentation operation.
[0085] If READ_REQ_EOP_PSN is greater than PSN_ALLOWED_MAX, it means that the end PSN of the read request packet exceeds the current allowed transmission window range, and the entire packet cannot be sent directly and needs to be segmented. If READ_REQ_EOP_PSN is 199 and PSN_ALLOWED_MAX is 150, since 199 is greater than 150, it means that READ_REQ_EOP_PSN is greater than PSN_ALLOWED_MAX. Then, the requesting network card uses the current maximum allowed transmission packet sequence number value of 150 as the segmentation boundary to segment the read request packet into the first sub-packet and the second sub-packet.
[0086] The PSN information for the message sequence number READ_REQ_1 of the first sub-message is:
[0087] a) The start sequence number of the first sub-message is READ_REQ_1_SOP_PSN = READ_REQ_SOP_PSN = PSN_NXT = 100;
[0088] b) The end message sequence number of the first sub-message: READ_REQ_1_EOP_PSN = PSN_ALLOWED_MAX = 150;
[0089] c) The length of data to be read from the first sub-message is DMA_LEN_1 = (PSN_ALLOWED_MAX - PSN_NXT) * PMTU = (150-100) * 4096 = 204800 bytes.
[0090] The PSN information for the second sub-message's sequence number READ_REQ_2 is:
[0091] a) The start sequence number of the second sub-message, READ_REQ_2_SOP_PSN, = PSN_ALLOWED_MAX + 1 = 150 + 1 = 151;
[0092] b) The end message sequence of the second sub-message: READ_REQ_2_EOP_PSN = READ_REQ_EOP_PSN = 199;
[0093] c) The length of data to be read in the second sub-message is DMA_LEN_2 = n - (PSN_ALLOWED_MAX -PSN_NXT) * PMTU = 100 × 4096 - (150-100) * 4096 = 204800 bytes.
[0094] In step S5, the first sub-message is sent, and the sending offset is updated according to the number of message sequence numbers occupied by the first sub-message.
[0095] The requesting network card sends the first sub-message. The PSN of the first sub-message is in the range of READ_REQ_SOP_PSN (e.g., 100) to PSN_ALLOWED_MAX (e.g., 150). This range is completely within the current allowed transmission window and can be sent immediately.
[0096] The transmission offset, denoted as OFST, is initially set to zero and is used to record the progress of the transmitted data within the original read request message. After transmission is complete, the requesting network interface card updates the queue in the context with the following content:
[0097] Set the transmit offset PSN_OFST = PSN_ALLOWED_MAX - READ_REQ_SOP_PSN = 150 - 100 = 50;
[0098] Update the sequence number of the next message to be sent: PSN_NXT = PSN_ALLOWED_MAX + 1 = 150 + 1 = 151;
[0099] The updated send offset PSN_NXT = PSN_OFST + 1 = 50 + 1 = 51.
[0100] In step S6, the second sub-message is used as the read request message to be sent. The updated maximum allowed message sequence number value is obtained. Steps S3 to S6 are repeated until the sending offset is equal to the total number of message sequence numbers of the read request messages.
[0101] The requesting network card will use the second sub-message as the read request message to be sent. The start sequence number of the second sub-message is 151 and the end sequence number is 199.
[0102] The requesting network card obtains the updated maximum allowed packet sequence number value. Specifically, the requesting network card rereads the updated PSN_UNACK from the queue pair context, obtains the updated NewAllowed PSN window from the congestion control module, and recalculates the maximum packet sequence number PSN_ALLOWED_MAX.
[0103] In this embodiment, it is assumed that during the transmission of the first sub-message, the receiving end processes part of the message and returns an acknowledgment, updating PSN_UNACK to 120. Simultaneously, the congestion control module adjusts the New Allowed PSN window to 40 based on the network status; therefore, the updated PSN_ALLOWED_MAX = 120 + 40 = 160.
[0104] The requesting network card repeats steps S3 to S6 for the second sub-message.
[0105] In the first iteration, step S4 is executed. At this time, it is determined whether the end message sequence number 199 of the second sub-message is greater than the maximum allowed message sequence number value 160. Since 199 is greater than 160, the result is yes. Then, the second sub-message is divided into a new first sub-message and a new second sub-message with 160 as the cutting boundary. The message sequence number range of the new first sub-message is from 151 to 160, and the message sequence number range of the new second sub-message is from 161 to 199.
[0106] In the first iteration, step S5 is executed, at which point a new first sub-message (message sequence number range 151 to 160) is sent. After sending, the queue context is updated: PSN_OFST and PSN_NXT are updated.
[0107] In the first iteration, step 6 is executed, and the new second sub-message is used as the read request message to be sent. The updated maximum message sequence number value that is currently allowed to be sent is obtained again.
[0108] Assuming that PSN_UNACK is updated to 130 and the New Allowed PSN window is adjusted to 70, then the updated PSN_ALLOWED_MAX = 1306 + 70 = 200.
[0109] In the second iteration, step S4 is executed. At this time, it is determined whether the end message sequence number 199 of the remaining sub-message is greater than the maximum allowed message sequence number value 200. Since 199 is less than or equal to 200, the result is no, no splitting is required, and the complete remaining sub-message (message sequence number range 161 to 199) is sent directly.
[0110] In the second iteration, step S5 is executed. At this point, the remaining sub-messages are sent. After the sending is completed, since PSN_ALLOWED_MAX (200) is greater than or equal to the end sequence number (199) of the second sub-message, the condition for complete sending is met, and the queue is updated to the context content as follows:
[0111] a) PSN_OFST = 0 indicates that all original read request messages have been sent;
[0112] b) PSNPSN_NXT = READ_REQ_2_EOP_PSN+1 = 199+1=200, which means that the sequence number PSN_NXT of the next message to be sent is set to the sequence number of the end message of the second sub-message plus 1;
[0113] c) HW_SQ_RPTR = HW_SQ_RPTR + the size of this request message, which means that the hardware send queue pointer HW_SQ_RPTR is incremented by the size of the current request message, at which point the current request message has been processed.
[0114] Compared with the prior art, this embodiment has the following beneficial effects:
[0115] 1. Dynamic decision-making mechanism based on real-time PSN window state: This embodiment does not pre-cut or statically cut the packet, but checks the current PSN_UNACK and PSN_ALLOWED_MAX in real time before each transmission, and dynamically decides whether the entire packet can be sent, or whether it needs to be cut, and how to cut it.
[0116] 2. Precise segmentation algorithm with PSN_ALLOWED_MAX as the boundary: The segmentation does not simply divide the data length equally, but strictly uses the maximum allowed PSN (PSN_ALLOWED_MAX) as the unique boundary. This ensures that the PSN range [SOP, PSN_ALLOWED_MAX] of the first sub-message (READ_REQ_1) generated after segmentation will definitely fall entirely within the allowed window and can be sent immediately.
[0117] 3. Introduction and Dynamic Management of Offset (OFST): The concept of "Offset (OFST)" is introduced and maintained and updated in QPC (Queue Pair Context). OFST accurately records the progress of the currently sent data in the original entire READ request (in units of PSN difference).
[0118] 4. Iterative Segmentation and Transmission Control Flow: This embodiment transforms the single large message transmission process into an iterative control loop of "send - wait for window update - make another decision (send or continue segmentation) - send". This process will automatically repeat until all parts of the original message have been sent (OFST returns to 0).
[0119] 5. Complete preservation of RDMA one-sided operational semantics: Although message segmentation and multiple transmissions occur on the requesting end, the responding end receives and processes multiple valid, independent READ request messages. The responding end is completely unaware of and does not need to adapt to this segmentation optimization on the requesting end; its behavior fully complies with the RDMA standard protocol.
[0120] Example 3
[0121] This embodiment provides an RDMA read request packet segmentation system based on window dynamic boundaries, used to execute the RDMA read request packet segmentation method based on window dynamic boundaries in Embodiment 1. The segmentation system includes a processor, which is configured with:
[0122] The first acquisition module is used to acquire the read request message to be sent, wherein the read request message has a start message sequence number and an end message sequence number;
[0123] The second acquisition module is used to acquire the maximum allowed message sequence number value currently being sent.
[0124] The third acquisition module is used to acquire the current sending offset;
[0125] The judgment module is used to determine whether the end sequence number of the read request message is greater than the maximum allowed sequence number value.
[0126] The segmentation module is used to segment the read request message into a first sub-message and a second sub-message, based on the current maximum allowed message sequence number as the segmentation boundary, when the output of the module is yes.
[0127] The sending module is used to send the first sub-message;
[0128] The offset management module is used to update the sending offset based on the number of message sequence numbers occupied by the first sub-message;
[0129] The loop module is used to treat the second sub-message as a new read request message to be sent, triggering the second acquisition module, judgment module, segmentation module, sending module, and offset management module to be executed repeatedly until the sending offset is equal to the total number of message sequence numbers of the read request messages.
[0130] The processor described in this embodiment may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.
[0131] The processor described in this embodiment has a memory connected to it for storing data or instructions. The memory may include a mass storage device for data or instructions. For example, and not limitingly, the memory may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include removable or non-removable (or fixed) media. Where appropriate, the memory may be internal or external to the data processing device. In a particular embodiment, the memory is non-volatile memory. In a particular embodiment, the memory includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random Access Memory (FPMDRAM), Extended Data Out Dynamic Random Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.
[0132] Memory can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions that the processor may execute. The processor reads and executes the computer program instructions stored in memory.
[0133] The processor described in this embodiment is connected to a transmission device for data transmission with external devices. The transmission device can be used to receive or send data via a network. Specific examples of the network described above may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0134] The processor described in this embodiment is connected to an input / output device for inputting or outputting information. The input / output device is used to input or output information, wherein the input can be a read request message, and the output can be a first sub-message, a second sub-message, or a complete read request message that has been segmented and sent according to the method of the present invention.
[0135] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.
Claims
1. A method for RDMA read request message segmentation based on dynamic window boundaries, applied to the requesting end device, characterized in that, include: S1. Obtain the read request message to be sent, wherein the read request message has a start message sequence number and an end message sequence number; S2. Obtain the maximum allowed message sequence number value currently; S3. Get the current sending offset; S4. Determine whether the end sequence number of the read request message is greater than the maximum allowed sequence number value. If so, divide the read request message into the first sub-message and the second sub-message using the maximum allowed sequence number value as the dividing boundary. If not, send the complete read request message directly. S5. Send the first sub-message and update the sending offset according to the number of message sequence numbers occupied by the first sub-message; S6. Take the second sub-message as the read request message to be sent, obtain the updated maximum allowed message sequence number value, and repeat steps S3-S6 until the sending offset is equal to the total number of message sequence numbers of the read request message.
2. The RDMA read request packet segmentation method based on window dynamic boundaries according to claim 1, characterized in that, The maximum allowed message sequence number value in step S2 includes the next pending message sequence number at the receiving end, and the number of currently allowed incomplete message sequence numbers.
3. The RDMA read request packet segmentation method based on window dynamic boundaries according to claim 1, characterized in that, In step S3, the initial value of the transmitted offset is zero.
4. The RDMA read request packet segmentation method based on window dynamic boundaries according to claim 1, characterized in that, In step S4, the sequence number range of the first sub-message is from the starting sequence number of the read request message to the maximum sequence number value currently allowed to be sent.
5. The RDMA read request packet segmentation method based on window dynamic boundaries according to claim 4, characterized in that, In step S4, the message sequence number range of the second sub-message is from the maximum allowed message sequence number value plus 1 to the end message sequence number of the read request message.
6. The RDMA read request packet segmentation method based on window dynamic boundaries according to claim 1, characterized in that, The segmentation method is executed in the network card hardware firmware or host driver software on the RDMA requesting end.
7. A window-based dynamic boundary RDMA read request message segmentation system, used to execute the window-based dynamic boundary RDMA read request message segmentation method according to any one of claims 1-6, the segmentation system comprising a processor, characterized in that, The processor is equipped with: The first acquisition module is used to acquire the read request message to be sent, wherein the read request message has a start message sequence number and an end message sequence number; The second acquisition module is used to acquire the maximum allowed message sequence number value currently being sent. The third acquisition module is used to acquire the current sending offset; The judgment module is used to determine whether the end sequence number of the read request message is greater than the maximum allowed sequence number value. The segmentation module is used to segment the read request message into a first sub-message and a second sub-message, based on the current maximum allowed message sequence number as the segmentation boundary, when the output of the module is yes. The sending module is used to send the first sub-message; The offset management module is used to update the sending offset based on the number of message sequence numbers occupied by the first sub-message; The loop module is used to treat the second sub-message as a new read request message to be sent, triggering the second acquisition module, judgment module, segmentation module, sending module, and offset management module to be executed repeatedly until the sending offset is equal to the total number of message sequence numbers of the read request messages.
8. The RDMA read request message segmentation system based on window dynamic boundaries according to claim 7, characterized in that, The processor is connected to a memory for storing data or instructions.
9. The RDMA read request message segmentation system based on window dynamic boundaries according to claim 7, characterized in that, The processor is connected to a transmission device for data transmission with external devices.
10. The RDMA read request message segmentation system based on window dynamic boundaries according to claim 7, characterized in that, The processor is connected to an input / output device for inputting or outputting information.
Citation Information
Patent Citations
Data flow control method and device, equipment and storage medium
CN115665046A