Differential congestion control method based on RDMA (Remote Direct Memory Access) and hardware controller system

Abstract

The invention discloses a differentiated congestion control method based on RDMA (Remote Direct Memory Access) and a hardware controller system. In the invention, a differentiated congestion control algorithm is provided by using the DSCP, so that the limitation of complete fair regulation and control of the traditional congestion control algorithm is broken through, accurate resource allocation for different flow types is realized, and a more efficient bandwidth utilization rate is achieved under the congestion condition; complete hardening of a congestion controller system is realized, a scheme for dynamically supporting all congestion flows in a network and supporting 1024 concurrent congestion flows at most is provided, and the congestion flows in the network can be managed more efficiently to achieve the purpose of relieving network congestion; the data which is read from the host and participates in operation does not need to be stored in the cache, so that the burden of the host is reduced, the performance reduction caused by bus data reading delay is eliminated, the processing speed of the parallel congestion event is remarkably improved, and the delay of rate feedback is reduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of RDMA network congestion control algorithms, and particularly relates to a differential congestion control method and a hardware controller system based on RDMA. Background Art

[0002] With the expansion of the scale of data centers, the traditional TCP / IP protocol is difficult to meet the high-throughput requirements due to problems such as high kernel protocol processing latency and large memory copy overhead. The RDMA technology significantly reduces communication latency through zero-copy, kernel bypass, and CPU offloading mechanisms, but its high-throughput characteristics are prone to causing network congestion. The current mainstream congestion controls include explicit congestion notification (ECN), round trip time (RTT), and in-band network telemetry (INT) congestion control. In the prior art, although the congestion control algorithms based on RTT or INT have been improved, there are problems such as high deployment complexity or dependence on additional hardware support. The ECN-based congestion control algorithm DCQCN has become the most widely used congestion control algorithm due to its low deployment cost and fast feedback response.

[0003] However, the DCQCN algorithm has the following defects: on the one hand, there are great limitations in the fairness regulation of the DCQCN algorithm. It adopts a unified deceleration and acceleration strategy for all traffic and cannot distinguish between high-priority and low-priority services, resulting in insufficient bandwidth and increased latency for critical traffic due to competition from low-priority flows; on the other hand, the DCQCN algorithm has poor dynamic adaptability. The fixed parameter adjustment cannot cope with diverse traffic scenarios, especially in high-load scenarios, the network link utilization improvement is limited. In addition, relying solely on software to implement the congestion control algorithm will pose a risk of untimely congestion control response, which will further exacerbate network congestion. Hardware controllers are the mainstream at present, and current hardware controllers also have problems such as supporting fewer congested connections and incomplete hardening. Summary of the Invention

[0004] The purpose of the present invention is to provide a differential congestion control method and a hardware controller system based on RDMA in order to solve the above-mentioned problems.

[0005] The technical solution adopted by the present invention is as follows: A differential congestion hardware controller system based on RDMA, characterized in that: the system includes:

[0006] A congestion management module, which is used to complete the binding, matching, and reading of congestion flow numbers in the network, internal address conversion, parameter storage, rate calculation, and registration of timing events, dynamically support all congestion flows in the network, and support a maximum of 1024 concurrent congestion flows.

[0007] The timing management module is used to complete the functions of storing the timing event time and managing the timing events.

[0008] The data packet sending module is used to implement the functions of packet assembly, packet sending, and packet parsing in network data packets. The input end of the data packet sending module is connected to the output end of the data packet receiving module.

[0009] The data packet receiving module is used to receive data packets and send a congestion notification message to the data packet sending module when a data packet with an ECN mark is received.

[0010] The scheduling module is used to adjust the sending rate of the transmitting end of the data packet sending module after receiving the calculated rate from the congestion control module. The output end of the scheduling module is connected to the input end of the data packet sending module.

[0011] The APB bus is used for module initialization configuration, which is implemented through configuration registers.

[0012] Switch: It is used for data packet forwarding and probabilistically marking ECN when the length of its output queue exceeds the threshold. The input end of the switch is connected to the output end of the data packet sending module, and the output end of the switch is connected to the input end of the data packet receiving module.

