Acceleration logic determination method and apparatus, and chip, network interface card, computer device, readable storage medium and program product

Abstract

The present application relates to an acceleration logic determination method and apparatus, and a computer device, a computer-readable storage medium and a computer program product. The method comprises: on the basis of the current network rate and a T-event time cycle parameter, obtaining the number of bytes expected to be sent when an expected T event is triggered; and when the number of currently sent bytes is greater than the number of bytes expected to be sent, executing acceleration logic. In the present method, the number of bytes expected to be sent is a value that dynamically changes with the current rate, and can be adaptively adjusted on the basis of the actual congestion situation of a current flow, and a T-event time cycle parameter is coupled with the number of sent bytes, thereby effectively avoiding improper acceleration caused by an excessively low threshold of the number of sent bytes.

Description

Methods, devices, chips, network interface cards, computer equipment, readable storage media, and program products for determining boost logic.

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on March 14, 2025, with application number 2025103028986, entitled "Increase Logic Determination Method, Apparatus, Chip, Network Interface Card, Computer Equipment, Readable Storage Medium and Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a method, apparatus, chip, network interface card, computer equipment, computer-readable storage medium, and computer program product for determining acceleration logic. Background Technology

[0004] Current RDMA (Remote Direct Memory Access) network cards need to use congestion control (CC) algorithms to detect and mitigate network congestion. The most mainstream congestion control algorithm is DCQCN (Data Center Quantized Congestion Notification).

[0005] In traditional technology, the DCQCN algorithm performs a speed-up operation when it is determined that there is no network congestion. The speed-up determination of DCQCN and the speed-up mode depends on the following three factors: (1) Whether the T event occurs, that is, whether the congestion notification packet is not received within the timer period. If it occurs, the T value (i.e., the number of T events) is incremented by 1; (2) Whether the BC event occurs, that is, whether more than ByteCounter bytes are sent without receiving CNP (Congestion Notification Packet). If it occurs, the BC value (the number of BC events) is incremented by 1; (3) The speed-up logic is determined based on the numerical relationship between T, BC and the speed-up state threshold value F. The speed-up logic includes: Fast Recovery process, Additive Increase process and Hyper Increase process. The Fast Recovery process restores the speed to a rate close to that before the speed-down, the Additive Increase process continues to probe available bandwidth, and the Hyper Increase process probes available bandwidth more actively.

[0006] However, the inventors realized that configuring ByteCounter as a static parameter could lead to inappropriate rate-up. Unlike the Timer parameter, the ByteCounter parameter is not constrained by the rate-down parameter. Therefore, if ByteCounter is set too small, a contradictory situation may occur: the rate increases due to a BC event within a K (rp_rate_reduce_monitor_period) period, but then a CNP event is received requiring rate-down. This repeated rate-up and rate-down within the same K period may persist, and congestion may not be effectively alleviated due to inappropriate rate-up, leading to algorithm failure. Summary of the Invention

[0007] Therefore, it is necessary to provide a method, device, chip, network interface card, computer equipment, computer-readable storage medium, and computer program product that can effectively avoid improper speed-up caused by an excessively low threshold for the number of bytes sent, in order to address the aforementioned technical problems.

[0008] Firstly, this application provides a method for determining acceleration logic, including:

[0009] Based on the current network speed and the T event time period parameter, the expected number of bytes to be sent when the expected T event is triggered is obtained;

[0010] If the number of bytes already sent is greater than the expected number of bytes to be sent, execute the speed-up logic.

[0011] In one alternative embodiment, prior to executing the acceleration logic, the following is further included:

[0012] If the number of bytes sent is greater than the expected number of bytes to be sent, update the number of BC events, where the current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time.

[0013] The acceleration logic is determined based on the relationship between the number of BC events and the acceleration state threshold.

[0014] In one optional embodiment, determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold includes:

[0015] If the number of BC events is less than the speed-up state threshold, the speed-up logic is determined to be fast recovery logic, which is used to restore the network speed to the speed before the speed-down.

[0016] In one optional embodiment, determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold includes:

[0017] If the number of BC events is greater than or equal to the acceleration state threshold, and less than or equal to the acceleration state threshold of the target multiple, the acceleration logic is determined to be active increase logic; the active increase logic is used to detect the first available bandwidth.

[0018] In one optional embodiment, the step of determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold further includes:

