Bitmap-free head-of-line blocking RDMA out-of-order packet reordering management method and system

Abstract

The application discloses a bitmap-free RDMA out-of-order packet reordering management method and system, and relates to the technical field of computer network systems. In view of the problems of traditional fixed bitmap HoL blocking, large hardware expansion overhead, and sharp decline in throughput in the out-of-order packet loss scene, the FastSlide architecture is proposed. A triple-constraint adaptive bitmap recycling mechanism is designed. When the bitmap is highly occupied, overflow is out of limit, and the SLT still has capacity, the blocked head missing packet is migrated to the SLT storing the compressed PSN, and the blocking is eliminated by circularly sliding the bitmap. In combination with the 2RTT bitmap timer, the bottom retransmission is realized. The SLT adopts a single RTT level timer to realize asynchronous packet loss recovery. When overflow cannot be cached, the NACK back pressure with congestion notification is issued. NS3 simulation shows that the application is suitable for RPS multi-path and lossy RDMA network, and the single connection hardware overhead is only 178 bits. Compared with the ECMP and RACK selective retransmission scheme, the application greatly shortens the task completion time, reduces redundant retransmission, and balances low hardware cost and high transmission throughput.

Description

Technical Field

[0001] This invention relates to the field of computer network system technology, specifically to a method and system for managing out-of-order RDMA data packets without Bitmap head-of-line blocking. Background Technology

[0002] Remote Direct Memory Access (RDMA) is a data transfer mechanism that bypasses the operating system kernel, directly reading and writing host memory using the RNIC (Remote Network Interface Card). With its advantages of zero-copy, kernel bypass, and hardware offloading, it has become a core communication solution for high-performance computing, distributed storage, and large-scale machine learning in data centers. Its reliable connection (RC) semantics enforces in-order packet delivery, but real-world data center networks rarely guarantee ordered transmission naturally, resulting in widespread out-of-order packets. On one hand, congestion and link failures cause packet loss and retransmission, and inconsistent forwarding delays between different batches of packets cause out-of-order delivery. On the other hand, multi-path forwarding causes packets in the same flow to travel on different links, further amplifying out-of-order delivery due to path delay differences. With the widespread adoption of lossy RDMA and Packet Spraying multi-path technologies, the frequency and impact of out-of-order packets continue to increase. To meet the in-order delivery requirements of RDMA, the receiving RNIC needs to reorder out-of-order packets using a bitmap structure. How to handle large-scale out-of-order packets cost-effectively and efficiently has become a key challenge in RDMA optimization.

[0003] Currently, commercial RDMA network cards generally use a single, static, fixed-size blocking bitmap for out-of-order management, relying on a sliding window mechanism. The bitmap can only record the packet reception status within its window range; the window can only slide forward after the missing head-of-line packet from the far left of the bitmap arrives. If the head-of-line packet is missing for an extended period, subsequent out-of-order packets will exceed the bitmap's traceable range and be discarded by the network card. Packet loss triggers numerous redundant retransmissions, severely impacting network throughput. Even slight expansion of the bitmap cannot fundamentally solve the bandwidth waste caused by head-of-line congestion.

[0004] Two optimization approaches have emerged in the industry to address the shortcomings of fixed bitmaps, but both have significant limitations. The first approach is a hardware-dynamically shared bitmap solution, represented by LEFT, MELO, and Eunomia. This solution organizes shared bitmap resources through linked lists, reusing idle bitmaps to dynamically expand the range when the out-of-order tracing range expands. However, this approach significantly increases hardware design complexity and cannot reduce the overall bitmap hardware resource consumption. The second approach is a hardware / software combined / fully software bitmap solution, such as OmiDMA and SRNIC. This solution offloads some or all of the out-of-order tracing logic to software, relying on the CPU to expand the bitmap tracing range. However, this introduces additional CPU overhead, violating the core design goal of RDMA: low overhead and low latency.

