A flow control method, electronic device, storage medium and program product

Abstract

This application provides a flow control method, an artificial intelligence distributed training method, an electronic device, a storage medium, and a program product. The method includes: acquiring traffic characteristic information of a data stream to be transmitted sent by an application layer program; generating corresponding flow table rules based on the traffic characteristic information; pre-configuring the flow table rules to a network device and controlling the flow table rules to be in an inactive dormant state; upon receiving a trigger signal sent by the application layer program, sending a control command to the network device to switch the flow table rules to an active state, so that the data stream to be transmitted is transmitted via a target path based on the active flow table rules; the trigger signal is used to instruct the data stream to be transmitted to start transmission. This avoids the problem of repeated PFC oscillations caused by switch buffer congestion due to sudden large traffic flows in traditional RoCE networks, enabling large data streams to be transmitted at a stable rate close to line speed.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and more specifically, to a flow control method, electronic device, storage medium, and program product. Background Technology

[0002] In distributed AI training (such as All-Reduce operations), nodes need to synchronize huge gradient parameters, resulting in a persistent "elephant flow".

[0003] Currently, RoCE-based networks rely on Priority Flow Control (PFC) to ensure lossless transmission. However, PFC is a coarse-grained, binary link-layer backpressure mechanism: when a switch buffer is full, a Pause frame is sent to suspend upstream traffic; it resumes when the buffer is cleared. This "either / or" switching control, when faced with persistent and bandwidth-intensive heavy traffic, causes link utilization to oscillate violently and repeatedly between zero and line speed. This oscillation prevents heavy traffic from smoothly and stably occupying bandwidth, thereby increasing transmission latency and tail latency, and reducing AI training efficiency.

[0004] Currently, there is a lack of solutions in related technologies that can dynamically establish a protected channel for persistent elephant streams based on application-layer predictions before data transmission begins, thereby fundamentally avoiding network congestion and PFC triggering. In other words, in RoCE networks, how to solve the problem of repeated PFC oscillations caused by persistent elephant streams to achieve stable, high-bandwidth, and low-latency data transmission is an urgent issue to be addressed. Summary of the Invention

[0005] The purpose of this application is to provide a flow control method, an artificial intelligence distributed training method, an electronic device, a storage medium, and a program product, so as to avoid repeated PFC oscillations caused by persistent elephant flows, thereby providing stable and deterministic high-bandwidth and low-latency data transmission for high-bandwidth applications such as AI training, and improving the overall utilization efficiency of network resources.

[0006] A first aspect of this application provides a flow control method, the method comprising: Obtain the traffic characteristics information of the data stream to be transmitted sent by the application layer program; Based on the traffic characteristic information, corresponding flow table rules are generated; The flow table rules are pre-configured to the network device, and the flow table rules are controlled to be in an inactive dormant state. Upon receiving a trigger signal from the application layer program, a control command is sent to the network device to switch the flow table rule to an active state, so that the data stream to be transmitted is transmitted via the target path based on the active flow table rule; the trigger signal is used to instruct the data stream to be transmitted to start transmission.

[0007] In the above implementation process, by introducing a "pre-configuration, post-triggering, dynamic activation" mechanism, the application layer's prediction of communication patterns is combined with the precise network control capabilities of SDN. This allows for the pre-establishment and reservation of a dedicated logical channel with guaranteed resources in the network before the transmission of high-bandwidth, low-latency "elephant streams" (such as AI gradient synchronization) begins, and microsecond-level instantaneous switching is achieved through application layer events. This avoids the PFC (Potential Frequency Congestion) oscillation problem caused by switch buffer congestion due to sudden large traffic flows in traditional RoCE networks. It enables "elephant streams" to transmit at a stable rate close to line speed, reducing communication latency and jitter (tail latency), thereby improving the iterative efficiency of high-performance computing tasks such as AI training, and simultaneously enhancing the overall utilization efficiency of network resources.

[0008] Furthermore, the control flow table rule being in an inactive dormant state and the flow table rule being switched to an active state are achieved by operating the flow table group in the ingress network device of the data flow to be transmitted; The pre-configured flow table group includes at least a first action bucket and a second action bucket. The first action bucket is associated with the target path and is configured to be initially inactive to form the dormant state. The second action bucket is associated with the default path and is configured to be initially active. The second action bucket is used to forward the data stream to be transmitted in the dormant state. The control command is used to instruct the modification of the configuration of the flow table group so that the first action bucket is activated.

[0009] In the above implementation process, the complex end-to-end path switching is simplified into a quick modification of the configuration of a single set of tables on the ingress device, thereby improving switching speed and reliability.

[0010] Furthermore, the control command carries an identifier of the flow table group and updated configuration information including the first action bucket, for instructing the effective action bucket in the flow table group to be switched from the second action bucket to the first action bucket according to the updated configuration information of the first action bucket.

[0011] In the above implementation process, by specifying the control command as a direct switching operation between the preset first action bucket and the second action bucket, the instantaneous change of the flow table rule state is realized, which provides a guarantee for eliminating PFC oscillation.

[0012] Furthermore, the traffic characteristic information includes the identifier of the data stream to be transmitted, the expected data volume, and the bandwidth requirement information; The step of generating corresponding flow table rules based on the traffic feature information includes: The start and end points of the data stream to be transmitted are determined based on the identifier; If the data stream to be transmitted is determined to be an elephant stream that needs to be scheduled based on the expected data volume, the target path is determined for the data stream to be transmitted and the corresponding bandwidth quota is allocated based on the bandwidth requirement information.

[0013] In the above implementation process, the traffic characteristics information, such as the identifier of the data stream to be transmitted, the expected data volume, and the bandwidth requirement information, together constitute a network resource reservation list. This enables the SDN controller to: accurately locate communication entities; proactively identify high-impact flows (i.e., elephant flows); plan feasible paths that meet service quality requirements in advance; and accurately reserve necessary bandwidth resources. This achieves a shift from passively responding to real-time network congestion to proactively configuring the network based on application-predicted needs.

[0014] Furthermore, the step of generating corresponding flow table rules based on the flow characteristic information includes: Based on the traffic characteristic information, the target path is calculated for the data stream to be transmitted, and dedicated queue resources and bandwidth quotas are allocated for the target path; Generate flow table rules for directing the data stream to be transmitted to the target path and dedicated queue.

[0015] In the above implementation process, from the perspective of network resource allocation, the bandwidth requirements of the application layer are mapped to an executable, resource-reserved forwarding strategy in the data plane. This fundamentally eliminates the competition between the target data stream and background traffic in the buffer and link bandwidth, thereby avoiding the conditions for triggering PFC. Moreover, through dedicated queues and bandwidth quotas, it provides a guarantee for achieving deterministic transmission with extremely low jitter.