[0019] If the number of BC events is greater than the target multiple of the acceleration state threshold, the acceleration logic is determined to be an over-proactive increase logic; the over-proactive increase logic is used to detect a second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

[0020] In one optional embodiment, before obtaining the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter, the method further includes:

[0021] If no congestion notification message is received by the end of the time period corresponding to the T event time period parameter, continue to execute the step of obtaining the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter.

[0022] If a congestion notification message is received at the end of the time period corresponding to the T event time period parameter, the number of BC events and the number of bytes currently sent are reset.

[0023] Secondly, this application also provides an acceleration logic determination device, the device comprising:

[0024] The expected number of bytes to be sent module is used to obtain the expected number of bytes to be sent when the expected event T is triggered, based on the current network rate and the time period parameter of event T.

[0025] The update module is used to execute acceleration logic when the number of bytes already sent is greater than the expected number of bytes to be sent.

[0026] Thirdly, this application also provides a chip, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the above embodiments.

[0027] Fourthly, this application also provides a network interface card, including a chip as described in any of the above embodiments and multiple interfaces, wherein the chip processes data or communicates externally through the interfaces.

[0028] Fifthly, this application also provides a computer device including the network interface card described in any of the above embodiments, wherein the network interface card is used for processing data or external communication.

[0029] Sixthly, this application also provides 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 any of the above embodiments.

[0030] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the above embodiments.

[0031] The aforementioned speed-up logic determination method, device, chip, network interface card, computer equipment, computer-readable storage medium, and computer program product, based on the current network rate and the T-event time period parameter, obtain the expected number of bytes to be sent when the expected T-event is triggered. Thus, if the current number of bytes sent is greater than the expected number of bytes to be sent, the speed-up logic is executed. The expected number of bytes to be sent is a value that changes dynamically with the current rate and can be adaptively adjusted according to the actual congestion situation of the current flow. By coupling the T-event time period parameter and the number of bytes to be sent, inappropriate speed-up caused by an excessively low threshold for the number of bytes to be sent can be effectively avoided. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the disclosed drawings without creative effort.

[0033] Figure 1 is a schematic diagram of the acceleration / deceleration process of the standard DCQCN algorithm.

[0034] Figure 2 is a schematic diagram of the application environment of the acceleration logic determination method according to one or more embodiments.

[0035] Figure 3 is a flowchart illustrating the acceleration logic determination method according to one or more embodiments.

[0036] Figure 4 is a flowchart illustrating the acceleration logic determination method according to one or more other embodiments.

[0037] Figure 5 is a block diagram of an acceleration logic determination device according to one or more embodiments.

[0038] Figure 6 is a block diagram of a computer device according to one or more embodiments. Detailed Implementation

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

[0040] Currently, RDMA network interface cards based on the RoCE (RDMA over Converged Ethernet) protocol generally implement this congestion control mechanism based on the publicly available DCQCN algorithm model.