[0013] In a preferred embodiment, the congestion management module communicates bidirectionally with the APB bus and the timing management module respectively. The input end of the congestion management module is connected to the output ends of the data packet receiving module and the data packet sending module, and the output end of the congestion management module is connected to the input end of the scheduling module.

[0014] In a preferred embodiment, the congestion management module includes:

[0015] The flow number / internal address conversion module is used to complete the binding, matching, and reading of congestion flow numbers in the network.

[0016] The parameter storage module is used to store the recommended rate RC, the target rate RT, the deceleration factor α, the byte count timeout times BC, the timing event timeout times T, the moment of the last deceleration Tlatest, the cumulative length of the sent data packets pkt_length, and the priority field DSCP.

[0017] The rate calculation module is used to calculate the acceleration or deceleration rate by looking up a table.

[0018] In a preferred embodiment, the timing management module includes:

[0019] The timing event storage module is used to store the timing event pointer and the corresponding remaining time.

[0020] The three - level timing engine module is used for timing event management. It realizes parallel timing of 216 time units through hierarchical timing. For any timing event with a start time of P and a remaining time of Q, it will complete timing at the system time P + Q. The sum of P + Q can respectively represent the timeout moments of a task in each level of the timing engine. The accuracy of the last - level timing engine is only 1 timing cycle and can be ignored. Therefore, a three - level timing engine is adopted.

[0021] In a preferred embodiment, the processing steps for the control method when receiving a congestion notification include:

[0022] (1) The data packet sending module assembles data packets and sends the data packets to the switch.

[0023] (2) The switch forwards the data packet and performs ECN probabilistic marking when the length of the output queue exceeds the threshold.

[0024] (3) If the data packet receiving module receives a data packet with an ECN mark, it enters step (3) and sends a congestion notification message to the data packet sending module. If it does not receive a data packet with an ECN mark, it means that the data stream has not experienced congestion.

[0025] (4) The data packet sending module parses the congestion notification message and sends a congestion notification containing the flow number and DSCP priority field to the congestion management module.

[0026] (5) The flow number / internal address conversion module receives the congestion notification and uses the flow number for matching. If the match is successful, it means that the data stream has encountered congestion before; if the match fails, it means that the data stream encounters congestion for the first time and needs to query the idle address of the flow number / internal address conversion module. Finally, the rate after speed reduction is obtained through internal processing.

[0027] (6) Send the calculated rate obtained from step (4) to the scheduling module according to the flow number.

[0028] (7) The scheduling module receives the new rate, adjusts the scheduling policy for the data stream again, and notifies the data packet sending module to adjust the sending rate.

[0029] In a preferred embodiment, in step (5), the internal processing specifically includes the following steps:

[0030] (5a) If the match is successful, obtain the internal address through the flow number / internal address conversion module, and read the parameters in the parameter storage module; if the match fails, search for an idle address in the flow number / internal address conversion module. If there is an idle address, go to step (5a), write the flow number into the flow number / internal address conversion module, read the parameters of the parameter storage module, register a timing event notification including the internal address and the remaining time with the timing management module, and if there is no idle address, discard the congestion notification.

[0031] (5b) Transmit the parameters to the rate calculation module and perform a look-up table calculation for the speed reduction process in combination with the DSCP priority field obtained in step (4).

[0032] (5c) Write the updated parameters into the parameter storage module.

[0033] In a preferred embodiment, the processing steps for the control method to receive the byte count situation include:

[0034] (1) The data packet sending module performs data packet assembly and sends a byte count notification including the data packet length, the corresponding flow number, and the DSCP priority field to the congestion management module.

[0035] (2) The flow number / internal address conversion module receives the byte count notification and uses the flow number for matching. If the match is successful, go to step (2), indicating that this data flow has encountered congestion before and obtain the internal address; if the match fails, it means that this data flow has not encountered congestion, and discard this byte count notification.

[0036] (3) Read the parameters in the parameter storage module through the internal address. If the sum of pkt_length and the data packet length obtained in step (1) exceeds the threshold, go to step (4); if the sum of pkt_length and the data packet length obtained in step (1) does not exceed the threshold, go to step (5).

