A multipath congestion control apparatus, method, medium, and program product

Abstract

The application discloses a kind of multi-path congestion control device, method, medium and program product, it is related to network communication technical field, it is applied to sending end, comprising: receiving module is received when first congestion notification message, bit position corresponding to target path in queue pair context is in congestion state;Sending module is read under the dispatch trigger congestion bitmap and after sending token application to processor, it is zeroed;Processor calculates the token of multiple paths according to congestion bitmap and constructs path bitmap return;Sending module is according to path bitmap and token selection target path and sends message.The application is replaced by congestion bitmap state accumulation instead of real-time reporting per message, reduces congestion event processing frequency, simultaneously, based on path bitmap, multiple path token is issued and message distribution, avoid single path traffic burst.

Description

Technical Field

[0001] This application relates to the field of network communication technology, specifically to a multipath congestion control device, method, computer-readable storage medium, and computer program product. Background Technology

[0002] In RDMA multipath transmission scenarios, each congested path triggers a Congestion Notification Message (CNP) and is immediately reported to the processor. The more paths there are, the greater the number of CNPs, straining the processor's computing power due to frequent hardware and software interactions. Limited by this, when the network interface card's (NIC) transmitting module requests a token from the processor, the processor can only employ a low-overhead simplified allocation strategy, returning only one token per path at a time, concentrating multiple packets onto that single path for transmission. This single-path token allocation leads to short-term bursts of high traffic (e.g., four packets bursting onto a fixed path between two requests), exacerbating local congestion and generating more CNP reports to the CPU. This creates a positive feedback loop of "CNP overload → simplified token allocation → traffic bursts → more CNPs," resulting in decreased congestion control efficiency and a continuous deterioration of CPU load. Summary of the Invention

[0003] The purpose of this application is to propose a multipath congestion control device, method, computer-readable storage medium, and computer program product to solve the problems of single-path traffic bursts and excessively high congestion event processing frequency in multipath data center quantized congestion notification.

[0004] According to a first aspect of this application, a multipath congestion control device is proposed, applied at a transmitting end, including a receiving module, a scheduling module, a transmitting module, and a processor;

[0005] The receiving module is configured to receive a first congestion notification message, determine the target data stream and target path corresponding to the first congestion notification message, read the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is in a non-congested state, the receiving module sets the bit in the congestion bitmap corresponding to the target path to a congested state; wherein, each bit in the congestion bitmap corresponds to a path; The scheduling module is used to schedule at least two data streams to obtain a target data stream to be sent, and to trigger the sending module to perform the sending operation of the target data stream; The sending module is further configured to, in response to the triggering of the sending operation, read the congestion bitmap in the queue pair context, generate a token request based on the congestion bitmap, send the token request to the processor, and clear the congestion bitmap in the queue pair context; The processor is configured to, upon receiving a token request carrying the congestion bitmap, determine the tokens for multiple paths corresponding to the target data stream and construct a path bitmap based on the congestion bitmap, and return the path bitmap and the tokens for the multiple paths to the sending module; wherein, each bit in the path bitmap corresponds to a path, and the bit position corresponding to the path allocated with a token is in a valid state. The sending module is further configured to select a target path based on the path bitmap and the tokens of the multiple paths, and send the message of the target data stream to the receiving end through the target path.

[0006] In one possible implementation, the receiving module is further configured to, upon receiving the second congestion notification message, determine the target data stream and the target path corresponding to the second congestion notification message, read the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is already in a congested state, then the receiving module reports the second congestion notification message to the processor. The processor is further configured to receive and cache the second congestion notification message, and upon subsequently receiving a token request corresponding to the target data stream, the processor executes a preset congestion algorithm to calculate tokens for multiple paths corresponding to the target data stream based on the second congestion notification message and the congestion bitmap carried in the token request.

[0007] In one possible implementation, the sending module is configured to cache the tokens of the multiple paths as the remaining tokens of the corresponding paths, select a target path to send a message based on the paths in the path bitmap where the bits are in a valid state and the corresponding remaining tokens are not zero, and deduct the remaining tokens corresponding to the target path after each message is sent; when it is detected that the remaining tokens corresponding to all paths in the path bitmap where all bits are in a valid state have been deducted to zero, the sending module rereads the congestion bitmap in the queue pair context and initiates the next token request to the processor.