[0016] Further, calculating the target path for the data stream to be transmitted based on the traffic characteristic information includes: Based on the global network topology and real-time link status information maintained by the software-defined network controller, an end-to-end explicit forwarding path is calculated for the data stream to be transmitted.

[0017] In the above implementation process, firstly, computation based on a global view avoids suboptimal decisions and potential congestion caused by local optimization, enabling the selection of truly efficient channels for large data flows from a network-wide perspective. Secondly, the use of explicit paths eliminates path jitter and other problems that may occur in traditional distributed routing protocols when dealing with large data flows, ensuring the stability of the transmission process.

[0018] Furthermore, the flow control method further includes: Upon receiving a signal from the application layer program indicating the end of the transmission of the data stream to be transmitted, the system controls the data stream to resume transmission via the default path and releases the network resources occupied by the target path.

[0019] In the above implementation process, on-demand occupation and timely reclamation of network resources are realized, avoiding long-term vacancy of dedicated channels after the flow ends, and improving the overall utilization rate of network resources.

[0020] Furthermore, the application layer program is an artificial intelligence distributed training framework, and the data stream to be transmitted is the gradient synchronization stream generated by the artificial intelligence distributed training framework during the training process.

[0021] The above implementation process provides a zero-congestion, zero-oscillation network transmission guarantee mechanism for the periodic and predictable synchronization of massive data in AI training. This transforms the originally uncontrollable communication delays affected by PFC oscillations into deterministic, optimal network transmission times, thereby shortening the cycle of each training iteration, accelerating model convergence, and improving the utilization efficiency of AI computing clusters.

[0022] Furthermore, the data stream to be transmitted is a remote direct memory access data stream transmitted in a lossless network environment.

[0023] In the above implementation process, by introducing predictive and resource-guaranteed scheduling into the lossless network, RDMA elephant streams can fully enjoy the benefits of zero packet loss without triggering PFC oscillations, thereby stably reaching the theoretical performance peak of the protocol.

[0024] A second aspect of this application provides a flow control method, the method comprising: During the training iteration cycle of the neural network model, local gradient calculations are performed in parallel on multiple computing nodes. Before the local gradient calculation is completed, the control training framework sends the flow characteristic information of the gradient data stream to be synchronized in the current iteration to the software-defined network controller; Once the local gradient calculation is completed, the training framework is controlled to send a trigger signal to the software-defined network controller. The software-defined network controller is controlled to respond to the trigger signal and activate the configured flow table rules so that the gradient data stream is synchronously transmitted through the target path; The parameters of the neural network model are updated based on the gradient data that has been synchronously transmitted.

[0025] In the above implementation process, zero-wait and zero-oscillation gradient synchronization communication was achieved. By reserving network resources in parallel during the computation phase and activating the dedicated channel instantaneously upon completion of the computation, the originally unpredictable large-scale gradient synchronization time, which was severely affected by network congestion and PFC, was transformed into a deterministic, near-linear-speed optimal transmission time. This shortened the cycle of each training iteration, thereby significantly accelerating the overall model convergence process.

[0026] A third aspect of this application provides an electronic device, the electronic device comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements either the method described in the first aspect or the method described in the second aspect.

[0027] A fourth aspect of this application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect or the steps of the methods described in the second aspect.

[0028] A fifth aspect of this application provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the methods described in the first aspect or implements the methods described in the second aspect. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating a flow control method provided in an embodiment of this application; Figure 2 A schematic diagram of an overall process provided for an embodiment of this application; Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0032] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0033] To address any of the problems raised above, embodiments of this application provide a flow control method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a flow control method provided in an embodiment of this application.

[0034] In this embodiment, the method includes: Step S10: Obtain the traffic characteristic information of the data stream to be transmitted sent by the application layer program; It should be noted that this embodiment is applied to a distributed AI training scenario, and its network foundation is a lossless Ethernet built on the RoCEv2 protocol, and an SDN controller (such as one based on the OpenFlow protocol) is deployed to centrally control the network.