[0037] (4) Transmit the parameters to the rate calculation module for a look-up table calculation for the acceleration process.

[0038] (5) Write the updated parameters into the parameter storage module.

[0039] (6) Send the calculated rate to the scheduling module from the flow number obtained in step (1).

[0040] (7) The scheduling module receives the new rate, re-adjusts the scheduling policy for this data flow, and notifies the data packet sending module to adjust the sending rate.

[0041] In a preferred embodiment, the processing steps for the control method to receive the timing event situation include:

[0042] (1) When the timing event is completed, the timing management module sends a timing event completion notification containing the internal address to the congestion management module.

[0043] (2) The flow number / internal address conversion module receives the timing event completion notification, obtains the internal address, reads the flow number, and stores the parameters in the parameter storage module through the internal address read parameters.

[0044] (3) Transmit the parameters to the rate calculation module for look-up table calculation of the acceleration process.

[0045] (4) Write the updated parameters into the parameter storage module.

[0046] (5) Send the calculated rate and the flow number obtained from step (1) to the scheduling module.

[0047] (6) The scheduling module receives the new rate, readjusts the scheduling policy for the data stream, and notifies the packet sending module to adjust the sending rate.

[0048] In a preferred embodiment, in step (3), the internal processing specifically includes the following steps:

[0049] (3a) If the calculated rate reaches the maximum rate, clear the corresponding flow number of the flow number / internal address conversion module through the internal address; if the calculated rate does not reach the maximum rate, proceed to step (3b).

[0050] (3b) Register a timing event notification containing the internal address and the remaining time with the timing management module.

[0051] In a preferred embodiment, the processing steps of the timing module of the control method include:

[0052] (1) After receiving the timing event notifications in step (5a) of case 1 and step (3b) of case 3, write the internal address (the timing module pointer is equivalent to the internal address) and the remaining time into the timing event storage module.

[0053] (2) Calibrate the remaining time through the current system time and allocate it to the time slots of the three-level timing engine. Each time slot maintains an event linked list. New events are connected to the list through the head and tail pointers. The head and tail pointers of the empty time slot are invalid. When there are multiple events, the head pointer points to the next pointer and the tail pointer points to the end of the chain.

[0054] (3) Each time slot updates the number of events to be processed (i.e., the number of events registered during this time period) at the exact time point, and processes the timing events in the linked list in order.

[0055] (4) If the event processing is later than the exact time point, recalculate the remaining time and adjust it to the next-level time slot. The three-level engine processes the events step by step until the remaining time is 0.

[0056] (5) When the remaining time is 0, the corresponding timing event is completed, and a timing event completion notification containing the internal address is sent to the congestion management module.

[0057] In summary, due to the adoption of the above technical solutions, the beneficial effects of the present invention are as follows:

[0058] 1. In the present invention, the differential control of traffic types is achieved by introducing the DSCP priority field. Traditional congestion control algorithms adopt a unified regulation strategy for all traffic, resulting in uneven resource allocation when high-priority services compete with low-priority services. In this solution, by converting the DSCP value into a priority factor and combining look-up table calculation during the rate adjustment process, high-priority traffic can obtain more active bandwidth guarantee and lower latency. This mechanism breaks through the complete fairness limitation of traditional algorithms, can preferentially meet the needs of critical services when congestion occurs, and at the same time improves the overall network bandwidth utilization rate.

[0059] 2. In the present invention, the system adopts a fully hardened hardware controller architecture, which significantly improves the processing efficiency and response speed. By integrating congestion management, timing management, and scheduling functions into dedicated hardware modules, the calculation latency and host resource occupation caused by software implementation are avoided. The hardware module directly processes packet parsing, parameter storage, and rate calculation, without relying on the host cache or frequent bus data transmission, thereby reducing the processing latency and improving the parallel processing ability. This design enables the system to quickly respond to network congestion events and effectively avoid the deterioration of congestion caused by feedback latency.