[0008] In one possible implementation, the sending module is used to filter out paths from the path bitmap where the bit is in a valid state and the corresponding remaining token is not zero as candidate paths, and to select the candidate paths as target paths in a round-robin manner for message sending.

[0009] According to a second aspect of this application, a multipath congestion control method is proposed, applied at the sending end, the method comprising: The receiving module receives a first congestion notification message, determines the target data stream and target path corresponding to the first congestion notification message, reads the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is in a non-congested state, the receiving module sets the bit in the congestion bitmap corresponding to the target path to a congested state; wherein, each bit in the congestion bitmap corresponds to a path; The scheduling module schedules at least two data streams to obtain the target data stream to be sent, and triggers the sending module to execute the sending operation of the target data stream; In response to the triggering of the sending operation, the sending module reads the congestion bitmap in the queue pair context, generates a token request based on the congestion bitmap, sends the token request to the processor, and clears the congestion bitmap in the queue pair context. After receiving a token request carrying the congestion bitmap, the processor determines the tokens for multiple paths corresponding to the target data stream and constructs a path bitmap based on the congestion bitmap, and returns the path bitmap and the tokens for the multiple paths to the sending module; wherein, each bit in the path bitmap corresponds to a path, and the bit position corresponding to the path allocated with a token is in a valid state. The sending module selects a target path based on the path bitmap and the tokens of the multiple paths, and sends the message of the target data stream to the receiving end through the target path.

[0010] One possible implementation also includes: When the receiving module receives the second congestion notification message, it determines the target data stream and the target path corresponding to the second congestion notification message, reads the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is already in a congested state, the receiving module reports the second congestion notification message to the processor. The processor receives and caches the second congestion notification message. When it subsequently receives a token request corresponding to the target data stream, the processor executes a preset congestion algorithm to calculate tokens for multiple paths corresponding to the target data stream based on the second congestion notification message and the congestion bitmap carried in the token request.

[0011] In one possible implementation, the sending module selects a target path based on the path bitmap and the tokens of the multiple paths, and sends the message of the target data stream to the receiving end through the target path, specifically including: The sending module caches the tokens of the multiple paths as the remaining tokens for the corresponding paths; The sending module selects a target path to send a message based on the path bitmap where the bit is in a valid state and the corresponding remaining token is not zero, and deducts the remaining token corresponding to the target path after each message is sent. When it is detected that the remaining tokens corresponding to the path for which all bits in the path bitmap are in a valid state have been reduced to zero, the sending module rereads the congestion bitmap in the queue pair context and initiates the next token request to the processor.

[0012] In one possible implementation, the sending module selects a target path to send a message based on paths in the path bitmap where bits are valid and the corresponding remaining tokens are not zero, including: The sending module selects paths from the path bitmap where the bit is valid and the corresponding remaining token is not zero as candidate paths, and uses a round-robin approach to sequentially select the candidate paths as target paths for message sending.

[0013] According to a third aspect of this application, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described in the second aspect of this application.

[0014] According to a fourth aspect of this application, a computer program product is proposed, comprising a computer program that, when executed by a processor, implements the method described in the second aspect of this application.

[0015] The multipath congestion control device, method, computer-readable storage medium, and computer program product proposed in this application have the following beneficial effects: By setting a congestion bitmap in the queue context to record the congestion status of each path in the data stream, the receiving module only sets the bitmap when the corresponding bit is in a non-congested state. The sending module sends the congestion bitmap to the processor along with the token request and then clears it immediately when triggering a sending operation. Compared with the traditional method, this mechanism changes the timing of congestion status reporting, replacing the traditional method of reporting to the processor in real time for each congestion notification message with bitmap status accumulation, effectively solving the problem of excessively high congestion event processing frequency. At the same time, the processor calculates tokens for multiple paths based on the received congestion bitmap and constructs corresponding path bitmaps. The sending module selects the target path based on the path bitmap and the tokens of multiple paths, realizing the transmission of the target data stream message to the receiving end through multiple paths. By utilizing the multi-path distribution capability, the transmission pressure of a single path is directly distributed, thereby solving the problem of single-path traffic bursts, reducing congestion, i.e., the probability of receiving a CNP, thus reducing software and hardware interactions and improving message transmission efficiency. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a structural diagram of a multipath congestion control device according to Embodiment 1 of this application.

[0018] Figure 2 This is a flowchart of a multipath congestion control method according to Embodiment 1 of this application.