[0035] The SDN controller receives a traffic registration request from the AI ​​training task management framework (i.e., the application layer program). This request contains predictive traffic characteristics of the upcoming gradient synchronization operation (i.e., the "elephant flow"). These traffic characteristics are prior knowledge and include, but are not limited to: Flow identifier: A five-tuple including source and destination IP addresses (or RoCE's GID), protocol port, etc., used to uniquely identify the data flow; Transmission requirements: Expected total data volume and required bandwidth guarantee; Timing information: The expected start time of communication, or a trigger signal identifier defined by the training framework, enables predictive collaboration between the application layer and the network controller.

[0036] Step S20: Generate corresponding flow table rules based on the traffic characteristic information; For example, the SDN controller performs policy calculations based on the received traffic characteristic information: Path and resource computation: Based on the global network topology and current link status, calculate the optimal explicit path from the source node to the destination node as the target path. Simultaneously, allocate a dedicated logical queue and reserve corresponding bandwidth quotas for key nodes along this path to ensure resource availability.

[0037] Flow table rule generation: Generates specific, deployable flow table rules. This set of rules is cross-switch and includes: Ingress label rules (anchor flow table): Deployed on the traffic ingress switch to match the five-tuple of elephant flow, the action is to add an internal label (such as a specific VLAN ID) to it. Path forwarding rules (dormant flow tables): Deployed on all switches along the target path, matching the internal tags mentioned above, the action is to point to the predetermined outgoing port. These rules are marked or configured to be inactive initially when generated, i.e., in a dormant state, to achieve "pre-configuration" without immediately affecting existing traffic.

[0038] Step S30: Pre-configure the flow table rules to the network device and control the flow table rules to be in an inactive dormant state; It should be noted that the SDN controller distributes the generated flow table rules to the relevant switches. The key focus is on the state management of these rules: The flow tables of the ingress switch are organized into a multi-level pipeline. For example, the anchor flow table described above is set in Table 0, with actions pointing to Table 1. In Table 1, a flow table group is set up, containing two action buckets: Bucket 1 (the first action bucket) is associated with actions pointing to the target path and dedicated queues (e.g., adding an internal label and forwarding, i.e., adding a specific internal label to push_vlan and then outputting to the specified port), and Bucket 2 (the second action bucket) is associated with actions of the default forwarding path (e.g., directly outputting to a regular forwarding port). By configuring initial weights or activation states, Bucket 1 (the dedicated channel for elephant flows) can be disabled, while Bucket 2 (the default channel) can be enabled. For example, if the flow table group type is "SELECT", then a weight of 0 is set for Bucket 1, and a non-zero weight (e.g., 1) is set for Bucket 2. According to the OpenFlow protocol specification, buckets with a weight of 0 will not be selected for forwarding, thus ensuring that traffic is forwarded only through Bucket 2. For example, if the switch supports this, by setting the bucket status flag, Bucket 1 can be marked as standby or inactive, while Bucket 2 can be marked as active. In this way, even if the flow table is pre-configured, the data flow will still default to the normal path, while the dedicated path will be in a "standby" state.

[0039] Although the forwarding rules of the transit and exit switches on the path have been issued, the matching internal tag data packets have not yet appeared, so they are not actually triggered.

[0040] Step S40: Upon receiving a trigger signal from the application layer program, a control command is sent to the network device to switch the flow table rule to an active state, so that the data stream to be transmitted is transmitted via the target path based on the active flow table rule; the trigger signal is used to instruct the data stream to be transmitted to start transmission.

[0041] It's important to note that when the AI ​​training framework reaches the step requiring gradient synchronization, it sends a trigger signal to the SDN controller. The SDN controller then sends an extremely fast control command to the ingress switch. This command is a group table modification message (e.g., the OFPGC_MODIFY command in the OpenFlow protocol), which modifies the pre-defined flow group configuration, for example, switching the effective bucket from Bucket 2 to Bucket 1. This operation is completed within microseconds, directing all subsequent arriving elephant flow packets matching the anchor flow table to the pre-defined, resource-guaranteed target path for transmission.

[0042] After the trigger command takes effect, the data packets of the elephant stream are internally tagged at the ingress switch and transmitted stably and efficiently to their destination in a dedicated queue according to the pre-configured and now "activated" path forwarding rules along the route. Because the path is pre-calculated and resources are guaranteed, it avoids competing for buffers with other traffic, thus avoiding triggering the PFC mechanism and achieving stable, high-bandwidth transmission.

[0043] It should be understood that the internal forwarding label is a temporary identifier used within the controlled network. When a data packet carrying this label is forwarded to the egress network device (i.e., the last-hop switch) connected to the destination compute node, the flow table rules pre-configured on that device include an action to remove the internal label (e.g., the pop_vlan action in OpenFlow). Subsequently, the data packet is delivered to the destination host's network interface card in its original format. In this way, the internal label is only valid during network transmission and is completely transparent to the host at the communication endpoint, ensuring the integrity of end-to-end forwarding.

[0044] In this embodiment, by introducing a "pre-configuration, post-triggering, dynamic activation" mechanism, the application layer's prediction of communication patterns is combined with the precise network control capabilities of SDN. This allows for the pre-establishment and reservation of a dedicated logical channel with guaranteed resources in the network before the transmission of high-bandwidth, low-latency "elephant streams" (such as AI gradient synchronization) begins, and microsecond-level instantaneous switching is achieved through application layer events. This avoids the PFC (Potential Frequency Congestion) oscillation problem caused by switch buffer congestion due to sudden large traffic flows in traditional RoCE networks. It enables "elephant streams" to transmit at a stable rate close to line speed, reducing communication latency and jitter (tail latency), thereby improving the iterative efficiency of high-performance computing tasks such as AI training, and simultaneously enhancing the overall utilization efficiency of network resources.

[0045] Based on any of the above embodiments, the control flow table rule being in an inactive dormant state and the flow table rule being switched to an active state are achieved by operating the flow table group in the ingress network device of the data stream to be transmitted; The pre-configured flow table group includes at least a first action bucket and a second action bucket. The first action bucket is associated with the target path and is configured to be initially inactive to form the dormant state. The second action bucket is associated with the default path and is configured to be initially active. The second action bucket is used to forward the data stream to be transmitted in the dormant state. The control command is used to instruct the modification of the configuration of the flow table group so that the first action bucket is activated.

[0046] It should be noted that the method described in this embodiment is applicable to SDN switches that support programmable flow table protocols (such as OpenFlow).

[0047] The default path refers to the regular network forwarding path followed by the data stream when a pre-configured dedicated scheduling policy for the data stream to be transmitted is not enabled. The default path can be established in ways including, but not limited to, any of the following: Based on existing routing protocols: the shortest path calculated by network devices based on traditional distributed routing protocols (such as OSPF and BGP); Based on the basic SDN flow table: the path defined by the general forwarding rules uniformly planned and issued by the SDN controller for the entire network traffic, such as distributing traffic to multiple links through equal cost multipath (ECMP) hashing; The switch's default forwarding behavior is to perform autonomous forwarding based on its MAC address table or IP routing table when no specific flow table rule is matched.

[0048] It should be understood that, in this embodiment, the second action bucket is associated with the forwarding action of the default path (e.g., outputting to the corresponding port implementing the default forwarding). By configuring the second action bucket to be initially active, it is ensured that the data stream to be transmitted can still be transmitted through the network's regular forwarding mechanism during the dormant state, thereby maintaining the continuity of network services. When the dedicated channel is activated (i.e., the first action bucket is active), the data stream will be switched to a target path with resource guarantees.

[0049] A flow table group (also called a group table) is an advanced flow table structure in SDN switches used to group multiple forwarding actions into a single logical unit. A flow table group contains one or more action buckets. Each bucket contains a set of ordered action instructions (such as modifying the packet header, outputting to a specified port, etc.). When a flow table entry matches and executes the "Group:<group ID>" action, it triggers the execution of one or more buckets in the specified flow table group. By configuring the bucket's weight, selection type, or activation status, the specific processing logic of the data packets can be controlled.

[0050] During the pre-configuration phase, the SDN controller creates and configures a specific flow table group (e.g., Group ID 100) on the switch that serves as the ingress network device for the data flow to be transmitted. This flow table group contains at least two action buckets: The first action bucket: its action sequence is associated with the pre-calculated target path of the data flow. Specific actions may include: adding an internal forwarding tag to the data packet (e.g., setting the VLAN ID to 200), implementing bandwidth protection through the meter, and outputting to a designated port on the target path. The controller initially disables this bucket by setting initial parameters (e.g., resetting the weight to 0, or marking it as "inactive" in the corresponding group type), thereby forming the dormant state; The second action bucket: its action sequence is associated with the default path, such as direct output to a regular forwarding port. This bucket is configured as the initially effective bucket.

[0051] Meanwhile, the controller pre-configures flow table entries matching the aforementioned internal tags along the target path (including core and egress switches), with the action pointing to the corresponding egress port. These flow table entries constitute a complete forwarding pipeline, and their state coordinates with the ingress flow table group, remaining in a "standby" state before triggering.

[0052] When the SDN controller receives a trigger signal from the application layer program, it generates a control command. This command is used to modify the configuration of a specified flow table group on the ingress network device.

[0053] The controller sends this control command to the ingress switch. Taking the OpenFlow protocol as an example, this command is a group table modification message. Its core content is to modify the activation relationship of action buckets within the flow table group, such as disabling the second action bucket and activating the first action bucket.

[0054] After the switch executes the command, its internal forwarding logic is updated instantly. Subsequently, packets matching the ingress flow table are processed by the first action bucket, tagged internally, and sent to the target path. Switches along the route relay the packets according to pre-defined tag matching rules, thus achieving a fast and seamless switchover of data flow from the default path to the reserved path.

[0055] In this embodiment, the complex end-to-end path switching is simplified into a quick modification of a single set of table configurations for the ingress device, thereby improving switching speed and reliability.

[0056] Based on any of the above embodiments, the control command carries an identifier of the flow table group and updated configuration information including the first action bucket, for instructing the effective action bucket in the flow table group to be switched from the second action bucket to the first action bucket according to the updated configuration information of the first action bucket.

[0057] It should be noted that, in this embodiment, control commands specifically refer to signaling messages transmitted between the controller and the switch via the southbound interface protocol in a software-defined networking (SDN) architecture, which are used to manage and configure the forwarding behavior of the switch, i.e., protocol control messages.

[0058] Specifically, after the SDN controller receives a trigger signal from the AI ​​training framework, it generates a specific control command. This command is a protocol control message conforming to the southbound interface protocol specification, used to modify the existing configuration of the switch. Taking the OpenFlow protocol as an example, this message is a GroupModification Message of type OFPGC_MODIFY. This message is a structured protocol data unit, and its key fields include, but are not limited to: Command type: Set to MODIFY to instruct the switch to update existing group table entries; Group identifier: Specifies the ID of the flow table group to be modified (e.g., GROUP_ID=100), which is the identifier of the flow table group; Bucket List: Carries updated configuration information for the first action bucket. In this scenario, this list primarily contains the updated configuration of the first action bucket (Bucket 1), such as adjusting its weight from 0 to an effective value (or setting its status flag from "inactive" to "active"), used to indicate switching the effective bucket to the first action bucket. Simultaneously, this list may contain corresponding updates for the second action bucket (Bucket 2), or implicitly change it to an inactive state based on protocol logic.

[0059] The SDN controller sends this group table modification message to the ingress switch via a secure channel (such as a TLS connection). The switch's protocol agent receives and parses the message, verifies its validity, locates the target flow table group based on the group identifier in the message, and instantly reconstructs its internal logic according to the updated configuration information.

[0060] The result of this execution is that the runtime configuration of the flow table group (Group 100) is updated. The previously inactive first action bucket is activated and becomes the active bucket; the previously active second action bucket is set to inactive. This is the process of switching the active action bucket in the flow table group from the second action bucket to the first action bucket. Afterwards, packets that match the relevant flow table entries will be processed by the active first action bucket and thus guided to the target path.

[0061] In this embodiment, by specifying the control command as a direct switching operation between the preset first action bucket and the second action bucket, the instantaneous change of the flow table rule state is realized, which provides a guarantee for eliminating PFC oscillation.

[0062] Based on any of the above embodiments, the traffic characteristic information includes the identifier of the data stream to be transmitted, the expected data volume, and the bandwidth requirement information; The step of generating corresponding flow table rules based on the traffic feature information includes: The start and end points of the data stream to be transmitted are determined based on the identifier; If the data stream to be transmitted is determined to be an elephant stream that needs to be scheduled based on the expected data volume, the target path is determined for the data stream to be transmitted and the corresponding bandwidth quota is allocated based on the bandwidth requirement information.

[0063] Optionally, the traffic characteristic information includes at least one of the following: the identifier of the data stream to be transmitted, the expected data volume, the communication start indication information, and the bandwidth requirement information.

[0064] It should be noted that traffic characteristic information refers to a set of prior knowledge about an upcoming data stream that is proactively provided to the network controller by the application layer (such as an AI training framework). This differs from real-time traffic characteristics obtained through network probing; rather, it is a predictive description based on application logic and serves as a crucial input for achieving cross-layer collaboration and proactive network planning.

[0065] Specifically, the SDN controller receives a registration request from an application layer program (such as an AI training framework). This request encapsulates traffic characteristics information about an upcoming data stream to be transmitted. This information is known in advance by the application according to its own logic.

[0066] Data stream identifier: Used to uniquely identify the data stream within the network. In AI distributed training scenarios, the data stream identifier includes a 5-tuple for gradient synchronization, comprising the source IP address, destination IP address (or RoCE's GID), transport layer protocol, and port number. In specific implementations, the data stream identifier includes the stream ID, source / destination IP address (or GID), and protocol port.

[0067] Expected data volume: An estimate of the total amount of data to be transferred. For example, in AI training, this corresponds to the total size of gradient parameters that need to be synchronized in a single All-Reduce operation.

[0068] Communication initiation indication information: Used to inform the controller when to activate reserved resources. This can be a future timestamp or a logical event identifier defined by the application (i.e., a preview of the "trigger signal").

[0069] Bandwidth requirement information: The minimum or expected bandwidth required for this data stream to meet its performance objectives (such as completion time requirements).

[0070] Specifically, the SDN controller parses and utilizes the aforementioned traffic characteristic information to perform resource planning and rule generation processes: Endpoint location and flow identification: The controller determines the start and end endpoints (source node and destination node) of the data flow based on the data flow identifier, thereby locating the start and end positions of its communication path in the global network topology; Elephant Flow Determination and Scheduling Trigger: Based on the expected data volume, the controller determines whether the flow belongs to an "elephant flow" that requires a dedicated scheduling strategy. For example, if the expected data volume exceeds a preset threshold, it is determined to be an "elephant flow," triggering the subsequent dedicated resource planning process. Path calculation and resource reservation: After determining that scheduling is required, the controller combines the bandwidth demand information with its real-time maintained global network topology and link status to execute a path calculation algorithm. The goal is to determine an end-to-end target path that can meet the bandwidth requirements of the data flow and allocate corresponding bandwidth quotas at the key nodes of this path (e.g., by configuring the weights of Meters or dedicated queues).

[0071] Through the above steps, the controller transforms the application's performance requirements (data volume, bandwidth) and communication constraints (start and end points, time) into flow table rules, including entry rules for identifying and marking data flows, and forwarding rules for guiding and guaranteeing bandwidth on dedicated paths.

[0072] In this embodiment, the traffic characteristics information, including the identifier of the data stream to be transmitted, the expected data volume, and the bandwidth requirement, collectively constitute a network resource reservation form. This enables the SDN controller to: ① accurately locate communication entities; ② proactively identify high-impact flows (i.e., elephant flows); ③ plan feasible paths to meet service quality requirements in advance; and ④ accurately reserve necessary bandwidth resources. This achieves a shift from passively responding to real-time network congestion to proactively configuring the network based on application-predicted needs.

[0073] Based on any of the above embodiments, the step of generating corresponding flow table rules based on the traffic feature information includes: Based on the traffic characteristic information, the target path is calculated for the data stream to be transmitted, and dedicated queue resources and bandwidth quotas are allocated for the target path; Generate flow table rules for directing the data stream to be transmitted to the target path and dedicated queue.

[0074] Specifically, based on the traffic characteristic information, and in conjunction with its maintained global network topology and real-time link status (such as available bandwidth), the controller runs a path calculation algorithm. Its goal is to calculate an optimal explicit path from source to destination for the data stream to be transmitted. This path is deterministic and pre-planned, rather than relying on runtime dynamic routing.

[0075] To ensure transmission quality along the target path, the controller, while calculating the path, assigns a logically unique queue identifier (e.g., a specific priority queue or physical queue) to critical nodes along the path (such as ingress and core switches). Simultaneously, based on bandwidth requirements from traffic characteristics, it sets a specific bandwidth quota for this queue (e.g., by configuring the switch's Meter or the weight of the priority queue). This effectively isolates a portion of guaranteed resources from shared network physical resources for this transmission.

[0076] Based on the above calculations, the controller generates a specific, deployable set of flow table rules. These rules are used to precisely guide data flows to preset target paths and direct them into dedicated queues for transmission. The generated rules mainly fall into two categories: ① Ingress Classification and Tagging Rules (Anchor Flow Table): Flow table entries are generated on the ingress switch, matching the five-tuple (part of the traffic characteristic information) of the data flow. The action is to add an internal tag (such as a specific VLAN ID) to the data packet, which implicitly contains path and queue affiliation information. Simultaneously, the ingress rule also includes actions pointing to the next processing step (such as a specific flow table group); ② Path Forwarding and Queue Selection Rules: Flow table entries are generated on switches along the target path. These rules match the internal tags mentioned above, and their actions consist of two key parts: Forwarding action: output to the next hop port of the calculated target path. Queue selection action: send the packet to the dedicated queue allocated for this flow (e.g., by setting the packet's QoS field or directly specifying the egress queue). For switches that support bandwidth guarantees, a meter action can also be associated to enforce bandwidth quotas.

[0077] Understandably, the target path, a pre-calculated, end-to-end forwarding route for a specific data flow based on the global network view, is a logically "dedicated channel".

[0078] Dedicated queue resources and bandwidth quotas: To ensure the performance of this data stream, queuing resources and bandwidth limits are logically reserved on network devices to avoid competition with other traffic and ensure deterministic transmission and low latency.

[0079] In this embodiment, from the perspective of network resource allocation, the bandwidth requirements of the application layer are mapped to a data plane executable, resource-reserved forwarding strategy. This fundamentally eliminates the competition between the target data stream and background traffic in the buffer and link bandwidth, thereby avoiding the conditions for triggering PFC. Moreover, through dedicated queues and bandwidth quotas, it provides a guarantee for achieving deterministic transmission with extremely low jitter.

[0080] Based on any of the above embodiments, the step of calculating the target path for the data stream to be transmitted according to the traffic characteristic information includes: Based on the global network topology and real-time link status information maintained by the software-defined network controller, an end-to-end explicit forwarding path is calculated for the data stream to be transmitted.

[0081] It should be noted that the global network topology is a complete map that is automatically discovered by the SDN controller through mechanisms such as LLDP (Link Layer Discovery Protocol) or predefined by the administrator, covering all switches (such as Spine and Leaf) in the network and the connections between them.

[0082] Link status: refers to the real-time dynamic information of each physical link in the network, including available bandwidth, and may also include latency, packet loss rate, etc. The SDN controller continuously collects this information through southbound interfaces (such as OpenFlow's Port-Status messages) or monitoring tools (such as sFlow).

[0083] Explicit path: also known as source routing path or engineered path, refers to the complete route for each hop forwarding node (i.e., switch) and outgoing port pre-specified by the SDN controller, and the data flow is forced to travel along this path by issuing flow table rules hop by hop. It is fundamentally different from the "hop-by-hop routing" in traditional networks that relies on each switch making independent decisions based on its local routing table.

[0084] For example, the SDN controller performs path calculation in the following manner: Information Input and Modeling: The controller's path calculation module receives traffic characteristic information (including source / destination addresses and bandwidth requirements) from the registration module. Simultaneously, this module accesses the network state database to obtain the latest global network topology and the real-time link status of each link (especially remaining available bandwidth). The controller typically abstracts the network as a weighted graph model, where nodes represent switches, edges represent links, and the edge weights comprehensively consider available bandwidth, hop count, latency, etc.

[0085] Constraint-based path calculation: The calculation module uses the bandwidth requirement in the traffic characteristic information as the core constraint and searches for feasible paths that satisfy this bandwidth constraint in the graph model. Its optimization objective is usually to select an optimal path, for example: Maximum bottleneck bandwidth path: Select the link with the smallest remaining available bandwidth (bottleneck link) in the path, and the path with the largest possible bandwidth to avoid becoming a new congestion point.

[0086] Load balancing path: Select the path that best balances the load across the entire network while meeting bandwidth requirements.

[0087] The calculation process can employ variations of the shortest path algorithm (such as Dijkstra's algorithm) or more complex multi-constraint path algorithms.

[0088] Generating an explicit path identifier: After calculation, the controller converts the resulting path into an explicit path identifier. This can be an ordered list showing each switch traversed from the ingress switch to the egress switch and its corresponding output port number. This identifier uniquely identifies a physical path across the network.

[0089] The explicit path is converted into flow table rules: Based on this explicit path identifier, the controller generates the flow table rules used to guide packets to the target path. For each switch on the path, the controller generates one or more flow table entries with the matching field being the internal label, and the action being to output precisely to the outgoing port specified in the explicit path. This ensures that packets are forwarded strictly along the predetermined route at each hop, without any uncertainty in local routing.

[0090] In this embodiment, firstly, computation based on a global view avoids suboptimal decisions and potential congestion caused by local optimization, enabling the selection of truly efficient channels for large data flows from a network-wide perspective. Secondly, the use of explicit paths eliminates path jitter and other problems that may occur in traditional distributed routing protocols when dealing with large data flows, ensuring the stability of the transmission process.

[0091] Based on any of the above embodiments, the flow control method further includes: Upon receiving a signal from the application layer program indicating the end of the transmission of the data stream to be transmitted, the system controls the data stream to resume transmission via the default path and releases the network resources occupied by the target path.

[0092] It should be noted that the end signal is a control signaling actively issued by the application layer to mark the completion of a specific data transmission task.

[0093] Restore transmission via default path: Reverts the forwarding policy of the specified data stream from the "explicit path forced routing" state to the "rely on regular network routing mechanisms (such as ECMP)" state.

[0094] Release occupied network resources: Revoke the network resources temporarily reserved to ensure the performance of this data stream, including logical path channels, queue identifiers and bandwidth quotas, so that they can be used by other services.

[0095] It should be understood that once the application layer program (such as an AI training framework) completes operations such as gradient synchronization and senses that the data stream to be transmitted has been completed, it will proactively send a signal to the SDN controller to indicate the end of transmission. This signal corresponds to the trigger signal during registration, forming a complete application layer communication lifecycle notification.

[0096] Upon receiving the termination signal, the SDN controller immediately initiates a reverse control flow to restore the data stream forwarding behavior to normal. Path switching: The controller sends another control command to the ingress network device (e.g., another OpenFlow OFPGC_MODIFY message). This command is used for flow group configuration to switch the effective action bucket from the first action bucket (associated with the target path) back to the second action bucket (associated with the default path); Forwarding Resumption: After this modification command takes effect, if there are subsequent data packets with the same 5-tuple, they will no longer be matched with the internal tag rules, but will be directly processed by the default action bucket, and will be restored to being transmitted through the default path (such as the ECMP-based regular hash forwarding path).

[0097] While restoring the default path, the controller initiates a resource cleanup process, releasing exclusive network resources reserved for this transmission, including: Logical channel deactivation: The path switching operation itself signifies that the logical dedicated channel established for this flow is closed; Queue and bandwidth resource reclamation: The controller notifies the relevant switches to release the dedicated queue and bandwidth quota allocated for this transmission (e.g., by deleting or modifying the corresponding Meter configuration). These released resources (queue identifier, bandwidth quota) will be reintegrated into the network's public resource pool and made available for other flow scheduling.

[0098] In this embodiment, on-demand occupation and timely reclamation of network resources are realized, avoiding long-term vacancy of dedicated channels after the flow ends, and improving the overall utilization rate of network resources.

[0099] Based on any of the above embodiments, the application layer program is an artificial intelligence distributed training framework, and the data stream to be transmitted is the gradient synchronization stream generated by the artificial intelligence distributed training framework during the training process.

[0100] It should be noted that distributed training frameworks for artificial intelligence refer to software platforms used to coordinate massively parallel computing to train deep neural networks, such as distributed versions of TensorFlow and PyTorch, or specialized communication libraries such as NCCL and Horovod. These frameworks are responsible for breaking down training tasks across multiple computing nodes (such as GPU servers) for execution and managing data synchronization between nodes.

[0101] Gradient synchronization stream: In distributed training, each computing node generates gradients for the model parameters after completing forward and backward propagation locally. To update the global model, the gradients from all nodes need to be aggregated (e.g., through an All-Reduce operation), and the aggregated gradients (or their update values) are then distributed to all nodes. The data stream generated by this aggregation and distribution communication process is called the gradient synchronization stream. Due to the enormous number of parameters in modern models (reaching hundreds of GB or even TB levels), and the need for synchronization in each training iteration, this data stream exhibits typical elephant stream characteristics: extremely large data volume, long duration, periodic occurrence, and extreme sensitivity to communication latency and bandwidth.

[0102] It should be understood that, in the application scenario described in this embodiment, the workflow of the flow control method is closely coupled with the lifecycle of the AI ​​training job: ①Training framework registration traffic characteristics: At the initial stage of an AI training task or before the start of each iteration cycle, the AI ​​distributed training framework, as an application layer program, can anticipate upcoming gradient synchronization operations. Based on model size, parallelism, and other factors, it calculates the traffic characteristics of the gradient synchronization flow, including: flow identifiers (IPs and ports of all nodes participating in All-Reduce), expected data volume (total gradient size), communication start indication information (bound to a specific computational stage of the training iteration), and bandwidth requirements (needed to meet the target iteration time). The framework proactively registers this information with the SDN controller.

[0103] ② Parallel network pre-configuration and training computation: Based on the registration information, the SDN controller calculates the target path, allocates dedicated queues and bandwidth, and pre-sets sleep flow tables. Simultaneously, each compute node performs local model training computations. Network-side preparation and compute-side operations run in parallel, without consuming critical training time.

[0104] ③ Network switching is triggered upon completion of calculation: When all nodes have completed local gradient calculations and are about to enter the communication phase, the training framework sends a trigger signal to the SDN controller. The controller then activates the pre-defined flow table, establishing a high-speed dedicated channel for gradient synchronization.

[0105] ④ Efficient and stable gradient synchronization: Gradient synchronization data begins transmission on the reserved channel. Because path resources are guaranteed, congestion and PFC oscillations are avoided, enabling the All-Reduce operation to complete with near-line-speed stable bandwidth and extremely low jitter, thus reducing communication overhead time.

[0106] ⑤ Release resources synchronously: After gradient synchronization is complete, the training framework sends a termination signal. The controller releases network resources, the network returns to normal, and the training process enters the computation phase of the next iteration.

[0107] In this embodiment, a zero-congestion, zero-oscillation network transmission guarantee mechanism is provided for the periodic and predictable synchronization of massive data in AI training. This transforms the originally uncontrollable communication delays affected by PFC oscillations into deterministic, optimal network transmission times, thereby shortening the cycle of each training iteration, accelerating model convergence, and improving the utilization efficiency of the AI ​​computing cluster.

[0108] Based on any of the above embodiments, the data stream to be transmitted is a remote direct memory access data stream transmitted in a lossless network environment.

[0109] It's important to note that a lossless network environment is one that uses link-layer flow control mechanisms to ensure no data frame loss occurs during congestion. In this environment, when a switch's egress queue is about to overflow, it sends a pause frame upstream, temporarily blocking traffic and achieving zero packet loss. However, this mechanism is precisely the root cause of bandwidth oscillation problems.

[0110] Remote Direct Memory Access (RDMA) data stream: A data stream transmitted via Remote Direct Memory Access (RDMA) technology. RDMA allows network adapters to directly read data from the memory of one host and write it to the memory of another host, completely bypassing the operating system kernel and CPU of both hosts, thus providing extremely high throughput and extremely low latency and CPU overhead. RoCE (RDMA over Converged Ethernet) is the mainstream protocol for implementing RDMA technology over Ethernet.

[0111] In this embodiment, by introducing predictive, resource-guaranteed scheduling into the lossless network, the RDMA elephant stream can fully enjoy the benefits of zero packet loss without triggering PFC oscillations, thereby stably reaching the theoretical performance peak of the protocol.

[0112] This application provides a flow control method.

[0113] In this embodiment, the method includes: During the training iteration cycle of the neural network model, local gradient calculations are performed in parallel on multiple computing nodes. Before the local gradient calculation is completed, the control training framework sends the flow characteristic information of the gradient data stream to be synchronized in the current iteration to the software-defined network controller; Once the local gradient calculation is completed, the training framework is controlled to send a trigger signal to the software-defined network controller. The software-defined network controller is controlled to respond to the trigger signal and activate the configured flow table rules so that the gradient data stream is synchronously transmitted through the target path; The parameters of the neural network model are updated based on the gradient data that has been synchronously transmitted.

[0114] It should be noted that this embodiment illustrates an artificial intelligence distributed training method based on the flow control method described in the above embodiments.

[0115] The gradient data stream to be synchronized in the current iteration corresponds to the data stream to be transmitted in the aforementioned flow control method. The training framework is a specific instance of the application layer program.

[0116] Through the steps in this embodiment, in each training iteration, when time-consuming gradient synchronization (such as All-Reduce operation) is required, the training framework and network controller work together to utilize a pre-configured, dormant dedicated network channel to achieve stable, high-speed, and low-latency transmission of gradient data. This effectively avoids the communication latency and jitter caused by PFC oscillations triggered by gradient synchronization flow in traditional RoCE networks, thereby transforming the originally unpredictable communication overhead into deterministic, optimal network transmission time, shortening the cycle of a single training iteration, and improving the execution efficiency of AI training tasks.

[0117] AI distributed training frameworks, such as TensorFlow, PyTorch's distributed modules, or Horovod, are responsible for organizing multiple computing nodes (such as GPU servers) for model training.

[0118] Software-defined network controller: responsible for centralized management of the underlying RoCE lossless network.

[0119] The distributed training framework for artificial intelligence and the software-defined network controller collaborate through a predefined interface, overlapping the computation and communication phases in a training iteration in time, and using predictive information to prepare dedicated network resources for the communication phase.

[0120] Understandably, before local gradient computation is complete, the training framework can pre-calculate the communication volume required for the upcoming gradient synchronization based on information such as model size and parallelism. Therefore, it proactively sends the traffic characteristics information of the gradient data stream to be synchronized in the current iteration to the SDN controller. Optionally, the traffic characteristics information includes the five-tuple identifier of the gradient synchronization stream, the expected data volume (total gradient size), bandwidth requirement information (required to meet the target iteration time), and communication start indication information (e.g., a trigger signal identifier bound to this iteration).

[0121] The training framework determines that local gradient computation is complete when all compute nodes have finished calculating their local gradients. The training framework immediately sends a trigger signal to the SDN controller. This trigger signal aims to map the end time of a computation job at the application layer to the start time of a dedicated transmission channel at the network layer, ensuring that network resources are activated precisely when needed.

[0122] Upon receiving a trigger signal, the SDN controller responds by sending a fast control command to the ingress network device. This command activates pre-configured flow table rules. Specifically, it modifies the flow table group of the ingress switch, switching the active action bucket from the bucket associated with the default path to the bucket associated with the target path. Instantly, an explicit path with guaranteed bandwidth from source to destination is established. The gradient data stream is then directed to this reserved path and synchronous transmission begins. Due to the exclusive and sufficient path resources, the transmission process is smooth and high-speed, avoiding buffer congestion and the resulting PFC oscillations.

[0123] After the gradient data is synchronized across all nodes, the training framework updates the parameters of the neural network model using optimization algorithms (such as SGD and Adam) based on the synchronized gradient data. At this point, a complete training iteration ends, and the system prepares to enter the next iteration cycle, repeating the above collaborative process.

[0124] In this embodiment, zero-wait and zero-oscillation gradient synchronization communication is achieved. By reserving network resources in parallel during the computation phase and activating the dedicated channel instantaneously upon completion of the computation, the originally unpredictable large-scale gradient synchronization time, which is severely affected by network congestion and PFC, is transformed into a deterministic, near-linear-speed optimal transmission time. This shortens the cycle of each training iteration, thereby significantly accelerating the overall model convergence process.

[0125] Furthermore, based on the same concept as the described flow control method, this application also provides an apparatus and method for solving elephant flow control in AI training networks using SDN flow tables. It relates to a method for fine-grained control of persistent elephant flows in high-performance computing and artificial intelligence training scenarios using Software-Defined Networking (SDN) technology to eliminate bandwidth oscillations caused by Priority Flow Control (PFC) mechanisms and achieve stable, high-bandwidth data transmission.

[0126] In this embodiment, the purpose of the device and method for solving the elephant flow control of AI training network using SDN flow tables is to overcome the defects of traditional PFC technology in elephant flow control. Based on the prediction information of AI training task, the network path is pre-configured before data transmission and activated instantaneously when needed, providing a "fast channel" with bandwidth guarantee and dedicated queue for elephant flow, thereby achieving stable high bandwidth transmission and eliminating PFC oscillation.

[0127] The core idea of ​​this method is "pre-configuration, post-triggering, and dynamic activation." Before the AI ​​training task begins, the flow table rules controlling the elephant flow are pre-configured into the relevant switches via the SDN controller, but these rules are initially in a "dormant" state. When the training framework sends a trigger signal to start communication, the controller activates these rules through a very fast control plane instruction (such as modifying the flow table group), guiding the elephant flow to the predetermined optimal path and dedicated queue. After communication ends, resources are dynamically released.

[0128] To achieve the above ideas, this method consists of two main components: 1. An SDN flow table control device: comprising a flow prediction registration module, a path calculation module, a flow table generation module, and a flow table trigger control module.

[0129] 2. A control method based on the device: comprising four main steps: flow feature registration, flow table pre-configuration, flow table dynamic activation, and resource release.

[0130] See Figure 2 Devices and methods for solving elephant flow control in AI training networks using SDN flow tables include: First, the AI ​​training framework program pre-registers the elephant flow traffic characteristics with the SDN controller. These characteristics include key parameters such as flow ID, source / destination IP address (or GID), protocol port, expected data volume, communication start time or trigger signal, and bandwidth requirements. Based on the traffic characteristics sent by the AI ​​training framework and the global network topology, the SDN controller calculates an optimal explicit path from the source to the destination. This elephant flow is then assigned a unique logical queue identifier and bandwidth quota.

[0131] II. The process of generating SDN flow tables: The SDN controller generates specific, cross-switch OpenFlow flow table entries. The key is generating an anchor flow table and a dormant flow table.

[0132] 1) Anchor Flow Table: Deployed on the ingress switch, it is used to identify elephant flows, assign an internal tag (such as VLAN ID) to them, and guide them to subsequent flow tables or groups.

[0133] 2) Dormant Flow Tables: These include transit flow tables on Spine switches and egress flow tables on egress switches. Flow tables are pre-configured on all switches along the path, with the matching field being the internal label and the action pointing to the specified egress port. However, their initial state is temporarily inactive because they are associated with a bucket of inactive actions through a group action.

[0134] 3) Detailed implementation of flow tables: Specifically, configure two flow tables on the ingress switch.

[0135] Table 0 is the anchor flow table, matching the elephant flow 5-tuple, with the action being push_vlan and goto_table 1.

[0136] The action of the flow table entry in Table 1 is group:100.

[0137] Group 100 contains two action buckets: Bucket 1: meter:1, set_field: 200->vlan_vid, output:3 (Elephant Stream channel, initial weight is 0 or ineffective).

[0138] Bucket 2: output:3 (Default channel, initially effective).

[0139] On the core and egress switches along the path, flow tables matching vlan_vid=200 are pre-configured, with the action pointing to the corresponding egress port. These flow tables are always valid.

[0140] III. Flow Table Trigger Control Module: The SDN controller receives the Elephant Stream trigger signal from the AI ​​framework. It sends a Group_MOD message to the ingress switch, activating the preset Elephant Stream channel from the default bypass in the action bucket of the specified group, and switching the data to the preset flow table.

[0141] After receiving the trigger signal, the controller sends the OpenFlow OFPGC_MODIFY command to the ingress switch to modify Group 100 and set Bucket 1 as the only effective bucket.

[0142] Fourth, after the elephant stream transmission is completed, the AI ​​training framework sends an elephant stream end signal to the SDN controller, and the ingress switch resumes default flow table forwarding, releasing the occupied network resources.

[0143] After receiving the end signal, the controller sends the OFPGC_MODIFY command again to switch the active bucket of Group 100 back to Bucket 2.

[0144] By utilizing the dynamic reorganization capability of SDN flow tables through the above methods, precise and rapid control of the network data plane is achieved, effectively solving the key performance bottleneck in AI training networks.

[0145] In this embodiment, bandwidth oscillations caused by the PFC mechanism are avoided, enabling elephant streams to transmit at a stable rate close to line speed, reducing communication latency and tail latency, and directly accelerating AI training iterations. Through "sleep" and "dynamic activation" mechanisms, network resources are only occupied by dedicated resources when needed, improving the overall network utilization efficiency. Triggered by SDN's Group_MOD message, the switching speed is extremely fast (microseconds), adapting to the rhythm of AI training iterations. No modification to the AI ​​training program is required, making deployment easy.

[0146] Based on the methods described in any of the above embodiments, this application also provides, as follows: Figure 3 The diagram shows the structure of an electronic device. Figure 3 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the methods described in any of the above embodiments.

[0147] Based on the methods described in any of the above embodiments, this application also provides a computer storage medium storing a computer program, which, when executed by a processor, can be used to perform the methods described in any of the above embodiments.

[0148] Based on the methods described in any of the above embodiments, this application also provides a computer program product, which includes one or more computer programs or instructions. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. When executed by a processor, the computer program implements the methods described in any of the above embodiments.

[0149] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0150] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0151] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0153] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0154] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A flow control method, characterized in that, The method includes: Obtain the traffic characteristics information of the data stream to be transmitted sent by the application layer program; Based on the traffic characteristic information, corresponding flow table rules are generated; The flow table rules are pre-configured to the network device, and the flow table rules are controlled to be in an inactive dormant state. Upon receiving a trigger signal from the application layer program, a control command is sent to the network device to switch the flow table rule to an active state, so that the data stream to be transmitted is transmitted via the target path based on the active flow table rule; the trigger signal is used to instruct the data stream to be transmitted to start transmission.