[0060] 3. In the present invention, the system supports dynamic management of a large number of concurrent congestion flows, enhancing the scalability and adaptability of network congestion control. Through the binding mechanism of flow numbers and internal addresses and the optimized design of the parameter storage module, the system can real-time track and adjust the congestion flow status in the network. The hierarchical management strategy of the three-level timing engine further improves the processing efficiency of timing events, ensuring stable operation even in high-load scenarios. This design enables the system to adapt to diverse traffic scenarios and at the same time provides efficient congestion mitigation capabilities for large-scale data centers. Brief Description of the Drawings

[0061] Figure 1 It is the hardware system framework diagram of the present invention;

[0062] Figure 2 It is the internal module block diagram of the congestion control module in the present invention;

[0063] Figure 3 It is the method flowchart for the present invention to receive a congestion notification;

[0064] Figure 4 It is the method flowchart for the present invention to receive a byte count notification;

[0065] Figure 5 This is a flowchart of the method for the present invention to receive a timing event completion notification. Detailed implementation manners

[0066] In order to make the objectives, technical solutions and advantages of the present invention more clear and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0067] Embodiment:

[0068] Refer to Figures 1-5 ,

[0069] A differentiated congestion hardware controller system based on RDMA, comprising:

[0070] A congestion management module, which is used to complete the binding, matching and reading of congestion flow numbers in the network, internal address conversion, parameter storage, rate calculation, and registration of timing events, dynamically support all congestion flows in the network, and support a maximum of 1024 concurrent congestion flows.

[0071] A timing management module, which is used to complete the functions of storing the timing event time and managing the timing events.

[0072] A data packet sending module, which is used to implement the functions of packet assembly, packet sending, and packet parsing in network data packets. The input end of the data packet sending module is connected to the output end of the data packet receiving module.

[0073] A data packet receiving module, which is used to implement data packet reception and send a congestion notification message to the data packet sending module when receiving a data packet with an ECN mark.

[0074] A scheduling module, which is used to adjust the sending rate of the sending end of the data packet sending module after receiving the calculation rate of the congestion control module. The output end of the scheduling module is connected to the input end of the data packet sending module.

[0075] An APB bus, which is used for module initialization configuration.

[0076] A switch: which is used for data packet forwarding and performing probabilistic ECN marking when the length of its output queue exceeds a threshold. The input end of the switch is connected to the output end of the data packet sending module, and the output end of the switch is connected to the input end of the data packet receiving module.

[0077] Such as Figure 2As shown in the figure, the congestion management module communicates bidirectionally with the APB bus and the timing management module respectively. The input end of the congestion management module is connected to the output ends of the data packet receiving module and the data packet sending module, and the output end of the congestion management module is connected to the input end of the scheduling module.

[0078] The congestion management module includes:

[0079] A flow number / internal address conversion module, which is used to complete the binding, matching, and reading of congestion flow numbers in the network.

[0080] A parameter storage module, which is used to store the recommended rate R C , the target rate R T , the deceleration factor α, the byte count timeout times BC, the timing event timeout times T, the moment of the last deceleration T latest , the cumulative length of the sent data packets pkt_length, and the priority field DSCP.

[0081] A rate calculation module, which is used to look up the table and calculate the acceleration or deceleration rate.

[0082] As shown in Table 1, the combination of DP-DCQCN introduces DSCP information into the control mechanism and uses the formula p = k * (DSCP - 15) to calculate the parameter reflecting the priority, where p is the priority factor. The DSCP value range is divided into two categories: high priority (≥15) and low priority (<15). Through piecewise linear mapping, it is ensured that high-priority flows are more sensitive to p. This enables the algorithm to treat traffic with different priorities differently when adjusting the rate. The value range of k is 0 to 1. Different k values can be designed for different priority value ranges to reflect the discrimination.

[0083]

[0084]

[0085] As Figure 2 shown, the timing management module includes:

[0086] A timing time storage module, which is used to store the timing time pointer and the corresponding remaining time.