[0019] The diagram is labeled as follows: 1-receiving module, 2-scheduling module, 3-transmitting module, 4-processor. Detailed Implementation

[0020] The detailed description of the accompanying drawings is intended to illustrate the present preferred embodiments of this application and is not intended to represent only the forms in which this application can be implemented. It should be understood that the same or equivalent functions can be achieved by different embodiments intended to be included within the spirit and scope of this application.

[0021] Example 1 Please see Figure 1 This embodiment proposes a multipath congestion control device, applied to the transmitting end, including a receiving module, a scheduling module, a transmitting module, and a processor; The receiving module is configured to receive a first congestion notification message, determine the target data stream and target path corresponding to the first congestion notification message, read the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is in a non-congested state, the receiving module sets the bit in the congestion bitmap corresponding to the target path to a congested state; wherein, each bit in the congestion bitmap corresponds to a path; Specifically, in multi-path data center networks, due to differences in switch buffers and loads across physical links, the timing and severity of congestion on different paths are typically inconsistent. The receiving module maintains a congestion bitmap in the Queue Pair Context (QPC), enabling the recording of multi-path congestion states with minimal hardware overhead. Upon receiving a Congestion Notification Message (CNP) for any path, it does not directly report the CNP to the processor but first records it using the congestion bitmap. The congestion bitmap is essentially a bit vector, its bit width matching the number of multipaths supported by the target data stream. Based on the message information carried by the first congestion notification message, the target data stream and target path corresponding to the first congestion notification message can be determined. For example, in a data stream supporting four paths, the congestion bitmap can be set to 4 bits, corresponding to paths 0 to 3 from low to high, with initial values ​​all set to 0 (non-congested state). When the receiving module parses the path identifier carried in the first congestion notification message (CNP) as path 1, it reads the current congestion bitmap. If bit 1 is 0, it flips it to 1 (congestion state).

[0022] The scheduling module is used to schedule at least two data streams to obtain a target data stream to be sent, and to trigger the sending module to perform the sending operation of the target data stream; Specifically, the scheduling module is the scheduler for internal service flow within the network interface card (NIC) hardware. It determines when to request resources from the processor and which data stream to send. In a multi-queue NIC architecture, the scheduling module typically arbitrates based on strategies such as the buffer water level of each queue, Service Level Agreement (SLA), or weighted round-robin. For example, assuming the NIC currently has flows A and B belonging to different queue pairs (QPs), the scheduling module detects through round-robin that the sending queue of flow A has accumulated packets reaching a preset threshold, while the queue of flow B is empty. In this case, the scheduling module decides that flow A has the right to send, outputs the identifier of flow A as the target data stream, and outputs a trigger signal to the sending module. As another example, in a strict priority scheduling scenario, if the scheduling module detects the arrival of a high-priority flow C, even if a low-priority flow D is waiting, the scheduling module will immediately preempt arbitration, triggering the sending module to execute a sending operation for flow C.

[0023] The sending module is further configured to, in response to the triggering of the sending operation, read the congestion bitmap in the queue pair context, generate a token request based on the congestion bitmap, send the token request to the processor, and clear the congestion bitmap in the queue pair context; Specifically, after receiving the trigger signal from the scheduling module, the sending module reads the congestion bitmap in the current QPC, generates a token request, carries the congestion bitmap in the token request, and sends the token request to the processor. The token refers to the amount of data / bytes that can be sent on each path. After successfully sending the token request to the processor, the sending module needs to clear all bits of the congestion bitmap in the current QPC to zero, indicating that the CNP packets of each path of the target data stream have been reported to the processor in batches. Therefore, clearing the bits is necessary to facilitate the recording of CNP packets of each path of the target data stream in the future.