[0041] DCQCN follows the RP-CP-NP model. The Reaction Point (RP), i.e., the data sender, is the main body executing the algorithm and is responsible for performing rate-up and rate-down operations. The Congestion Point (CP) marks outgoing packets with ECN (Explicit Congestion Notification) by checking the buffer queue size. If the queue size is less than kmin, no marking is performed; if the queue size is between kmin and kma, probabilistic marking is performed (the marking probability is linearly related to the queue size); if the queue size is greater than kma, the packet is deterministically marked with ECN. When the Notification Point (NP) receives a packet with ECN, if it receives ECN packets from the same flow within the same sampling period (which is determined based on the rate-down filtering threshold K), it ignores them; otherwise, it needs to respond with a Congestion Notification Packet (CNP). Upon receiving a CNP message, the RP determines that the current network is congested and performs a rate-down operation. This rate-down is achieved by quantifying congestion using the α parameter (a larger α indicates higher congestion, and vice versa). If the response point does not receive a CNP message after the time period (determined based on the response point's rate-up filtering threshold Timer) ends (or the number of sent messages exceeds ByteCounter), then the network is considered congested-free, and a rate-up operation can be performed. The rate-up operation consists of three phases: Fast Recovery, which restores the network to near its pre-rate-down speed; Additive Increase, which continues to probe available bandwidth; and Hyper Increase, which more actively probes available bandwidth.

[0042] The acceleration / deceleration process of the standard DCQCN algorithm is shown in Figure 1. This application mainly focuses on the acceleration logic of the standard DCQCN algorithm. The acceleration determination of DCQCN and the acceleration mode it is in depends on the following three factors: (1) Whether the T event occurs, that is, whether the CNP message is not received within the timer period. If it occurs, the T value (the number of times the T event occurs) is incremented by 1; (2) Whether the BC event occurs, that is, whether more than ByteCounter bytes are sent without receiving the CNP message. If it occurs, the BC value (the number of times the BC event occurs) is incremented by 1; (3) The numerical relationship between the T value, the BC value and the acceleration status threshold value F. If the larger of T and BC is greater than 0 and less than F, then the fast recovery acceleration algorithm is executed: r_c = (r_c + r_t) / 2, where r_c is the current rate and r_t is the target rate; if the larger of T and BC is greater than or equal to F, and the smaller of T and BC is less than or equal to F, then the active increase acceleration algorithm is executed: r_t = r_t + AI, r_c = (r_c + r_t) / 2, where AI is the statically configured single rate increase; if the smaller of T and BC is greater than F, then the excess active increase acceleration algorithm is executed: r_t = r_t + HAI, r_c = (r_c + r_t) / 2, where HAI is the statically configured single rate increase, and HAI > AI.

[0043] The acceleration / deceleration parameters for the standard DCQCN algorithm are listed in Table 1 below. These are all static configuration parameters and will not change automatically during algorithm operation once configured. As discussed above, events T and BC can independently facilitate the rapid recovery and active acceleration processes, respectively; they are decoupled. However, the Timer configuration for event T is constrained by the deceleration filtering threshold K, which cannot exceed the threshold; therefore, Timer > K.

[0044] Table 1. DCQCN Algorithm Acceleration / Deceleration Related Parameters

[0045] However, the standard DCQCN algorithm described above may have the following problems:

[0046] Configuring `rp_byte_reset` (i.e., the `ByteCounter` parameter) as a static parameter may lead to inappropriate rate-up. Unlike the `rp_time_reset` (Timer parameter), the setting of `rp_byte_reset` is not constrained by the rate-down parameter. Therefore, if `rp_byte_reset` is set too small, a contradictory situation may occur: within a period K (rp_rate_reduce_monitor_period), the rate is increased due to a BC event, but then a CNP event is received requiring rate-down. This repeated rate-up and rate-down within the same period K may persist, and congestion may not be effectively alleviated due to inappropriate rate-up, leading to algorithm failure.

[0047] Speed-up determination based on the static parameter configuration of `rp_time_reset` (Timer parameter) may lead to inappropriate speed-up. Although setting the `rp_time_reset` parameter to be greater than the K parameter will avoid the above problem, time-based speed-up determination can still cause inappropriate speed-up. This is because the current flow may be in a state of no traffic or only a small amount of traffic being sent. Therefore, the reason for not receiving a CNP within the `rp_time_reset` time is not that sending at the current rate will not cause congestion, but simply that the sending traffic is small: `r_c > ulp_flow_rate`, where `ulp_flow_rate` is the traffic supply rate of the upper-layer application.

[0048] The logical separation of rp_byte_reset and rp_time_reset parameter settings increases the difficulty of parameter tuning and reduces scalability. Although the standard DCQCN algorithm provides suggested values ​​for speed-up and speed-down configuration parameters, these values ​​need to be tuned separately under different network conditions (such as 25Gbps network cards and 200Gbps network cards) or service models. Moreover, the increase in the number of parameters exponentially increases the pressure on tuning complexity. The current dual-speed-up parameter configuration scheme is difficult to tune and has poor scalability.

[0049] To address the aforementioned technical issues, this application provides a method for determining acceleration logic. This method proposes an implicit acceleration determination mechanism based on the number of bytes sent and designs a dual-constraint acceleration determination strategy based on the coupling of time and the number of bytes sent.

[0050] The acceleration logic determination method provided in this application embodiment can be applied to the application environment shown in Figure 2. The data sender 102 communicates with the data receiver 104 via a network. Based on the current network speed and the T-event time period parameter, the data sender 102 obtains the expected number of bytes to be sent when the expected T-event is triggered. If the current number of bytes sent is greater than the expected number of bytes to be sent, the number of BC events is updated, where the current number of bytes sent is the number of bytes sent from the last update of the number of BC events to the current time. The acceleration logic is determined based on the relationship between the number of BC events and the acceleration state threshold. This coupling of the T-event time period parameter and the number of bytes sent, using dual constraints to determine the acceleration logic, avoids two types of improper acceleration: "too low a byte-to-send threshold" and "insufficient supply flow."

[0051] In an exemplary embodiment, as shown in FIG3, a method for determining acceleration logic is provided. Taking the application of this method to the data sender in FIG2 as an example, the method includes the following steps S302 to S304. Wherein:

[0052] S302: Based on the current network speed and the T event time period parameter, obtain the expected number of bytes to be sent when the expected T event is triggered.

[0053] The current network rate, denoted by r_c, is the rate at which the data sender is currently transmitting packets. The T-event time period parameter is rp_time_reset mentioned above.

[0054] Since the determination of whether event T has occurred is related to the time period parameter of event T, and whether event BC has occurred is related to the acceleration byte count threshold at the reaction point, i.e., the parameter rp_byte_reset, to avoid improper acceleration caused by independent acceleration determination of events T and BC, and to couple the parameters corresponding to events T and BC, the expected number of bytes to be sent when event T is triggered is introduced. Therefore, the value of expected_bytes_sent can be used to replace the static configuration parameter rp_byte_reset.

[0055] The expected number of bytes to be sent when event T is triggered is equal to the product of the current network rate and the time period parameter of event T, that is, expected_bytes_sent = r_c × rp_time_reset.

[0056] S304: If the number of bytes sent is greater than the expected number of bytes sent, update the number of BC events and execute the acceleration logic.

[0057] The current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time.

[0058] When the data sender detects that the number of bytes already sent exceeds the expected number of bytes to be sent (expected_bytes_sent), it executes the speed-up logic. In other words, if the expected_bytes_sent number of packets has been sent without receiving a CNP signal, it means that the current network rate of the current flow is not causing network congestion, and speed-up can be performed.

[0059] Since the update of the number of BC events already includes the constraints on the number of messages sent and the time constraint (because the expected number of bytes to be sent requires the T event time period parameter), the acceleration logic can be simplified to execute acceleration if the number of sent messages is greater than expected_bytes_sent (i.e., bytes_sent > r_c × rp_time_reset).

[0060] The advantages of `expected_bytes_sent` are: First, it eliminates the need for manually setting the byte count threshold, reducing the tedious parameter tuning process. Second, it is a dynamically changing value that adapts to the current flow's actual congestion. Third, it is constrained by the `rp_time_reset` parameter, preventing inappropriate rate increases during the rate-down detection period. Fourth, the `expected_bytes_sent` parameter explicitly expresses both the packet count constraint and implicitly includes the time constraint (i.e., `rp_time_reset`), thus, using this threshold naturally implements a dual-constraint rate-up decision strategy based on the coupling of time and packet count.

[0061] The above-described method for determining the acceleration logic is based on the current network rate and the T-event time period parameter to obtain the expected number of bytes to be sent when the T-event is triggered. In this way, if the current number of bytes sent is greater than the expected number of bytes to be sent, the acceleration logic is executed. The expected number of bytes to be sent is a value that changes dynamically with the current rate and can be adaptively adjusted according to the actual congestion situation of the current flow. By coupling the T-event time period parameter and the number of bytes to be sent, inappropriate acceleration caused by an excessively low threshold for the number of bytes to be sent can be effectively avoided.

[0062] In one optional embodiment, before executing the ramp-up logic, the method further includes: if the number of bytes sent is greater than the expected number of bytes sent, updating the number of BC events, wherein the current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time; and determining the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold.

[0063] If the number of bytes sent exceeds the expected number of bytes sent, a BC event is triggered, which updates the count of BC events. It's important to note that the current number of bytes sent is the number of bytes sent from the last update of the BC event count to the current time. Therefore, the current number of bytes sent must be reset after each update of the BC event count.

[0064] The acceleration logic is then determined based on the relationship between the number of BC events and the acceleration state threshold.

[0065] The acceleration state threshold, also known as F above, is the acceleration state threshold at the reaction point. The corresponding acceleration logic can be determined based on the relationship between the number of BC events and the acceleration state threshold. In this application, in order to achieve matching with the standard DCQCN algorithm, the acceleration logic of the three stages can be determined based on the relationship between the number of BC events and the acceleration state threshold.

[0066] In one optional embodiment, the acceleration logic is determined based on the relationship between the number of BC events and the acceleration state threshold, including: if the number of BC events is less than the acceleration state threshold, the acceleration logic is determined to be fast recovery logic, which is used to restore the network rate to the rate before the rate reduction.

[0067] In one optional embodiment, the acceleration logic is determined based on the relationship between the number of BC events and the acceleration state threshold, including: if the number of BC events is greater than or equal to the acceleration state threshold and less than or equal to the acceleration state threshold of the target multiple, the acceleration logic is determined to be an active increase logic; the active increase logic is used to detect the first available bandwidth.

[0068] In one optional embodiment, determining the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold further includes: determining the ramp-up logic as an over-proactive ramp-up logic when the number of BC events is greater than the ramp-up state threshold of the target multiple; the over-proactive ramp-up logic is used to detect a second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

[0069] The fast recovery logic restores the network speed to its pre-slowdown state. The excess proactive increase logic probes the first available bandwidth. The excess proactive increase logic probes the second available bandwidth, where the first available bandwidth is greater than the second available bandwidth.

[0070] The fast recovery logic, the proactive increase logic, and the excess proactive increase logic can increase the network rate linearly or non-linearly. Non-linear increase of the network rate can be obtained based on the acceleration curve of a convex function or based on the acceleration curve of a concave function.

[0071] For ease of understanding, the fast recovery logic, proactive increase logic, and excessive proactive increase logic in this application are explained using the linear increase of network speed as an example:

[0072] The fast recovery logic includes: calculating the first average rate of the current network rate and the target network rate, and using the first average rate as the new current network rate. That is, r_c = (r_c + r_t) / 2, where r_c is the current rate and r_t is the target rate.

[0073] The logic for proactively increasing the network rate beyond the initial target rate includes: updating the target network rate based on the configured first single-instance network rate increase to obtain the first target network rate; calculating the second average rate between the current network rate and the first target network rate; and using the second average rate as the new current network rate. That is, r_t = r_t + HAI, r_c = (r_c + r_t) / 2, where HAI is the statically configured single-instance rate increase, i.e., the first single-instance network rate increase, and HAI > AI.

[0074] The active increase logic includes: updating the target network rate based on the configured second single network rate increment to obtain a second target network rate, calculating a third average rate of the current network rate and the second target network rate, and using the third average rate as a new current network rate, wherein the second single network rate increment is less than the first single network rate increment. That is, r_t=r_t+AI, r_c=(r_c+r_t) / 2, and AI is a statically configured single rate increment, that is, the second single network rate increment.

[0075] In the present application, which rate increase logic to adopt can be determined based on the relationship between the number of occurred BC events and the rate increase state threshold. Specifically, when the number of occurred BC events is less than the rate increase state threshold, that is, when the BC value < F, the fast recovery logic is executed. When the number of occurred BC events is not less than the rate increase state threshold, it is further determined whether the number of occurred BC events is greater than the rate increase state threshold multiplied by a target multiple. For example, when the target multiple is 2, it is determined whether the BC value > 2F holds. If the BC value > 2F, the over-range active increase logic is executed; otherwise, the active increase logic is executed.

[0076] In summary, when the BC value < F, the fast recovery logic is executed; when the BC value > 2F, the over-range active increase logic is executed; when F < BC value < 2F, the active increase logic is executed.

[0077] The foregoing embodiment provides a method for determining a rate increase logic, and in other embodiments, other methods for determining a rate increase logic can be obtained based on the relationship between the number of occurred BC events and the rate increase state threshold, which is not specifically limited herein.

[0078] In an optional embodiment, the foregoing method further includes: waiting for a next rate increase logic determination process when the current number of transmitted bytes is less than or equal to the expected number of transmitted bytes.

[0079] In an optional embodiment, before obtaining the expected number of transmitted bytes when a T event is triggered based on the current network rate and a T event time period parameter, the method further includes: when no congestion notification packet is received after the time period corresponding to the T event time period parameter ends, continuing to perform the step of obtaining the expected number of transmitted bytes when the T event is triggered based on the current network rate and the T event time period parameter; and when a congestion notification packet is received after the time period corresponding to the T event time period parameter ends, resetting the number of occurred BC events and the current number of transmitted bytes.

[0080] Referring to FIG. 4, FIG. 4 is a schematic diagram of a three-stage rate-upgrading process of a rate-upgrading logic determining method in one embodiment. In this embodiment, after the data sender completes sending a specific packet, if no congestion notification packet is received when the time period corresponding to the T-event time period parameter expires, a rate-upgrading logic process is performed once.

[0081] First, check whether the current number of sent bytes (bytes_sent) is greater than the expected number of sent bytes (that is, expected_bytes_sent=r_c*rp_time_reset). If not, rate upgrading will not be performed, and the next processing, that is, the next rate-upgrading logic determination process will be waited for.

[0082] If the current number of sent bytes is greater than the expected number of sent bytes, the BC value is updated, that is, BC=BC+1, and the current number of sent bytes is reset, for example, set to 0. Then the rate-upgrading logic is determined based on the relationship between the BC value and F. Specifically, when the BC value < F, a fast recovery logic is executed; when the BC value > 2F, an excess active increase logic is executed; when F < BC value < 2F, an active increase logic is executed. And after the rate-upgrading logic is completed, the algorithm feeds back the indicated target network rate to the packet processing module.

[0083] When a congestion notification packet is received when the time period corresponding to the T-event time period parameter expires, the number of BC events that have occurred and the current number of sent bytes are reset. When a congestion notification packet is received, a rate reducing operation needs to be performed, and both the number of BC events that have occurred and the current number of sent bytes are set to 0.

[0084] The above rate-upgrading logic determining method does not require the rp_byte_reset parameter, reduces the number of parameters to be adjusted, greatly reduces the difficulty of parameter adjustment, enhances the scalability of parameter setting, and can be applied to multiple service models (such as different network card conditions, topologies, traffics, etc.). And a double-constraint rate-upgrading determination strategy coupled based on time and the number of sent bytes is realized. If only the time condition or the specific number-of-sent-bytes condition is satisfied, rate upgrading is not performed. Rate upgrading is executed only when both conditions are satisfied, which can effectively avoid two types of improper rate upgrading: too low sent byte threshold and too little supplied traffic.

[0085] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0086] Based on the same inventive concept, this application also provides an acceleration logic determination device for implementing the acceleration logic determination method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the acceleration logic determination device provided below can be found in the limitations of the acceleration logic determination method described above, and will not be repeated here.