[0087] A three-level timing engine module, which is used for timing event management. Through hierarchical timing, parallel timing of 2 16 time units is achieved. For any timing event with a start time of P and a remaining time of Q, it will complete timing at the system time P + Q. The sum of P + Q can represent the timeout moment of a task in each level of the timing engine. The accuracy of the last level of the timing engine is only 1 timing cycle and can be ignored. Therefore, a three-level timing engine is adopted.

[0088] Another object of the present invention is to provide a control method for a hardware controller system of a differentiated congestion algorithm based on RDMA, and the method includes sequential steps in 4 cases:

[0089] Initialize the entire hardware controller system through the APB bus to complete the initialization configuration of each module. As shown in 1 Figure 3 The processing steps for receiving a congestion notification are as follows:

[0090] (1) The data packet sending module assembles data packets and sends the data packets to the switch.

[0091] (2) The switch forwards the data packet and performs ECN probabilistic marking when the length of the egress queue exceeds the threshold.

[0092] (3) If the data packet receiving module receives a data packet with an ECN mark, it enters step (3) and sends a congestion notification message to the data packet sending module. If it does not receive a data packet with an ECN mark, it means that the data stream is not congested.

[0093] (4) The data packet sending module parses the congestion notification message and sends a congestion notification including a flow number and a DSCP priority field to the congestion management module.

[0094] (5) The flow number / internal address conversion module receives the congestion notification and uses the flow number for matching. If the match is successful, it means that the data stream has encountered congestion before; if the match fails, it means that the data stream encounters congestion for the first time and needs to query the free address of the flow number / internal address conversion module. Finally, the rate after speed reduction is obtained through internal processing.

[0095] (6) Send the calculated rate obtained from step (4) to the scheduling module according to the flow number.

[0096] (7) The scheduling module receives the new rate, adjusts the scheduling policy for the data stream again, and notifies the data packet sending module to adjust the sending rate.

[0097] In step (5) of case 1, the internal processing specifically includes the following steps:

[0098] (5a) If the match is successful, obtain the internal address through the flow number / internal address conversion module and read the parameters in the parameter storage module; if the match fails, search for the free address of the flow number / internal address conversion module. If there is a free address, enter step (5a), write the flow number into the flow number / internal address conversion module, read the parameters of the parameter storage module, and register a timing event notification including the internal address and the remaining time with the timing management module. If there is no free address, discard the congestion notification.

[0099] (5b) The parameter recommended rate RC The deceleration factor α is transmitted to the rate calculation module, and a look-up table calculation for the deceleration process is performed in combination with the DSCP priority field obtained in step (4).

[0100] (5c) The updated proposed rate R C The target rate R T The deceleration factor α, the byte count timeout count BC, the timing event timeout count T, the time T of the most recent deceleration latest The cumulative length of the sent data packets pkt_length are written into the parameter storage module.

[0101] 2 As Figure 4 shown, the processing steps for receiving the byte count situation are as follows:

[0102] (1) The data packet sending module assembles the data packets, and notifies the congestion management module of the byte count including the data packet length, the corresponding flow number, and the DSCP priority field.

[0103] (2) The flow number / internal address conversion module receives the byte count notification and matches it using the flow number. If the match is successful, it enters step (2), indicating that the data flow has encountered congestion before and obtains the internal address; if the match fails, it means that the data flow has not encountered congestion, and this byte count notification is discarded.

[0104] (3) Read the parameters in the parameter storage module through the internal address. If the sum of pkt_length and the data packet length obtained in step (1) exceeds the threshold, enter step (4); if the sum of pkt_length and the data packet length obtained in step (1) does not exceed the threshold, enter step (5).

[0105] (4) Transmit the parameter proposed rate R C The target rate R T The priority DSCP field to the rate calculation module for look-up table calculation of the acceleration process.

[0106] (5) Write the updated parameter proposed rate R C The byte count timeout count BC, the cumulative length of the sent data packets pkt_length into the parameter storage module.

[0107] (6) Transmit the calculated rate and the flow number obtained from step (1) to the scheduling module.

[0108] (7) The scheduling module receives the new rate and re-adjusts the scheduling policy for this data flow, and notifies the data packet sending module to adjust the sending rate.