[0024] The processor is configured to, upon receiving a token request carrying the congestion bitmap, determine the tokens for multiple paths corresponding to the target data stream and construct a path bitmap based on the congestion bitmap, and return the path bitmap and the tokens for the multiple paths to the sending module; wherein, each bit in the path bitmap corresponds to a path, and the bit position corresponding to the path allocated with a token is in a valid state. Specifically, after receiving a token request carrying a congestion bitmap from the sending module, the processor first parses the congestion bitmap to determine which paths in the target data stream have congestion indications. Then, the processor executes a preset congestion algorithm for multiple paths in the target data stream. This algorithm can combine the congestion status and current rate of each path to calculate the token (i.e., the number of bytes of the message that can be sent) corresponding to each path. For example, the preset congestion algorithm might reduce the current rate or decrease the allocation weight of the corresponding token for paths marked as congested in the bitmap; for paths not marked as congested in the bitmap, it maintains or increases their current rate and token allocation weight. This differentiated rate calculation based on bitmap status enables independent congestion control and dynamic bandwidth allocation among multiple paths. It should be noted that the above is only a simple example; in practical applications, the congestion algorithm can be adjusted according to actual technical requirements. After calculating the tokens for multiple paths, the processor constructs a path bitmap. The bit width of the path bitmap is consistent with the number of paths in the target data stream. If a token is assigned to a path, the corresponding bit position in the path bitmap is in a valid state (e.g., set to 1). Finally, the processor sends the constructed path bitmap and the specific token values ​​for each path to the sending module. In this way, the processor can return the scheduling and token information for multiple paths in a single interaction, which is beneficial for achieving even packet transmission across multiple paths and avoiding traffic bursts on a single path.

[0025] The sending module is further configured to select a target path based on the path bitmap and the tokens of the multiple paths, and send the message of the target data stream to the receiving end through the target path.

[0026] Specifically, after receiving the path bitmap and tokens for multiple paths from the processor, the sending module determines the set of paths currently allowed to send packets and the amount of data allowed to be sent on each path based on the path bitmap and the tokens for multiple paths. In subsequent packet transmission, the sending module no longer sends bursts of packets to a single path as in traditional techniques. Instead, based on the available paths indicated in the path bitmap, it evenly distributes packets across multiple paths for transmission. Each transmission requires verification of the remaining tokens for the corresponding path until all tokens for all paths are exhausted. This multi-path packet distribution method in this embodiment avoids bursts of traffic on a single path, resulting in a more balanced distribution of network traffic in a short period. This allows for better utilization of multi-path network bandwidth and significantly mitigates the adverse effects of single-path bursts on network congestion control.

[0027] In summary, the device in this embodiment records the congestion status of each path in the data stream by setting a congestion bitmap in the queue context. The receiving module only sets the bitmap when the corresponding bit is in a non-congested state. The sending module sends the congestion bitmap to the processor along with the token request and then clears it immediately when a sending operation is triggered. This mechanism changes the timing of congestion status reporting, replacing the traditional method of reporting to the processor in real time for each congestion notification message with bitmap status accumulation, effectively solving the problem of excessively high congestion event processing frequency. At the same time, the processor calculates tokens for multiple paths based on the received congestion bitmap and constructs corresponding path bitmaps. The sending module selects the target path based on the path bitmap and the tokens of multiple paths, realizing the transmission of the target data stream message to the receiving end through multiple paths. By utilizing the multi-path distribution capability, the transmission pressure of a single path is directly distributed, thereby solving the problem of single-path traffic bursts.

[0028] Based on the above Embodiment 1, in some embodiments, the receiving module is further configured to, upon receiving the second congestion notification message, determine the target data stream and the target path corresponding to the second congestion notification message, read the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is already in a congested state, then the receiving module reports the second congestion notification message to the processor. Specifically, in a real-world network environment, multiple Congestion Notification Messages (CNPs) may be received consecutively along the same path within a short period. For example, both the first and second CNPs may belong to the target path. Since the sending module has already set the bit position corresponding to the target path in the QPC congestion bitmap to a congested state when it receives the first CNP, the congestion bitmap has not yet been reported to the processor when the second CNP is received. Therefore, the bit position corresponding to the target path in the congestion bitmap is still congested. To prevent congestion event loss, the receiving module will not repeatedly set the congestion bitmap but will directly report the second CNP to the processor. In other words, during the interval between the sending module clearing the congestion bitmap and the next token request, for the same path, the receiving module only uses the first CNP to update the congestion bitmap; subsequent consecutive CNPs (i.e., second CNPs) will be directly reported to the processor to prevent CNP loss.

[0029] The processor is further configured to receive and cache the second congestion notification message, and upon subsequently receiving a token request corresponding to the target data stream, the processor executes a preset congestion algorithm to calculate tokens for multiple paths corresponding to the target data stream based on the second congestion notification message and the congestion bitmap carried in the token request.