[0087] In an exemplary embodiment, as shown in FIG5, an acceleration logic determination device is provided, including: an expected number of bytes to be sent calculation module 501 and an update module 502, wherein:

[0088] The expected number of bytes to be sent calculation module 501 is used to obtain the expected number of bytes to be sent when the expected T event is triggered, based on the current network rate and the T event time period parameter.

[0089] Update module 502 is used to execute speed-up logic when the number of bytes sent is greater than the expected number of bytes sent.

[0090] In one alternative embodiment, the above-described apparatus further includes:

[0091] Update module 502 is used to update the number of BC events when the current number of bytes sent is greater than the expected number of bytes sent. The current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time.

[0092] The ramp-up logic determination module is used to determine the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold.

[0093] In one optional embodiment, the above-mentioned speed-up logic determination module is specifically used to determine the speed-up logic as fast recovery logic when the number of BC events is less than the speed-up state threshold. The fast recovery logic is used to restore the network speed to the speed before the speed reduction.

[0094] In one optional embodiment, the above-mentioned speed-up logic determination module is specifically used to determine that the speed-up logic is active increase logic when the number of BC events is greater than or equal to the speed-up state threshold and less than or equal to the speed-up state threshold of the target multiple; the active increase logic is used to detect the first available bandwidth.

[0095] In one optional embodiment, the above-mentioned speed-up logic determination module is specifically used to determine that the speed-up logic is an over-proactive increase logic when the number of BC events is greater than the target multiple speed-up state threshold; the over-proactive increase logic is used to detect the second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