[0109] 3 As Figure 5 shown, the processing steps for receiving the timing event situation are as follows:

[0110] (1) When the timing management module completes a timing event, it sends a timing event completion notification containing the internal address to the congestion management module.

[0111] (2) The flow number / internal address conversion module receives the timing event completion notification, obtains the internal address, reads the flow number, and stores the parameters through the parameters in the internal address reading parameter storage module.

[0112] (3) Transmit the parameter recommended rate R C , the target rate R T , and the priority DSCP field to the rate calculation module for look-up table calculation of the acceleration process.

[0113] (4) Write the updated parameter recommended rate R C , the deceleration factor α, the number of timing event timeouts T, and the time T of the most recent deceleration into the parameter storage module. latest Write to the parameter storage module.

[0114] (5) Send the calculated rate and the flow number obtained from step (1) to the scheduling module.

[0115] (6) The scheduling module receives the new rate, re-adjusts the scheduling policy for this data stream, and notifies the packet sending module to adjust the sending rate.

[0116] In step (3) of case 3, the internal processing specifically includes the following steps:

[0117] (3a) If the calculated rate reaches the maximum rate, clear the corresponding flow number of the flow number / internal address conversion module through the internal address; if the calculated rate does not reach the maximum rate, go to step (3b).

[0118] (3b) Register a timing event notification containing the internal address and the remaining time with the timing management module.

[0119] 4 Timing module processing steps:

[0120] (1) After receiving the timing event notifications in step (5a) of case 1 and step (3b) of case 3, write the internal address (the timing module pointer is equivalent to the internal address) and the remaining time into the timing event storage module.

[0121] (2) Calibrate the remaining time through the current system time and allocate it to the time slots of the three-level timing engine. Each time slot maintains an event linked list. New events are connected to the list through the head and tail pointers. The head and tail pointers of empty time slots are invalid. When there are multiple events, the head pointer points to the next pointer and the tail pointer points to the end of the chain.

[0122] (3) Each time slot updates the number of events to be processed (i.e., the number of events registered during that time period) at the exact hour, and processes the timing events in the linked list in sequence.

[0123] (4) If the event processing is later than the exact hour, recalculate the remaining time and adjust it to the next-level time slot. The three-level engine processes the events level by level until the remaining time is 0.

[0124] (5) When the remaining time is 0, the corresponding timing event is completed, and a timing event completion notification containing the internal address is sent to the congestion management module.

[0125] In summary, the present invention uses DSCP to propose a differentiated congestion control algorithm, which breaks through the limitation of the traditional congestion control algorithm's completely fair regulation, realizes precise resource allocation for different traffic types, and has a higher bandwidth utilization rate in case of congestion; realizes the complete hardening of the congestion controller system, provides a solution that dynamically supports all congestion flows in the network and can support up to 1024 concurrent congestion flows at most, and can manage the congestion flows in the network more efficiently to achieve the purpose of alleviating network congestion; does not need to store the data read from the host for operation in the cache, thus reducing the host burden and eliminating the performance degradation caused by the bus data reading delay, significantly improving the processing speed of parallel congestion events and reducing the delay of rate feedback.

[0126] In the present invention, a differentiated congestion control algorithm is proposed by introducing the DSCP priority field, which breaks through the limitation of the traditional congestion control algorithm's completely fair regulation, realizes precise resource allocation for different traffic types, and has a higher bandwidth utilization rate in case of congestion.

[0127] In the present invention, the complete hardening of the congestion controller system is realized. It is not necessary to store the data read from the host for operation in the cache, thus reducing the host burden and eliminating the performance degradation caused by the bus data reading delay, significantly improving the processing speed of parallel congestion events and reducing the delay of rate feedback.

[0128] In the present invention, the system supports dynamic management of a large number of concurrent congestion flows, enhancing the scalability and adaptability of network congestion control. Through the binding mechanism of the flow number and the internal address and the optimized design of the parameter storage module, the system can track and adjust the congestion flow state in the network in real time. The hierarchical management strategy of the three-level timing engine further improves the processing efficiency of timing events, ensuring stable operation even in high-load scenarios. This design enables the system to adapt to diverse traffic scenarios and provides efficient congestion mitigation capabilities for large-scale data centers at the same time.