[0030] Specifically, after receiving the second congestion notification message directly reported by the receiving module, the processor caches it or updates the path status of the corresponding target path based on the second congestion notification message, without immediately triggering congestion algorithm calculation. Only when the sending module subsequently initiates a new token request for the target data stream (the token request carrying the latest recorded congestion bitmap) will the processor combine the cached second congestion notification message or the path status of the target path with the congestion bitmap carried in the current token request to make a comprehensive decision to determine whether the target path can be allocated a token. This embodiment's device, through a mechanism combining bitmap recording and direct reporting, significantly reduces the frequency of software and hardware interactions under normal conditions by utilizing bitmaps, while ensuring zero loss of CNP information under extreme congestion conditions through direct reporting, thus guaranteeing the accuracy of the congestion control algorithm.

[0031] Based on the above Embodiment 1, in some embodiments, the sending module is used to cache the tokens of the multiple paths as the remaining tokens of the corresponding paths, select the target path to send a message according to the path bitmap where the bit is in a valid state and the corresponding remaining token is not zero, and deduct the remaining token corresponding to the target path after each message is sent; when it is detected that the remaining tokens corresponding to all paths where all bit is in a valid state in the path bitmap have been deducted to zero, the sending module rereads the congestion bitmap in the queue pair context and initiates the next token request to the processor.

[0032] Specifically, after obtaining tokens for multiple paths issued by the processor, the sending module allocates storage space locally for each path and caches these tokens as the remaining tokens for the corresponding path. During the message sending phase, the sending module monitors the path bitmap in real time and selects paths with valid bits (indicating that the path allows message sending) and corresponding remaining tokens greater than zero as optional target paths. After successfully sending a message to a target path, the sending module immediately deducts the corresponding number of bytes from the remaining tokens of that target path. The sending module continues the loop of selecting a path → sending a message → deducting tokens until it detects that all paths in the path bitmap are set to valid and their corresponding remaining tokens have all been deducted to zero. At this point, it indicates that all the token quota requested in this application has been exhausted, and the sending module will then trigger a new round of token requests, reread the congestion bitmap newly accumulated in the queue context (QPC) during this period, and initiate a new token request to the processor accordingly. The batch token consumption mechanism in this embodiment further extends the time interval between the two software and hardware interactions.

[0033] Based on the above Embodiment 1, in some embodiments, the sending module is used to filter out paths from the path bitmap where the bit is in a valid state and the corresponding remaining token is not zero as candidate paths, and to sequentially select the candidate paths as target paths for message sending using a round-robin method.

[0034] Specifically, to achieve uniform packet distribution across multiple paths and eliminate bursts on single paths, the sending module incorporates a polling scheduling strategy. After determining the candidate path set (i.e., paths in the path bitmap where bits are valid and remaining tokens are non-zero), the sending module sequentially selects the next target path from the candidate paths for packet transmission according to the polling order. For example, assuming candidate paths are path 0, path 1, and path 2, the sending module will output packets to these paths in a fixed order: path 0 → path 1 → path 2 → path 0 → path 1 → path 2. This embodiment, through its polling spraying mechanism, ensures that packets are evenly distributed across multiple available paths within a very short time window, directly eliminating macroscopically balanced but microscopically bursty traffic spikes at the physical transmission level, significantly improving the congestion control stability of multi-path networks.

[0035] Example 2 See Figure 1 Embodiment 2 of this application proposes a multi-path congestion control method, applied at the sending end, which can be implemented based on the multi-path congestion control device described in Embodiment 1. The method includes: Step S10: The receiving module receives a first congestion notification message, determines the target data stream and target path corresponding to the first congestion notification message, reads the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is in a non-congested state, the receiving module sets the bit in the congestion bitmap corresponding to the target path to a congested state; wherein, each bit in the congestion bitmap corresponds to a path; Step S20: The scheduling module schedules at least two data streams to obtain the target data stream to be sent, and triggers the sending module to execute the sending operation of the target data stream; In step S30, in response to the triggering of the sending operation, the sending module reads the congestion bitmap in the queue pair context, generates a token request based on the congestion bitmap, sends the token request to the processor, and clears the congestion bitmap in the queue pair context. Step S40: After receiving a token request carrying the congestion bitmap, the processor determines the tokens for multiple paths corresponding to the target data stream and constructs a path bitmap based on the congestion bitmap, and returns the path bitmap and the tokens for the multiple paths to the sending module; wherein, each bit in the path bitmap corresponds to a path, and the bit position corresponding to the path allocated with a token is in a valid state. In step S50, the sending module selects a target path based on the path bitmap and the tokens of the multiple paths, and sends the message of the target data stream to the receiving end through the target path.