[0005] In summary, existing technologies all alleviate out-of-order congestion by increasing bitmap capacity, but they cannot balance hardware resource costs and network transmission performance. Therefore, a method and system for RDMA out-of-order data packet reordering management without bitmap head-of-line congestion is proposed to solve the above problems. Summary of the Invention

[0006] 1. The technical problem to be solved by the present invention

[0007] The purpose of this invention is to propose a method and system for managing out-of-order RDMA packets without Bitmap head-of-line blocking, in order to solve the following problems existing in the prior art: (1) Design of non-blocking bitmap algorithm: The existing Bitmap works in the form of a sliding window. The Bitmap window advances only after the data packet at the left boundary of the Bitmap is confirmed. A simple idea is to remove the head data packet blocking the Bitmap advance from the Bitmap and record it with a sparse data structure. However, the memory overhead introduced by sparse records is many times greater than the overhead of the bitmap. Therefore, it is necessary to determine the removal of the head blocking data packet in real time according to the actual Bitmap blocking situation.

[0008] (2) Hardware resource utilization optimization: In order to achieve a non-blocking bitmap, a small number of head-of-line blocking packets are recorded by a sparse data structure. However, without proper design, sparse tracking of a single packet requires tens of bits of on-chip resource overhead, which is impractical. Therefore, it is necessary to compress the packet information recorded in the sparse data structure to minimize hardware overhead as much as possible.

[0009] 2. Technical Solution To achieve the above objectives, the present invention provides the following technical solution: a method and system for managing out-of-order RDMA data packets without Bitmap head-of-line blocking, comprising: S1, Initialize and maintain metadata: The receiving end maintains bitmap metadata, which includes the left boundary sequence number L, bitmap occupancy count ρ, packet overflow count σ, and current load Ω of the sparse loss table; set the bitmap window length W, occupancy high watermark threshold θ (occ), overflow count threshold θ (ovf), and SLT hardware capacity limit. S2, Packet Classification and Flow Processing: Based on the distance d between the packet sequence number and the left boundary of the bitmap, distinguish three types of packets: historical retransmission, in-order arrival, and out-of-order arrival within the window, and perform SLT cleanup, direct upload, and bitmap marking operations respectively; S3, Adaptive Bitmap Recycling to De-HoL Blocking: When a message exceeds the window range, the overflow count is accumulated. If the three conditions of occupancy rate, overflow count, and SLT capacity are met, the missing packet at the head of the queue is moved to the SLT, the bitmap is slid and the message window ownership is re-determined. The cycle continues until the message can be stored in the bitmap. S4, fallback retransmission and congestion control: If a packet cannot be stored after multiple swipes, a negative response with congestion notification is sent; configure a 2RTT bitmap timer, and request batch retransmission of missing bitmap packets after timeout. S5, SLT asynchronous packet loss recovery: Missing packets stored in SLT immediately trigger the first retransmission. Combined with a single RTT-level entry timer, the packet will automatically retransmit repeatedly after the timeout. The SLT entry will be cleared after the corresponding retransmission message is received.

[0010] Applied to RDMA receiver network interface card (RNIC), it includes two core components, a fixed-size bitmap and a lightweight sparse loss table (SLT), which work together to include an adaptive bitmap recycling step and an asynchronous packet loss recovery step. The fixed-size bitmap is used to record out-of-order data packets within a continuous window range. The sparse loss table (SLT) is maintained independently for each queue pair (QP) and is used to record missing data packets that cause the head of the bitmap to block the HoL. Preferably, the distinction between historical retransmissions, in-order arrivals, and out-of-order arrivals within the window in step S2 includes: S2.1 Historical retransmission data packet d < 0: Match the compressed PSN record in the SLT. If a match is found, the corresponding SLT entry is cleared and the table entry resources are released. The PSN in the SLT is stored using fixed bit compression. A single SLT entry contains only the valid bits and the compressed PSN, reducing on-chip hardware storage overhead. S2.2 In-order arrival of data packets d=0: Directly deliver to the upper layer, the bitmap continues to slide to the right, update L and ρ and reset σ; S2.3 Out-of-order data packets within the window 0 < d < W: Set the corresponding index position of the bitmap to 1, and increment ρ.