[0096] In one alternative embodiment, the above-described apparatus further includes:

[0097] The loop module is used to wait for the next speed-up logic determination process when the number of bytes sent is less than or equal to the expected number of bytes sent.

[0098] In one alternative embodiment, the above-described apparatus further includes:

[0099] The congestion assessment module is used to continue executing the step of obtaining the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter if no congestion notification message is received at the end of the time period corresponding to the T event time period parameter; and to reset the number of BC events and the current number of bytes sent if a congestion notification message is received at the end of the time period corresponding to the T event time period parameter.

[0100] Each module in the aforementioned acceleration logic determination device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0101] This application also provides a chip, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the above embodiments. The chip can be a data processing unit (DPU) chip, or other chips used for processing data.

[0102] This application also provides a network interface card, including the chip as described in any of the above embodiments and multiple interfaces. The interfaces may include I / O interfaces such as PCI / PCIE interfaces, UART / USB / I2C / SPI / GPIO, etc. The chip processes data or communicates externally through the interfaces.

[0103] In an exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as shown in Figure 6. The computer device includes a processor, memory, input / output interface, network interface card, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the network interface card, display unit, and input device are also connected to the system bus via the input / output interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The network interface card of the computer device is used for processing data or communicating with external terminals via wired or wireless means, such as Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an acceleration logic determination method. The display unit of the computer device is used to form a visually visible image and may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0104] Those skilled in the art will understand that the structure shown in Figure 6 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0105] In one exemplary embodiment, the computer device described in the above embodiments can be a data sender or a data receiver as shown in FIG2.