[0129] It should be noted that, in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the said element.

[0130] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A differentiated congestion hardware controller system based on RDMA, characterized in that: The system comprises: Congestion management module, used to complete the binding, matching and reading of congestion flow numbers in the network, internal address conversion, parameter storage, rate calculation and registration timing event functions, dynamically support all congestion flows in the network and support a maximum of 1024 concurrent congestion flows; The timing management module is used to complete the functions of timing event time storage and timing event management; The data packet sending module is used to realize the functions of packet assembly, packet sending and packet parsing in the network data packet; the input end of the data packet sending module is connected to the output end of the data packet receiving module; The data packet receiving module is used to realize data packet reception and send a congestion notification message to the data packet sending module when receiving a data packet with an ECN mark; A scheduling module, configured to adjust the sending rate of the data packet sending module after receiving the calculated rate from the congestion control module; the output end of the scheduling module is connected to the input end of the data packet sending module; APB bus, used for module initialization configuration, implemented through configuration registers; Switch: used for data packet forwarding and probabilistic ECN marking when the length of its egress queue exceeds a threshold; the switch input end is connected to the output end of the data packet sending module, and the switch output end is connected to the input end of the data packet receiving module.

2. The RDMA-based differentiated congestion hardware controller system according to claim 1, characterized in that: The congestion management module communicates bidirectionally with the APB bus and the timing management module respectively. The input end of the congestion management module is connected to the output ends of the data packet receiving module and the data packet sending module. The output end of the congestion management module is connected to the input end of the scheduling module.

3. The RDMA-based differentiated congestion hardware controller system according to claim 1, characterized in that: The congestion management module comprises: The flow number / internal address translation module is used to complete the binding, matching and reading of congested flow numbers in the network; The parameter storage module is used to store the recommended rate RC, the target rate RT, the speed reduction factor α, the byte count timeout number BC, the timing event timeout number T, the time of the latest speed reduction Tlatest, the cumulative length of the sent data packets pkt_length, and the priority field DSCP; The rate calculation module is used to calculate the acceleration or deceleration rate by looking up the table.

4. The RDMA-based differentiated congestion hardware controller system according to claim 1, characterized in that: The timing management module includes: A timing event storage module, used to store a timing event pointer and the corresponding remaining time; The three-level timing engine module is used for timing event management. It realizes parallel timing of 216 time units through hierarchical timing. For any timing event with a start time of P and a remaining time of Q, it will complete the timing at the system time P+Q. The sum of P+Q can represent the time when a task times out in each level of the timing engine. The accuracy of the last level of the timing engine is only 1 timing cycle, which can be ignored. Therefore, a three-level timing engine is used.

5. The RDMA-based differentiated congestion hardware control method according to claim 1, characterized in that: The control method receives a congestion notification and the processing steps include: (1) The data packet sending module assembles the data packets and sends the data packets to the switch; (2) The switch forwards the data packet and performs ECN probabilistic marking when the egress queue length exceeds the threshold; (3) If the data packet receiving module receives a data packet with an ECN mark, it proceeds to step (3) and sends a congestion notification message to the data packet sending module; if it does not receive a data packet with an ECN mark, it means that the data flow is not congested; (4) The data packet sending module parses the congestion notification message and sends a congestion notification including the flow number and DSCP priority field to the congestion management module; (5) The flow number / internal address translation module receives the congestion notification and uses the flow number for matching. If the match is successful, it means that the data flow has encountered congestion before. If the match fails, it means that the data flow has encountered congestion for the first time and needs to query the free address of the flow number / internal address translation module. Finally, the rate after the speed reduction is obtained through internal processing. (6) Send the flow number obtained from step (4) to the scheduling module; (7) The scheduling module receives the new rate, readjusts the scheduling strategy for the data flow, and notifies the data packet sending module to adjust the sending rate.