[0011] The number of compressed bits is configurable, with a default of 9 bits used to store compressed PSN, which can uniquely cover a sliding window of 512 packets; Preferably, the conditions of occupancy rate, overflow count, and SLT capacity in S3 specifically include: S3.1: When three conditions are met simultaneously, such as bitmap occupancy rate ρ>θ(occ), overflow count σ>θ(ovf), and SLT load Ω not reaching the hardware limit, the missing HoL data packet at the head of the bitmap queue is evicted, and the compressed PSN is stored in the SLT. S3.2: The bitmap skips the current blocked header and subsequent continuously received data packets to complete the sliding, and synchronously updates the left boundary sequence number L, the number of bitmap occupied ρ, the data packet overflow count σ, and recalculates the relative distance d of the current data packet; S3.3: If the relative distance d of the current data packet falls within the bitmap window W after the update, mark the data packet in the bitmap; if it still exceeds the window, repeat the cyclic sliding of S3.1-S3.2.

[0012] Preferably, the adaptive bitmap recycling in S3 includes triple constraint judgment logic: (1) Occupancy constraint: If the proportion of bitmap data packets exceeds θ(occ), the bitmap is determined to be dense, and the data packet at the head of the queue is expelled to reclaim bitmap resources; (2) Overflow count constraint: If the number of data packets exceeding the bitmap window exceeds θ(ovf), the network is judged to be seriously out of order, and the head-of-line blocking is actively broken. (3) SLT resource constraints: When the current load Ω of SLT approaches the hardware capacity limit, the bitmap sliding is paused to form back pressure at the receiver and avoid exhaustion of hardware memory.

[0013] Preferably, the bitmap window length W is fixed at 128 slots, the high occupancy threshold θ (occ) is set to 80%, the overflow count threshold θ (ovf) is set to 5 data packets, a single QP is equipped with a 128-bit bitmap and a 50-bit SLT, and the total hardware state of a single connection occupies 178 bits.

[0014] Preferably, the out-of-order data path of the window adopts a packet-by-packet direct placement mechanism. After the out-of-order data packet arrives, the data load is directly written into the host user space memory without waiting for the bitmap window to advance and complete the data delivery.

[0015] As a preferred option, it is adapted to the leaf-spine data center network topology, supports random packet spraying RPS multipath forwarding scenarios, and is also compatible with lossy RDMA network environments with random packet loss on links.

[0016] An RDMA network interface card (RNIC) out-of-order reordering management system, which executes any of the described RDMA out-of-order packet reordering management methods and systems without Bitmap head-of-line blocking, includes a fixed-size bitmap storage module, a multi-QP independent sparse loss table (SLT) storage module, an adaptive bitmap recycling control unit, an asynchronous packet loss recovery scheduling unit, a packet sequence number parsing unit, a NACK message generation unit, and a bitmap timeout timer unit. The adaptive bitmap reclamation control unit is used to read bitmap metadata such as bitmap occupancy count ρ, data packet overflow count σ, and current load Ω of the sparse loss table, and to execute bitmap sliding and HoL data packet eviction logic. The asynchronous packet loss recovery scheduling unit is used to manage SLT entry compression PSN storage, matching, timed retransmission and entry release; The NACK message generation unit is used to generate a negative acknowledgment message carrying CNP congestion notification and send back pressure to the sending end.

[0017] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any of the RDMA out-of-order data packet reordering management methods and systems described above without Bitmap head-of-line blocking.

[0018] Compared with the prior art, the RDMA out-of-order packet reordering management method and system provided by the present invention, which does not involve Bitmap head-of-line blocking, has the following beneficial effects: Compared with the prior art, the RDMA out-of-order packet reordering management method and system provided by the present invention, which does not involve Bitmap head-of-line blocking, has the following beneficial effects: 1. By using triple constraints based on bitmap occupancy rate, window overflow count, and sparse loss table resource availability, missing data packets causing bitmap head-of-line blocking are adaptively migrated to the sparse loss table, enabling the bitmap to continue sliding over long-term missing data packets. This eliminates head-of-line blocking in traditional sliding window bitmaps and improves the coverage and continuous reception capability of out-of-order data packets in limited bitmap space.