2. The method according to claim 1, characterized in that, The control flow table rule is in an inactive dormant state, and the flow table rule is switched to an active state, by operating the flow table group in the ingress network device of the data flow to be transmitted. The pre-configured flow table group includes at least a first action bucket and a second action bucket. The first action bucket is associated with the target path and is configured to be initially inactive to form the dormant state. The second action bucket is associated with the default path and is configured to be initially active. The second action bucket is used to forward the data stream to be transmitted in the dormant state. The control command is used to instruct the modification of the configuration of the flow table group so that the first action bucket is activated.

3. The method according to claim 2, characterized in that, The control command carries the identifier of the flow table group and includes the updated configuration information of the first action bucket, and is used to instruct the effective action bucket in the flow table group to be switched from the second action bucket to the first action bucket according to the updated configuration information of the first action bucket.

4. The method according to claim 1, characterized in that, The traffic characteristic information includes the identifier of the data stream to be transmitted, the expected data volume, and the bandwidth requirement information; The step of generating corresponding flow table rules based on the traffic feature information includes: The start and end points of the data stream to be transmitted are determined based on the identifier; If the data stream to be transmitted is determined to be an elephant stream that needs to be scheduled based on the expected data volume, the target path is determined for the data stream to be transmitted and the corresponding bandwidth quota is allocated based on the bandwidth requirement information.