6. The RDMA-based differentiated congestion hardware control method according to claim 5, characterized in that: In step (5), the internal processing specifically includes the following steps: (5a) If the match is successful, the internal address is obtained through the flow number / internal address conversion module, and the parameters in the parameter storage module are read; if the match fails, the free address of the flow number / internal address conversion module is searched, and if there is a free address, the process goes to step (5a), the flow number is written into the flow number / internal address conversion module, the parameters of the parameter storage module are read, and the timing event notification including the internal address and the remaining time is registered with the timing management module. If there is no free address, the congestion notification is discarded; (5b) transmitting the parameters to the rate calculation module and performing table lookup calculation of the speed reduction process in combination with the DSCP priority field obtained in step (4); (5c) Write the updated parameters into the parameter storage module.

7. The RDMA-based differentiated congestion hardware control method according to claim 1, characterized in that: The control method receives the byte count information and the processing steps include: (1) The data packet sending module performs data packet grouping and sends a byte count notification including the data packet length, the corresponding flow number and the DSCP priority field to the congestion management module; (2) The stream number / internal address conversion module receives the byte count notification and uses the stream number for matching. If the match is successful, it proceeds to step (2), which means that the data stream has encountered congestion before and has obtained the internal address. If the match fails, it means that the data stream has not encountered congestion, and the byte count notification is discarded. (3) Read the parameters in the parameter storage module through the internal address. If the sum of pkt_length and the data packet length obtained in step (1) exceeds the threshold, proceed to step (4); if the sum of pkt_length and the data packet length obtained in step (1) does not exceed the threshold, proceed to step (5); (4) transmitting the parameters to the rate calculation module for table lookup calculation of the acceleration process; (5) Writing the updated parameters into the parameter storage module; (6) Send the flow number obtained from step (1) with the calculated rate to the scheduling module; (7) The scheduling module receives the new rate, readjusts the scheduling strategy for the data flow, and notifies the data packet sending module to adjust the sending rate.

8. The RDMA-based differentiated congestion hardware control method according to claim 1, characterized in that: The control method receives a timing event and processes the following steps: (1) When a timing event is completed, the timing management module sends a timing event completion notification containing an internal address to the congestion management module; (2) The stream number / internal address conversion module receives the timing event completion notification, obtains the internal address, reads the stream number, and reads the parameters in the parameter storage module through the internal address; (3) transmitting the parameters to the rate calculation module for table lookup calculation of the acceleration process; (4) Writing the updated parameters into the parameter storage module; (5) Send the calculated rate and the flow number obtained from step (1) to the scheduling module; (6) The scheduling module receives the new rate, readjusts the scheduling strategy for the data flow, and notifies the data packet sending module to adjust the sending rate.

9. The RDMA-based differentiated congestion hardware control method according to claim 8, characterized in that: In the step (3), the internal processing specifically includes the following steps: (3a) If the calculated rate reaches the maximum rate, clear the flow number / flow number corresponding to the internal address conversion module through the internal address; if the calculated rate does not reach the maximum rate, go to step (3b); (3b) Register the timing event notification including the internal address and the remaining time to the timing management module.

10. The RDMA-based differentiated congestion control method according to claim 1, characterized in that: The timing module processing steps of the control method include: (1) After receiving the timing event notification of step (5a) of case 1 and step (3b) of case 3, write the internal address (the timing module pointer is equal to the internal address) and the remaining time into the timing event storage module; (2) The remaining time is calibrated with the current system time and allocated to the time slots of the three-level timing engine. Each time slot maintains an event list. New events are added to the list through head and tail pointers. The head and tail pointers of empty time slots are invalid. When there are multiple events, the head pointer points to the next pointer and the tail pointer points to the end of the chain. (3) Each time slot updates the number of pending events (i.e., the number of events registered in that time period) at the exact moment, and processes the timing events in the linked list in order; (4) If the event is processed later than the on-time time, the remaining time is recalculated and adjusted to the next level time slot. The three-level engine processes the event level by level until the remaining time is 0; (5) When the remaining time is 0, the corresponding timing event is completed, and a timing event completion notification containing an internal address is sent to the congestion management module.

Images