[0019] 2. By using fixed bit compression to record the sequence number of the data packets in the sparse loss table, and only allocating sparse entries to a small number of missing data packets that cause head-of-queue blocking, the on-chip storage overhead of a single sparse record entry is reduced while maintaining the non-blocking bitmap function. This reduces the on-chip memory usage of the RNIC in multi-queue concurrent scenarios, and improves hardware resource utilization efficiency and system scalability.

[0020] 3. By combining the batch timeout recovery of missing data packets in the bitmap with the asynchronous item-by-item recovery of sparse loss table entries, the missing data packets migrated to the sparse loss table are promptly retransmitted. When resources are insufficient or the out-of-order status is too high, a negative acknowledgment message carrying congestion notification is generated, thereby shortening the packet loss recovery delay, avoiding the exhaustion of bitmap and sparse table resources, and improving the reliable transmission performance and operational stability in lossy multipath RDMA networks. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the FastSlide architecture of the present invention; Figure 2 This is a bar chart showing the performance of FastSlide under out-of-order conditions. Figure 3 This is a bar chart showing the performance of FastSlide under packet loss. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0024] Example 1, please refer to Figures 1 to 3 As shown: Existing work attempts to increase the size of the bitmap to track a wider range of out-of-order packets. However, we have found that small increases in bitmap size do not improve network performance, while large increases are impractical due to significant hardware resource overhead and implementation complexity. The following explanation uses NS3 simulation experiments to illustrate this: Experimental Setup: Our topology consists of two nodes placed under two ToR switches, with eight parallel paths between them. These paths have random latency ranging from 1 to 8 microseconds, and all links operate at 400Gbps. We enabled Random Packet Spray (RPS) on the ToR switches to evenly distribute packets across the eight parallel paths. All eight paths experienced a slight random packet loss rate (e.g., 3%). To address network-induced packet loss and out-of-order delivery, we deployed a RACK-based selective retransmission scheme at the endpoints and conducted experiments with different bitmap sizes. We initiated a 1GB traffic stream between the two nodes and analyzed its average throughput.

[0025] Experimental Observation: The results show that with a 128-bit Bitmap, the effective throughput is only 178Gbps, and the effective bandwidth is only 44.5%, far below 97%. This is because during packet loss detection and retransmission, the Bitmap cannot advance further, and the continuously arriving data gradually overflows the range that the Bitmap can track and is discarded. The discarded packets trigger retransmissions, leading to bandwidth waste. Existing work tracks a larger range of out-of-order packets by expanding the Bitmap size. To verify the effectiveness of this approach, we increased the Bitmap by 50% to 192 bits and repeated the above experiment, increasing the effective throughput to 238Gbps. Although expanding the Bitmap to 256 bits can further increase the effective bandwidth to 325Gbps, it still suffers from severe bandwidth waste compared to the ideal situation, and also leads to a significant increase in Bitmap resource overhead.

[0026] Discussion: The experimental results above show that due to the head-of-line blocking problem of Bitmap, a large number of data packets exceed the range that the receiving Bitmap can track and are therefore discarded. Pre-allocated smaller Bitmaps suffer from severe performance degradation, while expanding the size of Bitmaps still suffers from a decrease in effective throughput and introduces a large amount of hardware resource overhead.

[0027] To address the problems mentioned in the technical solutions, this application provides a method and system for RDMA out-of-order packet reordering management without Bitmap head-of-line blocking. This paper proposes FastSlide, a non-blocking and hardware-resource-friendly packet reordering Bitmap design. FastSlide consists of two components: a fixed-size bitmap for recording out-of-order (OoO) packets within a continuous range; and a lightweight sparse loss table (SLT) maintained by each QP for recording a small number of packets that cause head-of-line blocking (HoL) in the bitmap. For arriving out-of-order packets, the control path records them in the bitmap, while the data path uses a packet-by-packet direct placement mechanism to directly write the data payload into the corresponding user space.