5. The method according to claim 1, characterized in that, The step of generating corresponding flow table rules based on the traffic feature information includes: Based on the traffic characteristic information, the target path is calculated for the data stream to be transmitted, and dedicated queue resources and bandwidth quotas are allocated for the target path; Generate flow table rules for directing the data stream to be transmitted to the target path and dedicated queue.

6. The method according to claim 5, characterized in that, The step of calculating the target path for the data stream to be transmitted based on the traffic characteristic information includes: Based on the global network topology and real-time link status information maintained by the software-defined network controller, an end-to-end explicit forwarding path is calculated for the data stream to be transmitted.

7. The method according to claim 1, characterized in that, The flow control method further includes: Upon receiving a signal from the application layer program indicating the end of the transmission of the data stream to be transmitted, the system controls the data stream to resume transmission via the default path and releases the network resources occupied by the target path.

8. The method according to claim 1, characterized in that, The application layer program is an artificial intelligence distributed training framework, and the data stream to be transmitted is the gradient synchronization stream generated by the artificial intelligence distributed training framework during the training process.

9. The method according to claim 1, characterized in that, The data stream to be transmitted is a remote direct memory access data stream transmitted in a lossless network environment.

10. A flow control method, characterized in that, The method includes: During the training iteration cycle of the neural network model, local gradient calculations are performed in parallel on multiple computing nodes. Before the local gradient calculation is completed, the control training framework sends the flow characteristic information of the gradient data stream to be synchronized in the current iteration to the software-defined network controller; Once the local gradient calculation is completed, the training framework is controlled to send a trigger signal to the software-defined network controller. The software-defined network controller is controlled to respond to the trigger signal and activate the configured flow table rules so that the gradient data stream is synchronously transmitted through the target path. The gradient data after synchronous transmission is used to update the parameters of the neural network model.

11. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; When the processor invokes the executable instructions, it implements the method of any one of claims 1-9 or the method of claim 10.

12. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of any of the methods described in claims 1-9 or the steps of the method described in claim 10.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-9 or the method described in claim 10.

Images