[0106] In one exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: obtaining the expected number of bytes to be sent when the expected event T is triggered based on the current network rate and the time period parameter of event T; and executing speed-up logic if the current number of bytes sent is greater than the expected number of bytes to be sent.

[0107] In one embodiment, before the processor executes the acceleration logic implemented when executing the computer program, the method further includes: updating the number of BC events if the current number of bytes sent is greater than the expected number of bytes sent, wherein the current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time; and determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold.

[0108] In one embodiment, the processor, when executing a computer program, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, including: if the number of BC events is less than the ramp-up state threshold, determining the ramp-up logic as fast recovery logic, the fast recovery logic being used to restore the network rate to the rate before the slowdown.

[0109] In one embodiment, the processor, when executing a computer program, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, including: determining the ramp-up logic as an active ramp-up logic when the number of BC events is greater than or equal to the ramp-up state threshold and less than or equal to a ramp-up state threshold of a target multiple; the active ramp-up logic is used to detect the first available bandwidth.

[0110] In one embodiment, the processor, when executing a computer program, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, further comprising: determining the ramp-up logic as an excess active ramp-up logic when the number of BC events is greater than the ramp-up state threshold of a target multiple; the excess active ramp-up logic is used to detect a second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

[0111] In one embodiment, before the processor executes the computer program to obtain the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter, the method further includes: if no congestion notification message is received at the end of the time period corresponding to the T event time period parameter, continuing to execute the step of obtaining the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter; and if a congestion notification message is received at the end of the time period corresponding to the T event time period parameter, resetting the number of BC events and the current number of bytes sent.