[0028] When bitmap resources are plentiful, FastSlide maximizes its reordering tolerance. When header blocking occurs due to bitmap exhaustion, FastSlide adaptively decides whether to evict the blocking header slot based on various factors (including bitmap occupancy, overflow events, and hardware resource pressure), with a timeout mechanism as a fallback strategy. Evicted header packets are recorded in the SLT. The SLT is implemented as a contiguous memory region consisting of multiple lost record entries, each storing a compressed PSN. For the SLT, the system employs an asynchronous loss recovery mechanism: this mechanism periodically triggers retransmissions, and the arrival of retransmitted packets releases SLT entries, allowing the table to continuously accommodate a small number of packets that would otherwise block the bitmap.

[0029] Example 2: Based on Embodiment 1, but with some differences, the following description, in conjunction with specific examples and accompanying drawings, illustrates the RDMA out-of-order data packet reordering management method and system proposed in this invention without Bitmap head-of-line blocking. The specific details are as follows: I. Adaptive Bitmap Recycling We use a length of W A fixed-size bitmap (e.g., 128 slots) is used to record ordered and out-of-order (OoO) data packets. The receiver maintains four key metadata fields: (1) L (leftPSN): The sequence number of the expected received header (HoL) packet; (2) p(occupancy): The number of packets received in the current window; (3) σ (overflow_cnt): The number of packets that fall outside the bitmap window; (4) Ω: The current load of the Sparse Loss Table (SLT).

[0030] When a serial number is S When the data packet arrives, the receiving end calculates its relative distance. d =( S L ) / MTU, and process as follows: (i) Historical retransmissions ( d <0): This packet is sent to the SLT to retrieve previously evicted lost records (ii) arriving in order ( d =0): The data packet is delivered immediately. The bitmap then slides to the right, clearing consecutive 1s until it encounters the first 0. Each time it slides over a slot, L Add 1, p Decrease by 1 and reset σ; (iii) Disorder within the window (0 < d < W ): index as d Set the bit to 1 and... p Add 1.

[0031] When the arriving data packet exceeds the bitmap range ( d ≥ W When this occurs, the system applies an adaptive bitmap recycling strategy based on the following three signals: (1) Sliding based on occupancy rate p ):use p As a statistical indicator of bitmap density. When p When the high watermark threshold θ(occ) is exceeded (e.g., 80%), the bitmap is considered sufficiently dense. At this point, multiple subsequent slots can be quickly reclaimed by expelling blocked head slots, with the additional overhead showing to be small in experiments. The PSN of the expelled slots is recorded in the Sparse Loss Table (SLT) to prevent bitmap head blocking.

[0032] (2) Overflow-based robustness (σ): To cope with scenarios of severe path imbalance or high packet loss (a large number of data packets fall into the bitmap window) W In addition to the above, the system monitors the overflow pressure σ. When σ exceeds the threshold θ(ovf), it indicates that header blocking has severely affected the receive performance. At this time, the bitmap prioritizes robustness and breaks the deadlock caused by a small number of missing HoL packets blocking a large number of OoO packet records by selectively expelling blocked header slots, thereby avoiding a collapse in effective throughput.

[0033] (3) Backpressure based on resource constraints (Ω): Bitmap sliding is strictly constrained by the capacity of the Sparse Loss Table (SLT). Bitmap sliding is paused when the number of incomplete evicted packets Ω approaches the hardware limit. This prevents memory resources from being exhausted and naturally creates backpressure on the receiver.