[0036] Based on the content of Embodiment 2 above, some embodiments further include: In step S60, when the receiving module receives the second congestion notification message, it determines the target data stream and the target path corresponding to the second congestion notification message, reads the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is already in a congested state, the receiving module reports the second congestion notification message to the processor. In step S70, the processor receives and caches the second congestion notification message. When it subsequently receives a token request corresponding to the target data stream, the processor executes a preset congestion algorithm to calculate tokens for multiple paths corresponding to the target data stream based on the second congestion notification message and the congestion bitmap carried in the token request.

[0037] Based on the above embodiment two content, in some embodiments, step S50 specifically includes: Step S501: The sending module caches the tokens of the multiple paths as the remaining tokens of the corresponding paths; Step S502: The sending module selects a target path to send a message based on the path bit map where the bit is in a valid state and the corresponding remaining token is not zero, and deducts the remaining token corresponding to the target path after each message is sent. Step S503: When it is detected that the remaining tokens corresponding to the paths where all bits in the path bitmap are in a valid state have been reduced to zero, the sending module rereads the congestion bitmap in the queue pair context and initiates the next token request to the processor.

[0038] Based on the above embodiment two content, in some embodiments, step S502 includes: The sending module selects paths from the path bitmap where the bit is valid and the corresponding remaining token is not zero as candidate paths, and uses a round-robin approach to sequentially select the candidate paths as target paths for message sending.

[0039] It should be noted that the method in this second embodiment corresponds to the device in the first embodiment above. Therefore, any content not described in detail in this second embodiment can be obtained by referring to the device in the first embodiment above. Hence, no further details are provided in this second embodiment.

[0040] Example 3 Embodiment 3 of this application proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in Embodiment 2 above.

[0041] Specifically, the computer-readable storage medium can be any medium capable of containing, storing, transmitting, propagating, or transporting a program for use by or in conjunction with an instruction execution system, apparatus, or device. For example, a computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. Specific examples include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, or any suitable combination of the foregoing. When the computer program is loaded onto a computer or other programmable data processing device, it causes the computer or other programmable data processing device to perform a series of operational steps to produce a computer-implemented process, thereby providing instructions executable on the computer or other programmable device for implementing the program. Figure 2 The steps specified in the flowchart.

[0042] Example 4 Embodiment 4 of this application proposes a computer program product, including computer program instructions, which, when executed by a processor, implement the steps of the method described in Embodiment 2 above.

[0043] Specifically, the computer program product may be embodied as program code used to cause a computer system to perform some or all of the steps of the method described in the embodiments of this application. The computer program product may be one or more computer-readable media on which computer-readable program code is stored. This computer-readable program code may be accessed, retrieved, loaded, and executed by one or more processors. Various components of the computer program product may be implemented according to various programming languages ​​and / or technologies. The program code may be written in any combination of one or more programming languages, including assembly language, C / C++, Perl, Python, etc. The program code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer.

[0044] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many updates and modifications will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A multipath congestion control device, characterized in that, It is used on the transmitting end and includes a receiving module, a scheduling module, a transmitting module, and a processor; The receiving module is configured to receive a first congestion notification message, determine the target data stream and target path corresponding to the first congestion notification message, read the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is in a non-congested state, the receiving module sets the bit in the congestion bitmap corresponding to the target path to a congested state; wherein, each bit in the congestion bitmap corresponds to a path; The scheduling module is used to schedule at least two data streams to obtain a target data stream to be sent, and to trigger the sending module to perform the sending operation of the target data stream; The sending module is further configured to, in response to the triggering of the sending operation, read the congestion bitmap in the queue pair context, generate a token request based on the congestion bitmap, send the token request to the processor, and clear the congestion bitmap in the queue pair context; The processor is configured to, upon receiving a token request carrying the congestion bitmap, determine the tokens for multiple paths corresponding to the target data stream and construct a path bitmap based on the congestion bitmap, and return the path bitmap and the tokens for the multiple paths to the sending module; wherein, each bit in the path bitmap corresponds to a path, and the bit position corresponding to the path allocated with a token is in a valid state. The sending module is further configured to select a target path based on the path bitmap and the tokens of the multiple paths, and send the message of the target data stream to the receiving end through the target path.