[0112] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, performs the following steps: obtaining the expected number of bytes to be sent when the expected event T is triggered based on the current network rate and the time period parameter of event T; and executing speed-up logic if the current number of bytes sent is greater than the expected number of bytes to be sent.

[0113] In one embodiment, before the execution of the acceleration logic implemented when the computer program is executed by the processor, the method further includes: updating the number of BC events if the current number of bytes sent is greater than the expected number of bytes sent, wherein the current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time; and determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold.

[0114] In one embodiment, when a computer program is executed by a processor, it determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, including: if the number of BC events is less than the ramp-up state threshold, determining the ramp-up logic as fast recovery logic, the fast recovery logic being used to restore the network rate to the rate before the slowdown.

[0115] In one embodiment, the computer program, when executed by the processor, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, including: determining the ramp-up logic as an active ramp-up logic when the number of BC events is greater than or equal to the ramp-up state threshold and less than or equal to the ramp-up state threshold of a target multiple; the active ramp-up logic is used to detect the first available bandwidth.

[0116] In one embodiment, the computer program, when executed by the processor, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, further comprising: determining the ramp-up logic as an excess active ramp-up logic when the number of BC events is greater than the ramp-up state threshold of a target multiple; the excess active ramp-up logic is used to detect a second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

[0117] In one embodiment, before the computer program, when executed by the processor, calculates the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter, the method further includes: if no congestion notification message is received at the end of the time period corresponding to the T event time period parameter, continuing to execute the step of calculating the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter; and if a congestion notification message is received at the end of the time period corresponding to the T event time period parameter, resetting the number of BC events and the current number of bytes sent.

[0118] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps: obtaining the expected number of bytes to be sent when the expected event T is triggered, based on the current network rate and the event T time period parameter; and executing speed-up logic if the current number of bytes sent is greater than the expected number of bytes to be sent.