[0034] The specific process is shown in Algorithm 1. When the OoO data packet arrives and exceeds the bitmap window, if the bitmap occupancy rate... p If the overflow count σ exceeds the preset thresholds (θ(occ), θ(ovf)) and the SLT still has capacity, in line 6, the bitmap will attempt to reclaim slots by evicting header packets. Evicted packets are recorded in the SLT for asynchronous loss recovery, while the bitmap slides, decrementing the count for each occupied slot it passes. p And reduce σ accordingly. The sliding will continue as long as the head slot remains at 1. When an empty slot is encountered, the bitmap adjusts according to the current left boundary. L Recalculate the relative distance of the data packet, line 10. If the data packet has now fallen into the bitmap window, record it, line 11; otherwise, re-evaluate whether to continue sliding, lines 5–10.

[0035] Under extreme network conditions, such as widespread out-of-order delivery or high packet loss, if packets still cannot be buffered, a NACK with a Congestion Notification (CNP) is triggered, thus putting back pressure on the sender. It's important to note that this NACK directly triggers the retransmission of missing packets, not HoL packets (see lines 12-13). As a fallback mechanism, the system uses a 2-RTT bitmap timer to ensure forward progress. The timer resets as the bitmap slides; once it times out, all missing packets within the bitmap are immediately scheduled for retransmission.

[0036] Table 1 shows the statistical process of the adaptive bitmap recycling algorithm;

[0037] II. Asynchronous Packet Loss Recovery When the adaptive bitmap reclamation mechanism evicts a Head-Blocking (HoL) packet, the receiver inserts it into the Sparse Loss Table (SLT) and immediately allows the bitmap to slide forward, thus continuing to receive subsequent packets. Each SLT entry records only the compressed packet sequence number (PSN), not the full PSN, thereby reducing hardware overhead. The number of bits used for compression is configurable: more bits expand the range of uniquely representable in-transit packets, while fewer bits save memory. By default, we use 9 bits per PSN, which is sufficient to uniquely represent a sliding window containing 512 packets. At a 4KB MTU, this roughly corresponds to about 2MB of in-transit data.