2. The multipath congestion control device according to claim 1, characterized in that, The receiving module is further configured to, upon receiving the second congestion notification message, determine the target data stream and the target path corresponding to the second congestion notification message, read the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is already in a congested state, then the receiving module reports the second congestion notification message to the processor. The processor is further configured to receive and cache the second congestion notification message, and upon subsequently receiving a token request corresponding to the target data stream, the processor executes a preset congestion algorithm to calculate tokens for multiple paths corresponding to the target data stream based on the second congestion notification message and the congestion bitmap carried in the token request.

3. A multipath congestion control device according to claim 1 or 2, characterized in that, The sending module is used to cache the tokens of the multiple paths as the remaining tokens of the corresponding paths, select the target path to send the message according to the path bit map where the bit is in a valid state and the corresponding remaining token is not zero, and deduct the remaining token corresponding to the target path after each message is sent. When it is detected that the remaining tokens corresponding to the path for which all bits in the path bitmap are in a valid state have been reduced to zero, the sending module rereads the congestion bitmap in the queue pair context and initiates the next token request to the processor.

4. A multipath congestion control device according to claim 3, characterized in that, The sending module is used to filter out paths from the path bitmap where the bit is in a valid state and the corresponding remaining token is not zero as candidate paths, and to select the candidate paths as target paths in a round-robin manner for message sending.

5. A multipath congestion control method, characterized in that, Applied to the sending end, the method includes: The receiving module receives a first congestion notification message, determines the target data stream and target path corresponding to the first congestion notification message, reads the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is in a non-congested state, the receiving module sets the bit in the congestion bitmap corresponding to the target path to a congested state; wherein, each bit in the congestion bitmap corresponds to a path; The scheduling module schedules at least two data streams to obtain the target data stream to be sent, and triggers the sending module to execute the sending operation of the target data stream; In response to the triggering of the sending operation, the sending module reads the congestion bitmap in the queue pair context, generates a token request based on the congestion bitmap, sends the token request to the processor, and clears the congestion bitmap in the queue pair context. After receiving a token request carrying the congestion bitmap, the processor determines the tokens for multiple paths corresponding to the target data stream and constructs a path bitmap based on the congestion bitmap, and returns the path bitmap and the tokens for the multiple paths to the sending module; wherein, each bit in the path bitmap corresponds to a path, and the bit position corresponding to the path allocated with a token is in a valid state. The sending module selects a target path based on the path bitmap and the tokens of the multiple paths, and sends the message of the target data stream to the receiving end through the target path.

6. A multipath congestion control method according to claim 5, characterized in that, Also includes: When the receiving module receives the second congestion notification message, it determines the target data stream and the target path corresponding to the second congestion notification message, reads the congestion bitmap in the queue pair context corresponding to the target data stream, and if the bit in the congestion bitmap corresponding to the target path is already in a congested state, the receiving module reports the second congestion notification message to the processor. The processor receives and caches the second congestion notification message. When it subsequently receives a token request corresponding to the target data stream, the processor executes a preset congestion algorithm to calculate tokens for multiple paths corresponding to the target data stream based on the second congestion notification message and the congestion bitmap carried in the token request.

7. A multipath congestion control method according to claim 5 or 6, characterized in that, The sending module selects a target path based on the path bitmap and the tokens of the multiple paths, and sends the message of the target data stream to the receiving end through the target path, specifically including: The sending module caches the tokens of the multiple paths as the remaining tokens for the corresponding paths; The sending module selects a target path to send a message based on the path bitmap where the bit is in a valid state and the corresponding remaining token is not zero, and deducts the remaining token corresponding to the target path after each message is sent. When it is detected that the remaining tokens corresponding to the path for which all bits in the path bitmap are in a valid state have been reduced to zero, the sending module rereads the congestion bitmap in the queue pair context and initiates the next token request to the processor.

8. A multipath congestion control method according to claim 7, characterized in that, The sending module selects a target path to send a message based on the paths in the path bitmap where the bits are valid and the corresponding remaining tokens are not zero, including: The sending module selects paths from the path bitmap where the bit is valid and the corresponding remaining token is not zero as candidate paths, and uses a round-robin approach to sequentially select the candidate paths as target paths for message sending.

9. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method as described in any one of claims 5 to 8.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 5 to 8.

Images