[0119] In one embodiment, before the execution of the acceleration logic implemented when the computer program is executed by the processor, the method further includes: updating the number of BC events if the current number of bytes sent is greater than the expected number of bytes sent, wherein the current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time; and determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold.

[0120] In one embodiment, when a computer program is executed by a processor, it determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, including: if the number of BC events is less than the ramp-up state threshold, determining the ramp-up logic as fast recovery logic, the fast recovery logic being used to restore the network rate to the rate before the slowdown.

[0121] In one embodiment, the computer program, when executed by the processor, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, including: determining the ramp-up logic as an active ramp-up logic when the number of BC events is greater than or equal to the ramp-up state threshold and less than or equal to the ramp-up state threshold of a target multiple; the active ramp-up logic is used to detect the first available bandwidth.

[0122] In one embodiment, the computer program, when executed by the processor, determines the ramp-up logic based on the relationship between the number of BC events and the ramp-up state threshold, further comprising: determining the ramp-up logic as an excess active ramp-up logic when the number of BC events is greater than the ramp-up state threshold of a target multiple; the excess active ramp-up logic is used to detect a second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

[0123] In one embodiment, before the computer program, when executed by the processor, calculates the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter, the method further includes: if no congestion notification message is received at the end of the time period corresponding to the T event time period parameter, continuing to execute the step of calculating the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter; and if a congestion notification message is received at the end of the time period corresponding to the T event time period parameter, resetting the number of BC events and the current number of bytes sent.

[0124] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant regulations. The computer programs mentioned above can be computer-readable instructions.

[0125] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0126] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0127] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for determining acceleration logic, wherein, The method includes: Based on the current network speed and the T event time period parameter, the expected number of bytes to be sent when the expected T event is triggered is obtained; If the number of bytes already sent is greater than the expected number of bytes to be sent, execute the speed-up logic.

2. The method of claim 1, wherein, Before executing the acceleration logic, the following is also included: If the number of bytes sent is greater than the expected number of bytes to be sent, update the number of BC events, where the current number of bytes sent is the number of bytes sent from the last update time of the number of BC events to the current time. The acceleration logic is determined based on the relationship between the number of BC events and the acceleration state threshold.

3. The method of claim 2, wherein, The determination of the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold includes: If the number of BC events is less than the speed-up state threshold, the speed-up logic is determined to be fast recovery logic, which is used to restore the network speed to the speed before the speed-down.

4. The method of claim 2, wherein, The determination of the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold includes: If the number of BC events is greater than or equal to the acceleration state threshold and less than or equal to the acceleration state threshold of the target multiple, the acceleration logic is determined to be active increase logic; the active increase logic is used to detect the first available bandwidth.

5. The method of claim 4, wherein, The method for determining the acceleration logic based on the relationship between the number of BC events and the acceleration state threshold also includes: If the number of BC events is greater than the target multiple of the acceleration state threshold, the acceleration logic is determined to be an over-proactive increase logic; the over-proactive increase logic is used to detect a second available bandwidth, and the second available bandwidth is greater than the first available bandwidth.

6. The method of any one of claims 2 to 4, wherein, Before obtaining the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter, the method further includes: If no congestion notification message is received by the end of the time period corresponding to the T event time period parameter, continue to execute the step of obtaining the expected number of bytes to be sent when the expected T event is triggered based on the current network rate and the T event time period parameter. If a congestion notification message is received at the end of the time period corresponding to the T event time period parameter, the number of BC events and the number of bytes currently sent are reset.

7. A speed-up logic determination apparatus, wherein, The device includes: The expected number of bytes to be sent module is used to obtain the expected number of bytes to be sent when the expected event T is triggered, based on the current network rate and the time period parameter of event T. The update module is used to execute acceleration logic when the number of bytes already sent is greater than the expected number of bytes to be sent.

8. A chip comprising a memory and a processor, the memory storing a computer program, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A network interface card, wherein, It includes the chip as described in claim 8 and multiple interfaces, wherein the chip processes data or communicates externally through the interfaces.

10. A computer device, wherein, Includes the network interface card as described in claim 9, wherein the network interface card is used for processing data or external communication.

11. A computer readable storage medium having stored thereon a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

12. A computer program product comprising a computer program, wherein, The computer program, which is executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

Images