[0038] Each queue pair (QP) maintains an independent, fixed-capacity sparse loss table (SLT) to track a predefined number of incomplete losses. Each SLT entry contains a valid bit and a compressed PSN, resulting in low memory overhead, approximately on the order of 10 times the number of entries per connection. When a HoL packet is evicted from the bitmap and added to the SLT, the left PSN of the current bitmap is recorded. L ), and immediately send NACK to trigger a retransmission. When a historical data packet is received ( PSN < L When a packet loss occurs, the receiver matches the lower bits of its PSN with all valid SLT entries and clears the matching records. To handle duplicate packet loss, SLT maintains a timer slightly longer than one RTT; when the timer expires, it triggers retransmission for all tracked packets until each incomplete loss is acknowledged.

[0039] III. Experimental Results 1. Emulator We evaluated FastSlide in the NS-3 simulation environment using an 8×16 leaf-spine topology with a 1:1 subscription ratio. All link rates were 400Gbps, and each switch had a 64MB shared buffer. Eight ToR switches connected to 16 NICs each, forming a cluster of 128 NICs (corresponding to 128 GPUs), with all nodes participating in the same communication group. To evaluate performance under conditions of both packet loss and out-of-order delivery, we introduced heterogeneous path latency between the leaf switches, randomly distributing the latency of parallel paths between 1μs and 8μs. We used a 100MB AllReduce workload and ensured that all traffic passed through the ToR switches to cover cross-rack communication scenarios. The evaluation metric was the completion time of the last stream, characterizing the communication bottleneck of the entire training task.

[0040] 2. FastSlide enables package-level load balancing We compared FastSlide with RACK-based selective retransmission, both incorporating random packet splitting within the network, and compared it with ECMP. For RACK-based selective retransmission, we set different delay retransmission intervals of 4, 8, and 16 µs. For FastSlide, the Sparse Loss Table (SLT) is configured with 50 bits to track up to 5 incomplete losses; combined with a 128-bit bitmap, each connection occupies a total of 178 bits of state. To ensure fairness, ECMP and the RACK-based scheme also use equivalent 178-bit bitmaps. In our experiments, FastSlide's parameters were set such that header packets were evicted when the bitmap occupancy rate θ(occ) exceeded 102 / 128 (80%) or the overflow count θ(ovf) reached 5 packets.

[0041] FastSlide can effectively mitigate the out-of-order loading introduced by packet-level load balancing. For example... Figure 3 As shown, compared to the baseline scheme, it significantly reduces the AllReduce job completion time (JCT). By supporting fine-grained random packet splitting (RPS), FastSlide consistently outperforms the baseline: JCT is reduced by 78.9% compared to ECMP; and performance improvements of 24.0%–44.0% are achieved for 4, 8, and 16µs RACK selective retransmissions compared to different out-of-order tolerance settings. These performance improvements mainly stem from two aspects: first, FastSlide supports packet-level load balancing, thereby fully utilizing path diversity; second, it can expel long-delayed packets from the bitmap, avoiding continuous header blocking and maintaining high throughput. In contrast, selective retransmission generates a large number of redundant retransmissions due to limited out-of-order tolerance or bitmap header blocking issues.

[0042] 3. FastSlide enables efficient packet loss recovery. This scheme introduces 1% random packet loss on the uplink of each ToR switch under the same experimental configuration to evaluate FastSlide's recovery capability in lossy networks. The results are as follows: Figure 3 As shown, FastSlide significantly outperforms RACK-based selective retransmission under various delay retransmission interval settings, with performance improvements ranging from 29.0% to 53.0%. This improvement is primarily due to FastSlide's ability to adaptively adjust out-of-order tolerance based on the real-time state of the bitmap, thereby significantly reducing unnecessary retransmissions and mitigating header blocking caused by latency or packet loss. In contrast, a larger latency threshold can lead to severe HoL blocking, while a smaller threshold can trigger premature retransmissions for a large number of out-of-order packets.

[0043] Simulation results in this embodiment demonstrate that, compared to ECMP and selective retransmission schemes based on fixed delay thresholds, this technical solution can improve RDMA's tolerance to multipath out-of-order delivery and random packet loss without increasing hardware state overhead per connection. By adaptively migrating missing data packets causing head-of-line congestion to a sparse loss table based on bitmap occupancy status and window overflow, the traditional sliding window bitmap can avoid prolonged stagnation due to late or lost data packets. Simultaneously, it reduces premature retransmissions or recovery delays caused by fixed retransmission thresholds, thereby making fuller use of multipath bandwidth, reducing redundant retransmissions, improving packet loss recovery efficiency, and enhancing RDMA communication throughput, task completion time, and operational stability.

[0044] It should be noted that the term "comprising" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0045] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method and system for managing out-of-order RDMA data packets without Bitmap head-of-line blocking, characterized in that, include: S1, Initialize and maintain metadata: The receiving end maintains bitmap metadata, which includes left boundary sequence number L, bitmap occupancy count ρ, data packet overflow count σ, and current load Ω of sparse loss table; set bitmap window length W, occupancy high watermark threshold θ (occ), overflow count threshold θ (ovf), and SLT hardware capacity limit. S2, Packet Classification and Flow Processing: Based on the distance d between the packet sequence number and the left boundary of the bitmap, distinguish three types of packets: historical retransmission, in-order arrival, and out-of-order arrival within the window, and perform SLT cleanup, direct upload, and bitmap marking operations respectively; S3, Adaptive Bitmap Recycling to De-HoL Blocking: When a message exceeds the window range, the overflow count is accumulated. If the three conditions of occupancy rate, overflow count, and SLT capacity are met, the missing packet at the head of the queue is moved to the SLT, the bitmap is slid and the message window ownership is re-determined. The cycle continues until the message can be stored in the bitmap. S4, fallback retransmission and congestion control: If a packet cannot be stored after multiple swipes, a negative response with congestion notification is sent; configure a 2RTT bitmap timer, and request batch retransmission of missing bitmap packets after timeout. S5, SLT asynchronous packet loss recovery: Missing packets stored in SLT immediately trigger the first retransmission. Combined with a single RTT-level entry timer, the packet will automatically retransmit repeatedly after the timeout. The SLT entry will be cleared after the corresponding retransmission message is received.

2. The RDMA out-of-order data packet reordering management method and system without Bitmap head-of-line blocking as described in claim 1, characterized in that, The S2 distinguishes between three types of messages: historical retransmissions, in-order arrivals, and out-of-order messages within the window. S2.1 Historical retransmission data packet d < 0: Match the compressed PSN record in the SLT. If a match is found, the corresponding SLT entry is cleared and the table entry resources are released. The PSN in the SLT is stored using fixed bit compression. A single SLT entry only contains the valid bits and the compressed PSN, reducing on-chip hardware storage overhead. S2.2 In-order arrival of data packets d=0: Directly deliver to the upper layer, the bitmap continues to slide to the right, update L and ρ and reset σ; S2.3 Out-of-order data packets within the window 0 < d < W: Set the corresponding index position of the bitmap to 1, and increment ρ.

3. The RDMA out-of-order data packet reordering management method and system without Bitmap head-of-line blocking as described in claim 1, characterized in that, The specific conditions for satisfying the occupancy rate, overflow count, and SLT capacity in S3 include: S3.1: When three conditions are met simultaneously, such as bitmap occupancy rate ρ>θ(occ), overflow count σ>θ(ovf), and SLT load Ω not reaching the hardware limit, the missing HoL data packet at the head of the bitmap queue is evicted, and the compressed PSN is stored in the SLT. S3.2: The bitmap skips the current blocked header and subsequent continuously received data packets to complete the sliding, and synchronously updates the left boundary sequence number L, the number of bitmap occupied ρ, the data packet overflow count σ, and recalculates the relative distance d of the current data packet; S3.3: If the relative distance d of the current data packet falls within the bitmap window W after the update, mark the data packet in the bitmap; if it still exceeds the window, repeat the cyclic sliding of S3.1-S3.

2.

4. The RDMA out-of-order data packet reordering management method and system without Bitmap head-of-line blocking as described in claim 1, characterized in that, The adaptive bitmap recycling in S3 includes a triple constraint judgment logic: (1) Occupancy constraint: If the proportion of bitmap data packets exceeds θ(occ), the bitmap is determined to be dense, and the data packet at the head of the queue is expelled to reclaim bitmap resources; (2) Overflow count constraint: If the number of data packets exceeding the bitmap window exceeds θ(ovf), the network is judged to be seriously out of order, and the head-of-line blocking is actively broken. (3) SLT resource constraints: When the current load Ω of SLT approaches the hardware capacity limit, the bitmap sliding is paused to form back pressure at the receiver and avoid exhaustion of hardware memory.

5. The RDMA out-of-order data packet reordering management method and system without Bitmap head-of-line blocking as described in claim 1, characterized in that, The out-of-order data path of the window adopts a packet-by-packet direct placement mechanism. After the out-of-order data packet arrives, the data payload is directly written into the host user space memory without waiting for the bitmap window to advance and complete the data delivery.

6. A method and system for managing out-of-order RDMA data packets without Bitmap head-of-line blocking, characterized in that, The RDMA out-of-order data packet reordering management method and system without Bitmap head-of-line blocking as described in any one of claims 1-5 includes a fixed-size bitmap storage module, a multi-QP independent sparse loss table (SLT) storage module, an adaptive bitmap recycling control unit, an asynchronous packet loss recovery scheduling unit, a data packet sequence number parsing unit, a NACK message generation unit, and a bitmap timeout timer unit. The adaptive bitmap reclamation control unit is used to read bitmap metadata such as bitmap occupancy count ρ, data packet overflow count σ, and current load Ω of the sparse loss table, and to execute bitmap sliding and HoL data packet eviction logic. The asynchronous packet loss recovery scheduling unit is used to manage SLT entry compression PSN storage, matching, timed retransmission and entry release; The NACK message generation unit is used to generate a negative acknowledgment message carrying CNP congestion notification and send back pressure to the sending end.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the RDMA out-of-order data packet reordering management method and system without Bitmap head-of-line blocking as described in any one of claims 1 to 5.

Images