Data transmission control method and device, electronic equipment, storage medium and computer program product

Abstract

The application relates to a data transmission control method and device, electronic equipment, a storage medium and a computer program product, and relates to the technical field of computers.The method comprises the following steps: dividing to-be-transmitted data into a plurality of data packets of a same data stream, and generating a stream identifier, a sequential domain identifier and an intra-domain serial number for each data packet; determining a plurality of candidate paths, obtaining path state information of the candidate paths, and selecting a target path for each data packet to be sent based on the path state information, so that a receiving end submits data packets in a same sequential domain in an intra-domain serial number sequence according to the stream identifier, the sequential domain identifier and the intra-domain serial number. According to the application, data packets are adaptively distributed to candidate paths, local overload is avoided, and bandwidth utilization is improved; meanwhile, a grouping submission mechanism based on a sequential domain reduces the reordering complexity and cache overhead of the receiving end, and the throughput and delay performance of large-scale data transmission are optimized.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a data transmission control method, apparatus, electronic device, storage medium, and computer program product. Background Technology

[0002] In large model training and inference scenarios, AI (artificial intelligence) accelerators such as TPU (Tensor Processing Unit) and GPU (Graphics Processing Unit) need to use PCIe (High-Speed ​​Peripheral Component Interconnect Standard) / CXL (Compute High-Speed ​​Interconnect) high-speed interconnects to transfer training samples, parameters, gradients and other data between the host, memory, network card and accelerator. Current PCIe transmission typically employs single-stream, single-path binding, static allocation of DMA (Direct Memory Access) queues, or coarse-grained flow-level scheduling, lacking packet-level or block-level multi-path load balancing capabilities. Simple packet-by-packet distribution violates PCIe order field constraints, leading to errors in the correspondence between out-of-order submissions and completion messages. These shortcomings result in AI accelerators facing insufficient multi-path utilization and a lack of order protection under high-throughput, low-tail-latency requirements. Summary of the Invention

[0003] The technical problem solved by this application is to provide a data transmission control method, device, electronic device, storage medium and computer program product, which can realize packet-level multipath distribution and sequence protection of the same data stream in PCIe high-speed interconnect, so as to improve bandwidth utilization, reduce tail latency and enhance robustness in abnormal link scenarios.

[0004] According to a first aspect of the embodiments of this application, a data transmission control method is provided, applied at a transmitting end, the method comprising: The received data to be transmitted is divided into multiple data packets of the same data stream, and a stream identifier, a sequence field identifier, and an intra-domain sequence number are generated for each data packet. The stream identifier is used to identify the data stream, the sequence field identifier is used to identify the sequence field boundary, and the intra-domain sequence number is used to identify the order of data packets within the same sequence field. Multiple candidate paths are identified, and the path status information of the candidate paths is obtained; Based on the path status information, a target path is selected from the candidate paths for each data packet and sent, so that the receiving end submits data packets within the same sequence field identifier in the order of the intra-domain sequence number according to the flow identifier, the sequence field identifier, and the intra-domain sequence number.

[0005] Compared with the prior art, the beneficial effects of this application are as follows: This application divides the same data stream into multiple data packets and generates a flow identifier, sequence field identifier, and intra-domain sequence number for each data packet. This allows the sender to calculate path weights based on the path status information of candidate paths and dynamically select a target path for each data packet. Simultaneously, the receiver submits data packets within the same sequence field in order based on the flow identifier, sequence field identifier, and intra-domain sequence number. Compared with existing technologies, this application achieves packet-level multi-path distribution, avoiding local congestion and wasted idle paths caused by long-term binding of a single stream to a single path, thereby improving bandwidth utilization. Based on the path status information, a target path is selected from the candidate paths for each data packet and sent, effectively reducing latency spikes caused by single-path congestion and lowering tail latency. Through the sequence field identifier and intra-domain sequence number constraints, the submission order of data packets within the same sequence field is ensured to meet PCIe protocol requirements, solving the out-of-order risk that may be caused by simple packet-by-packet distribution and enhancing robustness in link anomaly scenarios.

[0006] In some embodiments, it also includes: The path weight of the candidate path is calculated based on the path status information, wherein the path weight is used to represent the congestion level of the path; Based on the path weights, a target path is selected from the candidate paths for each data packet and sent.

[0007] In some embodiments, it also includes: The receiver receives congestion information generated when the transmission node detects path congestion, and also receives acknowledgment information returned by the receiver based on the flow identifier and the sequence field identifier; wherein the acknowledgment information includes positive acknowledgment and negative acknowledgment, the positive acknowledgment being used to indicate that the data packet was received correctly, and the negative acknowledgment being used to indicate that the data packet timed out, was missing, or had a checksum error. The path weights of the candidate paths are adjusted based on the congestion information and the confirmation information. When the negative acknowledgment is received, the corresponding data packet is retransmitted on the original path or the backup path.

[0008] In some embodiments, adjusting the path weight of the candidate path based on the congestion information and the confirmation information includes: When a candidate path is detected to have consecutive negative acknowledgments, an increase in the number of replays, or an increase in the value of the congestion information, the path weight of the candidate path is reduced until the path use of the candidate path is suspended. Once the candidate path stabilizes, its path weight is gradually restored.

[0009] In some embodiments, the path weight is calculated as follows: The path weight is equal to the product of the first preset coefficient and the available credit value, plus the product of the second preset coefficient and the path bandwidth, minus the product of the third preset coefficient and the queue depth, minus the product of the fourth preset coefficient and the error count, and minus the product of the fifth preset coefficient and the number of retransmissions or negative acknowledgments. Wherein, the available credit value represents the credit limit currently available for the path, the path bandwidth represents the transmission bandwidth capacity of the path, the queue depth represents the queue length of data packets to be transmitted on the path, the error count represents the number of transmission errors that have occurred on the path, and the retransmission or negative acknowledgment count represents the number of retransmissions or negative acknowledgments that have been triggered on the path.

[0010] In some embodiments, selecting a target path from the candidate paths for each data packet and sending it based on the path weight includes: When the data packets belong to the same sequence field identifier and have a sequence dependency, multiple data packets in the same data stream are distributed to different candidate paths according to the path weight of the candidate path. This allows the receiving end to reorder the received data packets according to the stream identifier, the sequence field identifier, and the sequence number within the field, so as to restore the original order of the data packets within the same sequence field identifier and submit them.

[0011] In some embodiments, selecting a target path from the candidate paths for each data packet and sending it based on the path weight includes: When the data packets have loose order attributes, belong to different address windows, or belong to different service queues, data packets with different order field identifiers in the same data stream are distributed to different candidate paths in no particular order, so that the receiving end does not perform reordering within the order field for the data packets, but submits them directly according to the arrival order.

[0012] In some embodiments, generating a flow identifier, a sequence field identifier, and an intra-domain sequence number for each data packet includes: Parse the header and context information of each data packet, and extract at least one of the following attributes: request identifier, address, tag, queue number, service type, traffic category, and sequence attribute; Generate a flow identifier for each data packet based on at least one of the request identifier, the address, the tag, the queue number, the service type, and the traffic category; Based on the order attribute, the same order field identifier is assigned to packets with order dependencies, and different order field identifiers are assigned to packets that are allowed to be submitted out of order; and within the order field identifier, a sequentially increasing in-field sequence number is assigned to each packet.

[0013] In some embodiments, the transmission node generates congestion information when congestion is detected, including: When a transmission node detects that the queue length of the node on a candidate path exceeds a first threshold, the available credit value is lower than a second threshold, the link rate decreases by a third threshold, or the number of link layer error replays exceeds a fourth threshold, the congestion information is generated. The congestion information is transmitted to the sending end through internal sideband fields, vendor-defined messages, completion extension fields, acknowledgment information, status registers, interrupt signals, extended message signals, interrupt messages, or firmware mailbox mechanisms.

[0014] According to a second aspect of the embodiments of this application, a data transmission control method is provided, applied at a receiving end, the method comprising: The receiving end selects a target path from the candidate paths based on the path status information of multiple candidate paths and sends multiple data packets. Each data packet carries a flow identifier, a sequence field identifier, and a sequence number within the field. The flow identifier is used to identify the data flow, the sequence field identifier is used to identify the sequence field boundary, and the sequence number within the field is used to identify the order of data packets within the same sequence field. Based on the flow identifier, the sequence field identifier, and the intra-domain sequence number, data packets within the same sequence field identifier are submitted in the order of the intra-domain sequence number.

[0015] Compared with the prior art, the beneficial effects of this application are as follows: This application enables the receiving end to receive data packets carrying flow identifiers, sequence field identifiers, and intra-sequence numbers. Based on these identifiers, data packets within the same sequence field are submitted in the order of their intra-sequence numbers. This allows the receiving end to accurately identify the flow to which the data packets belong and the boundaries of the sequence field. Even when data packets arrive out of order via multiple paths, they can still be submitted in the order required by the PCIe protocol within the sequence field, avoiding protocol violations caused by out-of-order delivery in traditional multipath transmission. Furthermore, since the sending end dynamically selects paths based on path state information, the receiving end does not need to maintain a complex global reordering window; it only needs to perform local reordering based on the sequence field identifiers, reducing the receiving end's buffering overhead and processing latency. In addition, the receiving end can quickly locate missing data packets using the flow identifier and sequence field identifier, facilitating the generation of negative acknowledgments for feedback to the sending end. Combined with the sending end's closed-loop adjustment mechanism, this further improves the reliability of data transmission and the ability to recover from link anomalies.

[0016] In some embodiments, it also includes: Buffer out-of-order packets based on the flow identifier, sequence field identifier, and intra-field sequence number; For data packets that belong to the same sequence field identifier and have sequence dependencies, they are reordered according to the flow identifier, the sequence field identifier, and the sequence number within the field to restore the original order of data packets within the same sequence field identifier and submit them. For packets with loose order attributes, belonging to different address windows, or belonging to different service queues, reordering within the order field is not performed; they are submitted directly in the order of arrival.

[0017] According to a third aspect of the embodiments of this application, a data transmission control device is provided, applied at a transmitting end, the device comprising: The data partitioning module is used to divide the received data to be transmitted into multiple data packets of the same data stream, and generate a stream identifier, a sequence field identifier, and an intra-domain sequence number for each data packet. The stream identifier is used to identify the data stream, the sequence field identifier is used to identify the sequence field boundary, and the intra-domain sequence number is used to identify the order of data packets within the same sequence field. The path status acquisition module is used to determine multiple candidate paths and obtain the path status information of the candidate paths; The packet distribution and scheduling module is used to select a target path from the candidate paths for each data packet based on the path status information and send it, so that the receiving end submits the data packets within the same sequence field identifier in the order of the sequence number according to the flow identifier, the sequence field identifier and the intra-domain sequence number.

[0018] According to a fourth aspect of the embodiments of this application, a data transmission control device is provided, applied at a receiving end, the device comprising: The receiving module is used to receive path status information from multiple candidate paths from the sending end, select the target path from the candidate paths, and send multiple data packets. Each data packet carries a flow identifier, a sequence field identifier, and a sequence number within the field. The flow identifier is used to identify the data flow, the sequence field identifier is used to identify the sequence field boundary, and the sequence number within the field is used to identify the order of data packets within the same sequence field. The reordering module is used to submit data packets within the same sequence field identifier in the order of the intra-domain sequence number, based on the flow identifier, the sequence field identifier, and the intra-domain sequence number.

[0019] According to a fifth aspect of the embodiments of this application, an electronic device is provided, characterized in that it includes a memory and a processor, the memory being used to store a computer program executable by the processor; the processor being used to execute the computer program in the memory to implement the data transmission control method as described in any one of the first or second aspects.

[0020] According to a sixth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the executable computer program in the storage medium is executed by a processor, the data transmission control method as described in any one of the first or second aspects is implemented.

[0021] According to a seventh aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the data transmission control method as described in any one of the first or second aspects. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a data transmission control method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a data transmission control method according to another exemplary embodiment; Figure 3 This is a schematic diagram illustrating a data transmission control architecture according to an exemplary embodiment; Figure 4 This is a data flow timing diagram illustrated according to an exemplary embodiment; Figure 5 This is a block diagram illustrating a data transmission control device according to an exemplary embodiment.

[0023] Figure 6 This is a block diagram illustrating a data transmission control device according to another exemplary embodiment.

[0024] Figure 7 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0025] Unless otherwise defined, the technical or scientific terms used in this specification and claims shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. Specific embodiments of this application will be described below in conjunction with the accompanying drawings. It should be noted that, in order to provide a concise description, this specification cannot exhaustively describe all features of the actual embodiments. Without departing from the spirit and scope of this application, those skilled in the art can modify and substitute the embodiments of this application, and the resulting embodiments are also within the protection scope of this application.

[0026] As the scale of large-scale model training and inference tasks increases, AI accelerators such as TPUs (Tensor Processing Units), GPUs (Graphics Processing Units), and NPUs (Neural Processing Units) need to continuously transfer training samples, model parameters, gradient data, and intermediate results between the host CPU, system memory, network interface card (NIC), SSD (Solid State Drive), DPU (Data Processing Unit), and multiple accelerators. This data transfer typically relies on high-speed interconnects within PCIe, CXL, PCIe switches, DMA engines, or internal boards. In multi-accelerator servers, the system often has multiple PCIe Root Ports, multiple switch downlink ports, multiple Virtual Channels, multiple DMA queues, and multiple internal forwarding pipelines. If a data stream is bound to a single path for a long time, it is prone to problems such as local congestion, credit exhaustion, queue backlog, and increased tail latency, while other paths may be idle.

[0027] Existing technologies enhance the bandwidth of a single link through parallel transmission in multiple lanes at the PCIe physical layer. However, this mechanism is limited to symbol-level parallelism within the same link and cannot address load balancing across multiple PCIe ports or logical paths. Furthermore, data transmission typically relies on static allocation using DMA queues, Traffic Classes, Virtual Channels, or Switch port mappings. Different queues or flows are fixedly mapped to specific paths, lacking dynamic adjustment capabilities. Regarding flow control, while credit-based flow control can prevent the sender from exceeding the receiver's buffer capacity, its feedback only reflects the local state of the link or channel, lacking end-to-end congestion awareness for the entire data flow. At the scheduling level, driver software or firmware can perform coarse-grained scheduling across multiple DMA queues, but the scheduling granularity is typically at the queue, task, or flow level, failing to achieve fine-grained control at the TLP (Transaction Layer Packet) or data block level. Finally, although some switching chips can count port queues or error status, they do not feed back the congestion information of specific paths to the original sender along with ACK / NACK (acknowledgment / negative acknowledgment) or Completion, which makes it impossible for the sender to dynamically adjust the transmission rate accordingly.

[0028] Therefore, existing technologies suffer from the following technical problems: First, single-stream, single-path dependence leads to uneven resource utilization. A training data stream, parameter stream, gradient stream, or DMA stream may occupy a single path for an extended period, causing congestion on that path while other paths remain idle. Second, load balancing granularity is too coarse. Existing multi-queue scheduling typically operates on a stream, task, or DMA descriptor basis, making it difficult to balance link load at the TLP or data block granularity. Third, congestion perception is inaccurate. PCIe credits primarily reflect local buffer resources, and the sender cannot know the specific congestion status of intermediate ports, virtual channels, or internal paths. Furthermore, simple packet-by-packet distribution carries the risk of out-of-order delivery. If the TLP in the same PCIe transaction stream is distributed unconstrainedly across multiple paths, it may disrupt the sequence field, completion correspondence, or the data submission order visible to the device. Finally, fault recovery efficiency is low. When a path degrades, error replay increases, or a port becomes congested, existing solutions rely on slow software scheduling or link recovery processes. In the PCIe / CXL high-speed interconnect field, replay is a standard term referring to data retransmission behavior triggered by errors or packet loss at the link layer. To address the problems of single-stream single-path dependency, coarse-grained load balancing, inaccurate congestion perception, out-of-order risk from simple packet-by-packet distribution, and low fault recovery efficiency in existing PCIe high-speed interconnect technologies for AI accelerators, this application provides a data transmission control method, apparatus, electronic device, storage medium, and computer program product. This method solves the problems of single-stream single-path dependency and coarse-grained load balancing by distributing the same data stream to multiple available paths at the packet or block level, thereby improving bandwidth utilization and reducing tail latency. By introducing sequence domain control, it avoids the out-of-order risk of simple packet-by-packet distribution, ensuring the correctness of data submission order. An explicit congestion feedback mechanism improves congestion control accuracy. Simultaneously, combined with a dynamic weight adjustment mechanism, it enhances fault recovery efficiency and robustness under abnormal link scenarios.

[0029] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0030] This application can be applied to AI accelerators (such as TPU (Tensor Processing Unit)), GPUs (Graphics Processing Units), NPUs (Neural Processing Units), DPUs (Data Processing Units), SmartNICs (Smart Network Interface Cards), NVMe controllers (Non-volatile Memory Fast Path Controllers), storage accelerator cards, or inter-chip interconnect bridge chips, etc.; the interconnect protocols on which it is based include PCIe, CXL.io (Compute Fast Link I / O Protocol), CXL.mem (Compute Fast Link Memory Protocol), CXL.cache (Compute Fast Link Caching Protocol), Network on Chip (NoC), Chiplet Interconnect, UEC (Ultra Ethernet Alliance) / RDMA (Remote Direct Memory Access) entry-side transmission, or vendor-defined high-speed interconnects, etc.

[0031] This application offers high flexibility and convenience in hardware implementation. Specifically, it can be directly integrated into hardware devices such as PCIe controllers, data processing units (DPUs), network switches, field-programmable gate arrays (FPGAs), or tensor processing units (TPUs) I / O dies, operating as a hardware module. Furthermore, key parameters (such as path weights) can be dynamically configured via firmware, adapting to different network environments and service requirements without modifying the hardware logic. This design ensures both the advantages of high-performance hardware acceleration and the flexibility of software programmability.

[0032] This application offers broad scalability in deployment scenarios. Specifically, it can be applied within a single server, such as a server equipped with multiple TPUs (Tensor Processing Units), to optimize data transmission scheduling between TPUs; it can also be extended to larger-scale rack-level AI training systems, serving as an I / O scheduling module for DPUs (Data Processing Units) or PCIe Switches to achieve efficient data flow control across nodes and racks. This design allows the solution to flexibly adapt to different deployment needs, from small standalone machines to large clusters, balancing high-performance local interconnection with global resource scheduling capabilities.

[0033] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a data transmission control method according to an exemplary embodiment. The data transmission control method of this application, applied at the transmitting end, includes steps S101-S103: S101, the received data to be transmitted is divided into multiple data packets of the same data stream, and a stream identifier, a sequence field identifier, and an intra-domain sequence number are generated for each data packet, wherein the stream identifier is used to identify the data stream, the sequence field identifier is used to identify the sequence field boundary, and the intra-domain sequence number is used to identify the order of data packets within the same sequence field.

[0034] Understandably, at the sending end, the received data to be transmitted (e.g., training samples, model parameters, gradient data, etc.) is split into multiple data packets belonging to the same data stream, and a flow ID, order domain ID, and sequence number are generated for each data packet. The flow ID uniquely identifies the data stream to which the data packet belongs (e.g., a DMA stream or TPU computation stream); the order domain ID defines the order domain boundaries, i.e., which data packets must maintain a strict submission order; and the sequence number identifies the order of data packets within the same order domain. Its function is to allow the system to distinguish and independently schedule different data streams through the flow ID; to identify which data packets have order dependencies (must be submitted in order) and which are allowed to be out of order (e.g., data packets with loose order attributes or belonging to different address windows) through the order domain ID; and to allow the receiving end to buffer out-of-order data packets and reorder them when the order conditions are met, thereby restoring the original order. In this way, the sending end can distribute data packets of the same data stream to multiple available paths while ensuring the correct order, thereby achieving load balancing and avoiding the out-of-order risk caused by simple packet-by-packet distribution.

[0035] This application introduces flow identifiers, sequence field identifiers, and intra-domain sequence numbers to achieve independent routing and reordering at the TLP or data block granularity. This breaks through the coarse-grained scheduling limitations of existing technologies that use flow, task, or DMA descriptors as units, thereby balancing link load at a finer granularity while ensuring orderly data submission and avoiding out-of-order risks.

[0036] S102, determine multiple candidate paths and obtain the path status information of the candidate paths.

[0037] Optionally, the data transmission control method further includes: calculating the path weight of the candidate path based on the path status information, wherein the path weight is used to represent the congestion level of the path.

[0038] Understandably, the sending end pre-configures multiple selectable transmission paths as candidate paths. The sending end uses a path status sampling module to obtain the current status information of each candidate path in real time, including available credit, queue depth, link bandwidth, round-trip delay, error count, replay count, and ACK / NACK status. Then, based on this status information, it calculates the weight value of each path using a weighting formula. This weight value directly reflects the congestion level of the path. Its function is to provide a quantitative basis for path selection to the packet distribution and scheduling module, enabling the sending end to dynamically allocate data packets to paths with higher weights (i.e., less congested and better quality) based on the real-time congestion status of each path. This avoids sending data packets to already congested paths, achieving load balancing among multiple paths, improving overall bandwidth utilization, and reducing tail latency.

[0039] S103, based on the path status information, select a target path from the candidate paths for each data packet and send it, so that the receiving end submits the data packets within the same sequence field identifier in the order of the sequence number according to the flow identifier, the sequence field identifier and the intra-domain sequence number.

[0040] Optionally, the data transmission control method further includes: selecting a target path from the candidate paths for each data packet and sending it based on the path weight.

[0041] Understandably, the sending end calculates the path weights of the candidate paths in step S102. These path weights can be determined by algorithms such as weighted round-robin, minimum queue, random, delay-first, fixed threshold, minimum delay, minimum queue, congestion window, reinforcement learning, or historical traffic prediction models. A target path is dynamically selected for each data packet, allowing different data packets from the same data stream to be distributed across multiple available paths. Simultaneously, the receiving end caches and reorders data packets belonging to the same sequence field based on the flow identifier, sequence field identifier, and intra-domain sequence number carried by the data packet. This ensures that only data packets arriving in the order of their intra-domain sequence numbers are submitted to the upper layer (such as TPU on-chip memory or computing units). This achieves multi-path load balancing and improves bandwidth utilization while ensuring the correctness of PCIe sequence field constraints and business logic, avoiding data errors or confusion in correspondence caused by out-of-order submissions.

[0042] In summary, this application achieves controlled packet distribution at the TLP / data block granularity by introducing flow identifiers, sequence field identifiers, and intra-domain sequence numbers. This not only breaks through the coarse-grained load balancing of existing technologies that only use flow, task, or DMA descriptors as units, but also avoids the out-of-order risk of simple per-packet distribution through sequence field boundaries and receiver reordering mechanisms. At the same time, by calculating path weights based on real-time collected path states, the sender can dynamically perceive the congestion level of each path and select the target path accordingly. This solves the problems of single-flow single-path dependence, inaccurate congestion feedback, and low fault recovery efficiency in existing technologies, thereby significantly improving multi-path bandwidth utilization, reducing tail latency, and ensuring the correctness of PCIe order constraints.

[0043] In some embodiments, the data transmission control method further includes: receiving congestion information generated by the transmission node when path congestion is detected, and receiving acknowledgment information returned by the receiving end based on the flow identifier and the sequence field identifier; wherein the acknowledgment information includes positive acknowledgment and negative acknowledgment, the positive acknowledgment indicating that the data packet is correctly received, and the negative acknowledgment indicating that the data packet has timed out, is missing, or has a verification error; adjusting the path weight of the candidate path according to the congestion information and the acknowledgment information; and retransmitting the corresponding data packet on the original path or the backup path when the negative acknowledgment is received.

[0044] Understandably, during data transmission, the sending end is not only responsible for packet distribution but also receives congestion information from transmission nodes (such as intermediate switching nodes or TPU I / O modules) (generated when queue depth exceeds a threshold, credit is insufficient, or link degradation is detected), as well as acknowledgment information from the receiving end (ACK indicates that the data packet was received correctly, and NACK indicates timeout, missing data, or verification anomaly). The sending end dynamically adjusts the path weights of corresponding candidate paths based on this feedback: for paths with high congestion information or frequent NACKs, their weights are reduced to decrease transmission volume; for normal paths, their weights are maintained or increased. When a NACK is received, the sending end can choose to retransmit the corresponding data packet on the original path or a backup path. Its function is to form a closed-loop congestion feedback and dynamic speed adjustment mechanism, enabling the sending end to perceive path quality in real time and respond quickly, thereby avoiding congestion escalation, reducing retransmission delays, improving the overall robustness and efficiency of transmission, and ensuring that data ultimately arrives correctly.

[0045] In some embodiments, adjusting the path weight of the candidate path based on the congestion information and the confirmation information includes: when a candidate path is detected to have consecutive negative confirmations, an increase in the number of replays, or an increase in the congestion information, reducing the path weight of the candidate path until it is suspended from use; and gradually restoring its path weight after the candidate path stabilizes.

[0046] Understandably, after receiving congestion information and ACK / NACK confirmation information, the sending end dynamically adjusts the path weights of candidate paths. Specifically, when a candidate path experiences consecutive NACKs (negative acknowledgments), an increase in replay counts, or a rise in congestion information, it indicates that the path is severely congested, the link is degraded, or errors are frequent. In this case, the sending end will gradually reduce the path weight of the path until it is suspended from use. When the path subsequently recovers and stabilizes (e.g., NACKs decrease, congestion information decreases, and replay counts return to normal), its path weight is gradually restored, allowing it to re-participate in data packet transmission. Its purpose is to enable the sending end to automatically avoid paths with degraded quality, preventing further congestion or triggering more retransmissions, while simultaneously allowing for timely reuse when paths recover, thereby improving overall transmission robustness, reducing tail latency, and ensuring the continuous effectiveness of multi-path load balancing.

[0047] In some embodiments, the path weight is calculated as follows: the path weight equals the product of a first preset coefficient and the available credit value, plus the product of a second preset coefficient and the path bandwidth, minus the product of a third preset coefficient and the queue depth, minus the product of a fourth preset coefficient and the error count, and minus the product of a fifth preset coefficient and the number of retransmissions or negative acknowledgments; wherein, the available credit value represents the currently available credit limit of the path, the path bandwidth represents the transmission bandwidth capacity of the path, the queue depth represents the queue length of data packets to be transmitted on the path, the error count represents the number of transmission errors that have occurred on the path, and the number of retransmissions or negative acknowledgments represents the number of retransmissions or negative acknowledgments that have been triggered on the path.

[0048] Understandably, the path weight is calculated using a weighted combination formula: Path Weight = a × Available Credit Value + b × Path Bandwidth - c × Queue Depth - d × Error Count - e × Number of Retransmissions or Negative Acknowledgments, where a, b, c, d, and e are preset coefficients. Available Credit Value reflects the remaining capacity of the receiver's buffer resources, path bandwidth represents the link's transmission capacity, queue depth reflects the current path's queuing congestion level, and error count and retransmission / NACK count characterize the path's reliability and error frequency.

[0049] This formula integrates multiple real-time metrics affecting path transmission quality. Available credit and path bandwidth are positive metrics, reflecting the sufficiency of receiver buffer resources and the transmission capacity of the link, respectively; therefore, their weights are positively correlated. Queue depth, error count, and retransmission / negative acknowledgment count are negative metrics, reflecting the path's congestion level, reliability, and error frequency, respectively; therefore, their weights are negatively correlated. This weighted combination quantifies the real-time status of the path into a comprehensive score, enabling the packet distribution and scheduling module to dynamically and accurately select paths with low congestion, high bandwidth, and few errors to send data packets. This avoids allocating data packets to congested or faulty paths, achieving multi-path load balancing, reducing tail latency, and improving overall transmission robustness.

[0050] In some embodiments, in step S103, selecting a target path from the candidate paths for each data packet based on the path weight and sending it includes: when the data packets belong to the same sequence field identifier and have sequential dependencies, distributing multiple data packets in the same data stream to different candidate paths according to the path weight of the candidate paths, so that the receiving end reorders the received data packets according to the stream identifier, the sequence field identifier and the in-domain sequence number to restore the original order of data packets within the same sequence field identifier and submit them.

[0051] Understandably, when data packets to be transmitted belong to the same sequence field identifier and have strict order dependencies, the sender dynamically distributes multiple data packets in the same data stream to different candidate paths based on the path weights of the candidate paths, rather than binding them to a single path. The receiver, on the other hand, buffers and reorders out-of-order data packets based on the flow identifier, sequence field identifier, and intra-domain sequence number carried by the data packets, ensuring that only data packets in intra-domain sequence number order are submitted to the upper layer (such as TPU on-chip memory or computing units), thereby restoring the original submission order of data packets within the same sequence field. Its function is to achieve multi-path load balancing, improve bandwidth utilization, and reduce tail latency while strictly ensuring the correctness of PCIe order constraints and business logic, avoiding data errors or confusion in correspondence caused by out-of-order submissions, thus solving the out-of-order risk caused by simple packet-by-packet distribution in existing technologies.

[0052] In some embodiments, step S103, which involves selecting a target path from the candidate paths for each data packet based on the path weight, includes: when the data packet has a loose order attribute, belongs to different address windows, or belongs to different service queues, distributing data packets with different order field identifiers in the same data stream to different candidate paths in an unordered manner, so that the receiving end does not perform reordering within the order field for the data packets, but submits them directly according to the arrival order.

[0053] Understandably, when data packets to be transmitted have relaxed ordering attributes, belong to different address windows, or are in different service queues, these packets are assigned to different sequence field identifiers. Since the PCIe protocol allows such out-of-order transmission of packets, the sender is not bound by order constraints and can distribute packets with different sequence field identifiers within the same data stream to different candidate paths in no particular order. Upon receiving these packets, the receiver does not perform reordering operations within the sequence field and directly submits them to the upper layer (such as TPU on-chip memory or computing units) in the order of arrival. Its purpose is to fully utilize the parallel transmission capability of multiple paths while strictly adhering to PCIe ordering rules, reducing the buffering overhead and processing latency of receiver reordering, thereby further improving bandwidth utilization and transmission efficiency. It is suitable for data types with relaxed order requirements (such as non-critical intermediate results).

[0054] In some embodiments, step S101, generating a flow identifier, a sequence field identifier, and an intra-domain sequence number for each data packet, includes: parsing the header and context information of each data packet, and extracting at least one of a request identifier, address, tag, queue number, service type, traffic category, and sequence attribute; generating a flow identifier for each data packet based on at least one of the request identifier, address, tag, queue number, service type, and traffic category; assigning the same sequence field identifier to data packets with sequential dependencies, and assigning different sequence field identifiers to data packets that are allowed to be submitted out of order, based on the sequence attribute; and assigning an in-domain sequence number to each data packet within the sequence field identifier in an ascending order.

[0055] Understandably, at the sending end, each data packet to be transmitted first undergoes header and context information parsing to extract key fields such as request ID, address, tag, queue number, service type, traffic class, and sequence attributes. A unique flow ID is generated based on at least one of these fields (e.g., request ID, address, tag) to distinguish different data flows. Subsequently, based on the data packet's sequence attributes: for packets with strict order dependencies, the same order domain identifier is assigned to ensure they belong to the same order domain; for packets that allow out-of-order submission, different order domain identifiers are assigned, thus achieving isolation at the order domain level. Finally, within each order domain identifier, each data packet is assigned an incrementally increasing sequence number for the receiving end to reorder and submit in order. Its purpose is to provide a precise identification basis for subsequent packet distribution scheduling and receiver reordering, enabling the sending end to perform controlled distribution based on order domain boundaries, and the receiving end to correctly restore the original order of data packets based on the flow identifier and the sequence number. This achieves multi-path load balancing while strictly ensuring the correctness of PCIe order constraints and business logic.

[0056] In some embodiments, the transmission node generates congestion information when it detects congestion, including: generating the congestion information when the transmission node detects that the queue length of the node on the candidate path exceeds a first threshold, the available credit value is lower than a second threshold, the link rate decreases by a third threshold, or the number of link layer error replays exceeds a fourth threshold; wherein the congestion information is transmitted to the sending end through an internal sideband field, a vendor-defined message, a completion extension field, an acknowledgment information, a status register, an interrupt signal, an extended message signal interrupt message, or a firmware mailbox mechanism.

[0057] Understandably, transmission nodes (such as intermediate switching nodes or TPU I / O modules) generate congestion information when they detect congestion conditions on candidate paths. Specific conditions include: queue length exceeding a first threshold, available credit value falling below a second threshold, link rate reduction exceeding a third threshold, or the number of link-layer error replays exceeding a fourth threshold. The generated congestion information can be transmitted to the sender through various means, such as internal sideband fields, vendor-defined messages, completion extended fields, ACK / NACK messages, status registers, interrupt signals, MSI-X (Extended Message Signal Interruption) messages, or firmware mailbox mechanisms. Its purpose is to enable the sender to know the congestion level on specific paths in real time, thereby dynamically adjusting path weights and transmission strategies based on this feedback information. This avoids sending data packets to congested paths, achieving precise path-level congestion control and improving overall transmission efficiency and robustness.

[0058] In other embodiments, this application extends the Quality of Service (QoS) by setting different priorities for different data types in AI training (such as training samples, model parameters, gradient data, control messages, and storage access), ensuring that critical data receives higher priority transmission services. At the same time, different traffic classes can each adopt independent distribution strategies (i.e., how data is distributed across multiple paths) and reordering windows (buffers for handling out-of-order packets), thereby ensuring low latency for high-priority data while taking into account the order and bandwidth requirements of different traffic, achieving refined transmission quality assurance.

[0059] It should be noted that PCIe, as a high-speed interconnection protocol, has strict TLP order constraints at its transaction layer, a correspondence between non-posted requests and completion responses, credit-based flow control, and a link-layer replay mechanism. These characteristics mean that the packet-by-packet distribution mechanism in traditional networks cannot be simply copied into PCIe transmission. Therefore, this application makes improvements, fully considering the requirements of order fields, credit management, and error recovery, thereby ensuring the correctness of data submission and link stability while achieving multi-path load balancing. Specifically: To address the order constraints of the PCIe transaction layer, this application introduces a sequence domain identifier and an intra-domain sequence number mechanism. Unlike the unconstrained packet-by-packet distribution in traditional networks, this application assigns a sequence domain identifier and an intra-domain sequence number to each data packet. For data packets with strict order dependencies, the same sequence domain identifier is assigned, and the receiver only submits the packet after the intra-domain sequence number arrives in the correct order and passes verification. For data packets that allow out-of-order delivery (such as those with RelaxedOrdering attributes, different address windows, or different service queues), different sequence domain identifiers are assigned, allowing out-of-order arrival across paths and direct submission. This design achieves multi-path load balancing while strictly guaranteeing the TLP order constraints and completion correspondence of the PCIe transaction layer.

[0060] To address the PCIe credit-based flow control mechanism, this application incorporates available credit value into the path weight calculation as a key positive factor. Traditional PCIe credit-based flow control only reflects local buffer resources and cannot guide global path selection. In this application, the available credit value is used as a positive factor in the path weight formula (Path Weight = a × Available Credit Value + b × Path Bandwidth - c × Queue Depth - d × Error Count - e × Number of Retransmissions or Negative Acknowledgments). This allows the sender to perceive the real-time credit reserve of each candidate path, thereby avoiding sending data packets to paths with insufficient credit and preventing transmission congestion caused by credit exhaustion at the source.

[0061] To address link-layer error recovery requirements, this application uses error count and retransmission / negative acknowledgment count as negative factors of path weights and supports path-level retransmission. When a path experiences consecutive negative acknowledgments, an increase in the number of link-layer error replays, or a rise in congestion information, the sender automatically reduces the path weight until it is suspended. Simultaneously, the sender can retransmit timed-out or failed-checked data packets on the original or backup path. This closed-loop feedback mechanism (sender distributes → transmission node generates congestion information → receiver returns acknowledgment information → sender dynamically adjusts path weights) significantly improves robustness and recovery efficiency in link anomaly scenarios.

[0062] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a data transmission control method according to another exemplary embodiment. The data transmission control method of this application, based on a receiving end, includes steps S201-S203: S201, the receiving end selects a target path from the candidate paths based on the path status information of multiple candidate paths and sends multiple data packets. Each data packet carries a flow identifier, a sequence field identifier, and a sequence number within the field. The flow identifier is used to identify the data flow, the sequence field identifier is used to identify the sequence field boundary, and the sequence number within the field is used to identify the order of data packets within the same sequence field.

[0063] Optionally, the sending end selects multiple data packets from multiple candidate paths based on path weights to send to the target path, wherein the path weights are calculated based on the path status information of the candidate paths and are used to represent the congestion level of the path.

[0064] Understandably, the sender calculates path weights based on the path status information of candidate paths (such as available credit value, queue depth, link bandwidth, error count, and retransmission count). These path weights quantify the congestion level of a path to reflect transmission quality. Based on these path weights, the sender selects a path from multiple candidate paths for the target data packet. Before transmission, each data packet is assigned a flow ID, an order domain ID, and a sequence number. The flow ID distinguishes different data flows, the order domain ID defines the boundaries of order dependencies, and the sequence number identifies the order of data packets within the same order domain. This serves to achieve dynamic and fine-grained load balancing through path weights, preventing congestion on a single path while other paths remain idle. Simultaneously, the order domain and sequence number ensure that the receiver can correctly restore the original submission order of data packets, thereby improving bandwidth utilization, reducing tail latency, and strictly satisfying the order constraints of the PCIe transaction layer and the correctness of business logic.

[0065] S202, based on the flow identifier, the sequence field identifier, and the intra-domain sequence number, data packets within the same sequence field identifier are submitted in the order of the intra-domain sequence number.

[0066] Understandably, after receiving data packets from multiple candidate paths, the receiving end caches and sorts packets belonging to the same order domain based on the flow ID, order domain identifier, and sequence number carried by each packet. In other words, for packets within the same order domain identifier, the receiving end must strictly submit them in ascending order of the sequence number within the domain. Specifically, the receiving end maintains a cache window sorted by the sequence number within the domain. Only when the packet with the smallest sequence number within the domain has arrived and passed verification is it submitted to the upper layer (such as the TPU's on-chip memory or computing unit), and then the next sequence number within the domain is processed sequentially. This mechanism ensures that the order of data submission is consistent with the constraints of the PCIe transaction layer.

[0067] In some embodiments, the data transmission control method further includes: caching out-of-order data packets based on the flow identifier, the sequence field identifier, and the intra-domain sequence number; for data packets belonging to the same sequence field identifier and having order dependencies, reordering them based on the flow identifier, the sequence field identifier, and the intra-domain sequence number to restore the original order of data packets within the same sequence field identifier and submitting them; for data packets with loose order attributes, belonging to different address windows, or belonging to different service queues, not performing intra-sequence reordering, but directly submitting them according to their arrival order.

[0068] Understandably, after receiving data packets from multiple candidate paths, the receiving end buffers out-of-order data packets based on the Flow ID, Order Domain, and Sequence Number carried by each packet. For data packets belonging to the same Order Domain and having strict order dependencies, the receiving end reorders them in ascending order of the Sequence Number. Only after the data packet with the smaller sequence number has arrived and passed verification can subsequent data packets be verified in order, thus restoring the original submission order. For data packets with relaxed ordering attributes, belonging to different address windows or different service queues (such as non-critical intermediate results), there is no need to perform reordering within the Order Domain; they are directly submitted to the upper layer (such as TPU on-chip memory or computing units) in the order of arrival. Its purpose is to achieve multi-path parallel distribution transmission and improve bandwidth utilization while strictly ensuring the order constraints and correctness of business logic at the PCIe transaction layer. At the same time, it reduces the caching overhead and processing latency of reordering for data types that allow out-of-order delivery, thus achieving a balance between high throughput and low latency.

[0069] In summary, this application solves the technical problems of insufficient multi-path utilization, inaccurate congestion perception, difficulty in guaranteeing order constraints, and slow fault recovery in existing technologies by organically combining sequence field identification, multi-dimensional path weights, closed-loop feedback mechanisms, and differentiated reordering strategies. It achieves a synergistic technical effect of high bandwidth, low latency, strong order correctness, and high robustness. Specifically: First, in existing technologies, long-term binding of a single stream to a single path leads to localized congestion, while simple packet-by-packet distribution disrupts the TLP order and completion correspondence of the PCIe transaction layer. This application addresses this by generating a stream identifier, a sequence field identifier, and an intra-domain sequence number for each data packet, and performing controlled distribution based on path weights. This allows the same data stream to be distributed across multiple paths, while the receiving end strictly reorders and submits data according to the sequence field and intra-domain sequence number. The combination of controlled distribution and sequence field isolation improves bandwidth utilization while resolving the inherent contradiction between the PCIe protocol's order constraints and multi-path parallel transmission, achieving a balance between high throughput and strong order correctness.

[0070] Secondly, in existing technologies, PCIe credits only reflect local buffer resources, and the sender cannot perceive the congestion status of transmission nodes. This application introduces congestion information and ACK / NACK feedback. The sender adjusts the transmission rate of each path in real time according to the path weight formula, and automatically reduces the weight of a path until it is suspended when NACKs occur consecutively or congestion information increases. The closed-loop mechanism of "sender distributing data packets → transmission nodes generating congestion information → receivers providing confirmation information → sender adjusting path weights" enables congestion control granularity to be precise from overall speed reduction to path-level speed reduction, achieving faster fault recovery and lower tail latency than existing coarse-grained scheduling.

[0071] Furthermore, existing technologies process all data packets uniformly, either strictly in order (leading to bottlenecks) or completely out of order (violating order constraints). This application, based on the order attributes of data packets, reorders and submits data packets with strict order dependencies within the order field, while directly submitting data packets with loose order attributes, belonging to different address windows or different service queues, in the order of arrival. This differentiated processing simultaneously satisfies PCIe order constraints and low latency requirements, avoiding unnecessary caching overhead, and is particularly suitable for transmission scenarios with mixed order requirements in AI accelerators.

[0072] Furthermore, existing technologies rely solely on a single metric (such as credit) for scheduling. This application weights and combines five dimensions—available credit value, path bandwidth, queue depth, error count, and retransmission count—to ensure that path weights simultaneously reflect resource availability, transmission capacity, congestion level, and link health. This multi-dimensional comprehensive calculation produces a robustness effect: even if a path has sufficient credit but an increased error rate, its weight will automatically decrease, thus preventing packets from being sent to potentially faulty paths and improving the overall robustness of transmission.

[0073] Please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating a data transmission control architecture according to an exemplary embodiment. This application is not limited to a specific high-speed interconnect protocol, but is designed for general high-speed interconnect transmission units. PCIe TLP messages, CXL flit slices, NoC network messages, Chiplet interconnect packets, and DMA data blocks can all be used as transmission units. Figure 3 The illustrated architecture includes a service source, a transmitter, a transmission node, and a receiver. While maintaining compatibility with high-speed interconnect protocols such as PCIe / CXL, it achieves multi-path high-bandwidth aggregation and strictly meets the sequence constraints of high-speed interconnect protocols, as detailed below: (1) Business source end The service source end is the input side of the entire transmission process. All data to be transmitted is output from this service source end. This includes regular read and write data issued by the Host CPU / system memory, external I / O data output by the NIC / SSD / DPU, computing unit data streams generated by the TPU / GPU / NPU, as well as training samples, model parameters, gradient-type DMA queues / task queues, and all data to be transmitted is input to the interface of the sending end.

[0074] (2) Sending end The sending end includes the following modules: The data partitioning module includes a data flow identification module and a sequence domain generation module, wherein: The data stream identification module is used to divide the received data to be transmitted into multiple independent data packets belonging to the same data stream.

[0075] The sequence field generation module is used to parse the header and context information of each data packet, extract at least one of the following information: request identifier, address, tag, queue number, service type, traffic category, and sequence attribute, as the basis for determining the flow identifier; based on the parsed sequence attribute, it assigns the same sequence field identifier to data packets with sequence dependencies, and assigns different sequence field identifiers to data packets that are allowed to be submitted out of order; at the same time, within the same sequence field identifier range, it assigns an in-domain sequence number in ascending order to each data packet, and finally generates a triplet identifier system of flow identifier, sequence field identifier, and in-domain sequence number for each data packet.

[0076] The path status acquisition module is used to determine multiple candidate paths and obtain the path status information of the candidate paths. It collects and updates five types of status parameters of all candidate paths in real time: available credit value, path bandwidth, queue depth, error count, and number of retransmissions or negative acknowledgments, providing complete input for path weight calculation.

[0077] The path weight calculation module is used to obtain the path status information of the candidate path and calculate the path weight of the candidate path based on the path status information, wherein the path weight is used to represent the congestion level of the path.

[0078] The packet distribution and scheduling module performs controlled distribution operations based on path weights, including: for data packets with sequential dependencies within the same sequence field identifier, distributing multiple data packets from the same data stream to different candidate paths for the receiving end to reorder and restore the original order; for data packets with loose order attributes that belong to different address windows or different service queues, distributing data packets with different sequence field identifiers to different candidate paths in no order for the receiving end to submit directly according to the arrival order.

[0079] Furthermore, the sending end receives the acknowledgment information (ACK / NACK) returned by the receiving end, as well as the congestion information generated by the transmission node, and performs dynamic adjustment of the path weight, including: when a certain path continuously receives negative acknowledgments, the number of replays increases, or the congestion information rises, the weight of the path is automatically reduced until it is suspended from use. After the path stabilizes, its path weight is gradually restored. When a negative acknowledgment occurs, the corresponding data packet is directly triggered to be retransmitted on the original path or the backup path.

[0080] (3) Transmission Node For the intermediate transmission link layer, multiple candidate transmission paths are provided in parallel. These multiple candidate paths (such as path A to path N) cover various physical / logical paths, including PCIe / CXL ports or links, NoC virtual networks / on-chip routing, Chiplet / UCIe / Die-to-Die interconnects, DPU / Switch internal links, or custom interconnects. All distributed and allocated data packets are transmitted in parallel on multiple paths, achieving multi-path aggregation of total bandwidth.

[0081] The congestion information generation module is used to detect the queue length, available credit value, link rate, and link layer error replay count of the current path in real time based on all transmission nodes. When the corresponding indicators exceed the preset threshold, congestion information is generated and transmitted back to the sending end through internal sideband fields, vendor-defined messages, completion extension fields, acknowledgment information, status registers, interrupt signals, extended message signals, interrupt messages, or firmware mailbox mechanisms, providing the sending end with accurate end-to-end congestion awareness capability for dynamically adjusting path weights.

[0082] Optionally, the congestion information generation module can send the generated congestion information directly to the sender, or it can send the generated congestion information to the receiver, which will then forward it to the sender.

[0083] (4) Receiver The receiver includes the following modules: The receiving module is used to buffer all data packets arriving asynchronously from multiple candidate paths. Based on the flow identifier, sequence field identifier, and intra-domain sequence number carried by each data packet, it automatically detects out-of-order data packets and whether data packets are missing.

[0084] The reordering module is used to reorder data packets that belong to the same sequence field identifier and have order dependencies based on the flow identifier, sequence field identifier, and sequence number within the field, and then submit them after restoring the original order of the data packets within the same sequence field. For data packets with loose order attributes that belong to different address windows or different service queues, the reordering operation within the sequence field is not performed, and the data packets are directly submitted according to their arrival order, thereby minimizing buffer overhead and transmission latency.

[0085] The data submission module is used to submit the processed data packets to the upper layer (such as on-chip memory, computing unit, or DMA completion queue) to complete the final delivery of business data.

[0086] The acknowledgment message generation module is used to return acknowledgment information based on the flow identifier and the sequence field identifier; wherein the acknowledgment information includes positive acknowledgment and negative acknowledgment, the positive acknowledgment is used to indicate that the data packet was received correctly, and the negative acknowledgment is used to indicate that the data packet timed out, was missing or had a verification error, and the acknowledgment information is sent back to the sending end to form a complete closed-loop feedback link, supporting the sending end to complete dynamic weight adjustment and missing data packet retransmission logic.

[0087] Please refer to Figure 4 , Figure 4 This is a data flow timing diagram illustrated according to an exemplary embodiment, including the following steps S401~S412: S401, the service source submits the data to be transmitted to the sending end.

[0088] S402, the sending end splits the received data to be transmitted into multiple data packets of the same data stream, and generates a triplet identifier of stream identifier, sequence field identifier and intra-domain sequence number for each data packet.

[0089] Specifically, the sending end first parses the header and context information of each data packet, extracts fields such as request identifier, address, tag, queue number, service type, traffic category, and sequence attribute, and generates a flow identifier that can uniquely identify the data stream based on fields such as request identifier and address. Based on the sequence attribute, it assigns the same sequence field identifier to data packets with order dependencies and assigns an independent sequence field identifier to data packets that are allowed to be submitted out of order. Then, it assigns an in-order sequence number in each sequence field, providing a unique index basis for subsequent multipath scheduling and receiver reordering.

[0090] S403, the sending end actively reads real-time path status information from all candidate paths.

[0091] The data collection dimensions include five core parameters: available credit value, path bandwidth, queue depth, error count, and retransmission count. Specifically, all data collection dimensions are the input parameters required for path weight calculation, ensuring that the subsequent weight calculation results accurately reflect the current real-time congestion level and transmission capacity of each candidate path.

[0092] S404 returns a summarized full path status table to the sending end and reports the real-time operating parameters of all candidate paths.

[0093] Specifically, real-time status data scattered across candidate paths are uniformly aggregated and delivered to the sending end, providing standardized structured input for subsequent path weight calculations and avoiding the problem of weight calculation distortion due to missing status parameters.

[0094] S405, the sending end calculates the real-time path weight of each candidate path based on the path weight calculation formula, and distributes different data packets to the corresponding candidate paths according to the weight ratio.

[0095] Specifically, the numerical calculation is completed according to the path weight calculation formula: "Path weight = first preset coefficient × available credit value + second preset coefficient × path bandwidth - third preset coefficient × queue depth - fourth preset coefficient × error count - fifth preset coefficient × number of retransmissions or negative acknowledgments". The higher the weight, the lower the current congestion level and the stronger the transmission capacity of the corresponding path. Data packets will be preferentially allocated to high-weight paths for transmission, thereby achieving load balancing scheduling of traffic.

[0096] S406 carries multiple data packets, including a flow identifier, a sequence field identifier, and a sequence number triplet, and forwards them to the receiving end in parallel through multiple candidate paths.

[0097] Specifically, multipath transmission includes: for data packets with sequential dependencies and the same sequence field, the sender distributes them to different candidate paths for parallel transmission, maximizing the potential of multipath bandwidth; for data packets with loose sequence attributes that belong to different address windows or different service queues, the sender directly distributes data packets with different sequence field identifiers to candidate paths in no particular order, eliminating unnecessary sequence binding overhead from the source.

[0098] S407: Transmission nodes on the transmission path monitor their local operating status in real time and generate corresponding congestion information when congestion threshold conditions are triggered.

[0099] Specifically, when a transmission node detects any of the following conditions: the local queue length exceeds the first threshold, the available credit value is lower than the second threshold, the link rate is lower than the third threshold, or the number of link layer error replays exceeds the fourth threshold, it will generate congestion information. This congestion information can be transmitted to the sender through various carriers such as internal sideband fields, vendor-defined messages, completion extension fields, and acknowledgment information, allowing the sender to perceive the path congestion situation, which is much faster than the traditional congestion perception mechanism that relies on packet loss feedback.

[0100] S408: Data packets transmitted via multipath arrive at the receiving end out of order. The receiving end performs buffering based on the flow identifier, sequence field identifier, and intra-field sequence number carried in the data packets.

[0101] Specifically, the receiving end does not directly discard out-of-order data packets. Instead, it temporarily stores the data packets in the corresponding cache partition using the triple identifier as an index. This avoids missing or lost packets and can quickly locate the missing data packet number, providing a basis for subsequent differentiated submissions that require ordered data packets and allow unordered data packets.

[0102] S409, the receiving end performs differential processing on the buffered data packets, restores the corresponding order requirements, and delivers them to the upper layer (such as the target AI accelerator or storage computing unit).

[0103] Specifically, for data packets with order dependencies within the same sequence field identifier, the receiving end performs a reordering operation based on the sequence number within the field, restores the original order of the data packets, and then submits them to the upper layer; for data packets with loose order attributes, the receiving end completely skips the reordering process and submits them directly to the upper layer according to the arrival order of the data packets, which greatly reduces the buffer usage and processing latency of the receiving end.

[0104] S410, the receiving end returns confirmation information to the sending end, which includes positive acknowledgment (ACK) and negative acknowledgment (NACK).

[0105] Specifically, the positive acknowledgment ACK is used to inform the sender that the corresponding data packet has been correctly received, and can also simultaneously carry the path running status data statistically collected by the receiver; the negative acknowledgment NACK is used to indicate three types of abnormal conditions of data packet: timeout, missing, and checksum error, so that the sender can quickly locate the problematic data packet without waiting for the timer to expire for a long time.

[0106] S411, the sending end dynamically adjusts the path weights of each candidate path based on the received congestion information and the acknowledgment information returned by the receiving end, thereby completing the dynamic speed adjustment of the transmission process.

[0107] Specifically, if a candidate path is detected to have consecutive negative acknowledgments, an increase in retransmissions, and a continuous rise in congestion information, the sender will gradually reduce the weight of that path until it is completely suspended from using that path to transmit traffic. After the path's operation stabilizes, its weight will be gradually increased in a gradient manner to avoid network oscillations caused by weight jumps.

[0108] When the receiving end detects that a data packet with a sequence number within a certain field has timed out and has not arrived, it will proactively send a negative acknowledgment (NACK) to the sending end, triggering the retransmission process at the sending end. Specifically, after receiving this type of NACK, the sending end can flexibly choose to retransmit the corresponding data packet on the original transmission path, or it can switch to another backup path with better status to complete the retransmission, further reducing the probability of congestion waiting during retransmission and significantly improving the transmission reliability under high load scenarios.

[0109] The data transmission control device provided in this application is described below. The data transmission control device described below can be referred to in correspondence with the data transmission control method described above.

[0110] Please refer to Figure 5 , Figure 5 This is a block diagram illustrating a data transmission control device according to an exemplary embodiment. The data transmission control device, applied at the sending end, includes a data partitioning module 501, a path status acquisition module 502, and a packet distribution and scheduling module 503.

[0111] For example, the data partitioning module 501 is used to partition the received data to be transmitted into multiple data packets of the same data stream, and generate a stream identifier, a sequence field identifier, and an intra-domain sequence number for each data packet, wherein the stream identifier is used to identify the data stream, the sequence field identifier is used to identify the sequence field boundary, and the intra-domain sequence number is used to identify the order of data packets within the same sequence field.

[0112] For example, the path status acquisition module 502 is used to determine multiple candidate paths and obtain the path status information of the candidate paths.

[0113] For example, the packet distribution and scheduling module 503 is used to select a target path from the candidate paths for each data packet based on the path status information and send it, so that the receiving end submits the data packets within the same sequence field identifier in the order of the intra-domain sequence number according to the flow identifier, the sequence field identifier and the intra-domain sequence number.

[0114] Specifically, it also includes a path weight calculation module, which is used to calculate the path weight of the candidate path based on the path status information, wherein the path weight is used to represent the congestion level of the path; and based on the path weight, select a target path from the candidate paths for each data packet and send it.

[0115] Specifically, the path status acquisition module is used to determine multiple candidate paths and obtain the path status information of the candidate paths. It collects and updates five types of status parameters of all candidate paths in real time: available credit value, path bandwidth, queue depth, error count, and number of retransmissions or negative acknowledgments, providing complete input for path weight calculation.

[0116] Specifically, the path weight is calculated as follows: the path weight equals the product of the first preset coefficient and the available credit value, plus the product of the second preset coefficient and the path bandwidth, minus the product of the third preset coefficient and the queue depth, minus the product of the fourth preset coefficient and the error count, and minus the product of the fifth preset coefficient and the number of retransmissions or negative acknowledgments.

[0117] Specifically, the packet distribution and scheduling module 503 is also used to: distribute multiple data packets of the same data stream to different candidate paths for data packets with sequential dependencies within the same sequence field identifier, so that the receiving end can reorder and restore the original order; and distribute data packets with loose order attributes, belonging to different address windows or different service queues to different candidate paths in no order for the receiving end to submit directly according to the arrival order.

[0118] Specifically, it also includes a path weight adjustment module, which is used to receive congestion information generated by the transmission node when path congestion is detected, and to receive acknowledgment information returned by the receiving end based on the flow identifier and the sequence field identifier; wherein the acknowledgment information includes positive acknowledgment and negative acknowledgment, the positive acknowledgment is used to indicate that the data packet is correctly received, and the negative acknowledgment is used to indicate that the data packet has timed out, is missing, or has a checksum error; the path weight of the candidate path is adjusted according to the congestion information and the acknowledgment information; when the negative acknowledgment is received, the corresponding data packet is retransmitted on the original path or the backup path; wherein the specific method of adjusting the path weight is as follows: when a candidate path is detected to have consecutive negative acknowledgments, an increase in the number of replays, or an increase in the congestion information, the path weight of the candidate path is reduced until it is suspended from use; when the candidate path recovers and stabilizes, its path weight is gradually restored.

[0119] Please refer to Figure 6 , Figure 6 This is a block diagram illustrating a data transmission control device according to another exemplary embodiment. The data transmission control device, applied at a receiving end, includes a receiving module 601 and a reordering module 602.

[0120] For example, the receiving module 601 is used to receive multiple data packets sent by the sending end from the candidate paths based on the path status information of multiple candidate paths, selecting the target path. Each data packet carries a flow identifier, a sequence field identifier, and a sequence number within the field, wherein the flow identifier is used to identify the data flow, the sequence field identifier is used to identify the sequence field boundary, and the sequence number within the field is used to identify the order of data packets within the same sequence field.

[0121] For example, the reordering module 602 is used to submit data packets within the same sequence field identifier in the order of the intra-domain sequence number according to the flow identifier, the sequence field identifier, and the intra-domain sequence number.

[0122] Specifically, it also includes a data submission module, which is used to submit the processed data packets to the upper layer.

[0123] Specifically, it also includes an acknowledgment message generation module, used to return acknowledgment information based on the flow identifier and the sequence field identifier; wherein the acknowledgment information includes positive acknowledgment and negative acknowledgment, the positive acknowledgment is used to indicate that the data packet was received correctly, and the negative acknowledgment is used to indicate that the data packet timed out, was missing or had a verification error, and the acknowledgment information is sent back to the sending end.

[0124] In summary Figure 5 and Figure 6 In the data transmission control device of this application, the sending end generates flow identifiers, sequence field identifiers, and intra-domain sequence numbers for data packets through a data partitioning module. The path status acquisition module acquires real-time status parameters such as available credit value, bandwidth, queue depth, error count, and retransmission count for candidate paths. The path weight calculation module calculates dynamic weights based on these parameters. The packet distribution and scheduling module selects a target path for each data packet based on the weights and performs multi-path distribution for sequentially dependent data packets. Simultaneously, the path weight adjustment module dynamically adjusts the weights and triggers retransmissions based on congestion information and ACK / NACK feedback returned by the receiving end. The receiving end receives data packets from different paths through a receiving module. The reordering module submits data packets within the same sequence field in order based on the flow identifier, sequence field identifier, and intra-domain sequence number. The acknowledgment message generation module generates ACK / NACK messages and sends them back to the sending end.

[0125] Compared to existing technologies, this application achieves fine-grained order control by introducing a sequence field identifier, supporting flexible transmission of partially ordered and partially out-of-order data within the same data stream; based on dynamic weight calculation using multi-dimensional path states and closed-loop feedback, it achieves efficient load balancing and congestion avoidance; the controlled distribution strategy fully utilizes multi-path bandwidth while ensuring order dependencies, reducing reordering buffer pressure and end-to-end latency, and significantly improving data transmission throughput, reliability, and real-time performance.

[0126] Embodiments of this application also provide an electronic device, including a processor and a memory; the memory is used to store a computer program executable by the processor; the processor is used to execute the computer program in the memory to implement the data transmission control method described in any of the above embodiments.

[0127] Embodiments of this application also propose a computer-readable storage medium that, when an executable computer program in the storage medium is executed by a processor, enables the data transmission control method described in any of the above embodiments.

[0128] Embodiments of this application also propose a computer program product, including a computer program that, when executed by a processor, implements a data transmission control method for a universal serial bus interface according to any of the above embodiments.

[0129] Regarding the apparatus in the above embodiments, the specific manner in which the processor performs the operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0130] Embodiments of this application also provide an electronic device 700, such as... Figure 7 As shown, the electronic device 700 includes a memory 701 and a processor 702. The memory 701 is used to store computer programs executable by the processor 702; the processor 702 is used to execute the computer programs in the memory 701 to implement the data transmission control method provided in any of the above embodiments.

[0131] The electronic device 700 also includes a communication interface 703. The processor 702, memory 701, and communication interface 703 are connected via a communication bus and communicate with each other.

[0132] Processor 702 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of programs in the above scheme.

[0133] The communication interface 703 is used to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc.

[0134] The memory 701 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory may exist independently and be connected to the processor via a bus. The memory may also be integrated with the processor.

[0135] In this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The term "multiple" refers to two or more unless otherwise expressly defined.

[0136] The above description of the embodiments is intended to enable those skilled in the art to understand and apply this application. It will be apparent to those skilled in the art that various modifications can be easily made to these embodiments, and the general principles described herein can be applied to other embodiments without creative effort. Therefore, this application is not limited to the embodiments described herein, and any improvements and modifications made by those skilled in the art based on the disclosure of this application without departing from the scope and spirit of this application are within the scope of this application.

Claims

1. A data transmission control method, characterized in that, Applied to the sending end, the method includes: The received data to be transmitted is divided into multiple data packets of the same data stream, and a stream identifier, a sequence field identifier, and an intra-domain sequence number are generated for each data packet. The stream identifier is used to identify the data stream, the sequence field identifier is used to identify the sequence field boundary, and the intra-domain sequence number is used to identify the order of data packets within the same sequence field. Multiple candidate paths are identified, and the path status information of the candidate paths is obtained; Based on the path status information, a target path is selected from the candidate paths for each data packet and sent, so that the receiving end submits data packets within the same sequence field identifier in the order of the intra-domain sequence number according to the flow identifier, the sequence field identifier, and the intra-domain sequence number.

2. The data transmission control method according to claim 1, characterized in that, Also includes: The path weight of the candidate path is calculated based on the path status information, wherein the path weight is used to represent the congestion level of the path; Based on the path weights, a target path is selected from the candidate paths for each data packet and sent.

3. The data transmission control method according to claim 2, characterized in that, Also includes: Receive congestion information generated by the transmission node when path congestion is detected, and receive acknowledgment information returned by the receiving end based on the flow identifier and the sequence field identifier; The confirmation information includes positive confirmation and negative confirmation. The positive confirmation is used to indicate that the data packet was received correctly, and the negative confirmation is used to indicate that the data packet timed out, was missing, or had a verification error. The path weights of the candidate paths are adjusted based on the congestion information and the confirmation information. When the negative acknowledgment is received, the corresponding data packet is retransmitted on the original path or the backup path.

4. The data transmission control method according to claim 3, characterized in that, The step of adjusting the path weight of the candidate path based on the congestion information and the confirmation information includes: When a candidate path is detected to have consecutive negative acknowledgments, an increase in the number of replays, or an increase in the value of the congestion information, the path weight of the candidate path is reduced until the use of the candidate path is suspended. Once the candidate path stabilizes, its path weight is gradually restored.

5. The data transmission control method according to claim 2, characterized in that, The path weight is calculated as follows: The path weight is equal to the product of the first preset coefficient and the available credit value, plus the product of the second preset coefficient and the path bandwidth, minus the product of the third preset coefficient and the queue depth, minus the product of the fourth preset coefficient and the error count, and minus the product of the fifth preset coefficient and the number of retransmissions or negative acknowledgments. Wherein, the available credit value represents the credit limit currently available for the path, the path bandwidth represents the transmission bandwidth capacity of the path, the queue depth represents the queue length of data packets to be transmitted on the path, the error count represents the number of transmission errors that have occurred on the path, and the retransmission or negative acknowledgment count represents the number of retransmissions or negative acknowledgments that have been triggered on the path.

6. The data transmission control method according to claim 2, characterized in that, The step of selecting a target path from the candidate paths and sending each data packet based on the path weight includes: When the data packets belong to the same sequence field identifier and have a sequence dependency, multiple data packets in the same data stream are distributed to different candidate paths according to the path weight of the candidate path. This allows the receiving end to reorder the received data packets according to the stream identifier, the sequence field identifier, and the sequence number within the field, so as to restore the original order of the data packets within the same sequence field identifier and submit them.

7. The data transmission control method according to claim 2, characterized in that, The step of selecting a target path from the candidate paths and sending each data packet based on the path weight includes: When the data packets have loose order attributes, belong to different address windows, or belong to different service queues, data packets with different order field identifiers in the same data stream are distributed to different candidate paths in no particular order, so that the receiving end does not perform reordering within the order field for the data packets, but submits them directly according to the arrival order.

8. The data transmission control method according to claim 1, characterized in that, The process of generating a flow identifier, a sequence field identifier, and a sequence number within each data packet includes: Parse the header and context information of each data packet, and extract at least one of the following attributes: request identifier, address, tag, queue number, service type, traffic category, and sequence attribute; Generate a flow identifier for each data packet based on at least one of the request identifier, the address, the tag, the queue number, the service type, and the traffic category; Based on the order attribute, the same order field identifier is assigned to packets with order dependencies, and different order field identifiers are assigned to packets that are allowed to be submitted out of order; and within the order field identifier, a sequentially increasing in-field sequence number is assigned to each packet.

9. The data transmission control method according to claim 3, characterized in that, When the transmission node detects congestion, it generates congestion information, including: When a transmission node detects that the queue length of the node on a candidate path exceeds a first threshold, the available credit value is lower than a second threshold, the link rate decreases by a third threshold, or the number of link layer error replays exceeds a fourth threshold, the congestion information is generated. The congestion information is transmitted to the sending end through internal sideband fields, vendor-defined messages, completion extension fields, acknowledgment information, status registers, interrupt signals, extended message signals, interrupt messages, or firmware mailbox mechanisms.

10. A data transmission control method, characterized in that, Applied to the receiving end, the method includes: The receiving end selects a target path from the candidate paths based on the path status information of multiple candidate paths and sends multiple data packets. Each data packet carries a flow identifier, a sequence field identifier, and a sequence number within the field. The flow identifier is used to identify the data flow, the sequence field identifier is used to identify the sequence field boundary, and the sequence number within the field is used to identify the order of data packets within the same sequence field. Based on the flow identifier, the sequence field identifier, and the intra-domain sequence number, data packets within the same sequence field identifier are submitted in the order of the intra-domain sequence number.

11. The data transmission control method according to claim 10, characterized in that, Also includes: Buffer out-of-order packets based on the flow identifier, sequence field identifier, and intra-field sequence number; For data packets that belong to the same sequence field identifier and have sequence dependencies, they are reordered according to the flow identifier, the sequence field identifier, and the sequence number within the field to restore the original order of data packets within the same sequence field identifier and submit them. For data packets with loose order attributes, belonging to different address windows, or belonging to different service queues, reordering within the order field is not performed; they are submitted directly in the order of arrival.

12. A data transmission control device, characterized in that, The device, applied to the transmitting end, includes: The data partitioning module is used to divide the received data to be transmitted into multiple data packets of the same data stream, and generate a stream identifier, a sequence field identifier, and an intra-domain sequence number for each data packet. The stream identifier is used to identify the data stream, the sequence field identifier is used to identify the sequence field boundary, and the intra-domain sequence number is used to identify the order of data packets within the same sequence field. The path status acquisition module is used to determine multiple candidate paths and obtain the path status information of the candidate paths; The packet distribution and scheduling module is used to select a target path from the candidate paths for each data packet based on the path status information and send it, so that the receiving end submits the data packets within the same sequence field identifier in the order of the sequence number according to the flow identifier, the sequence field identifier and the intra-domain sequence number.

13. A data transmission control device, characterized in that, The device, applied at the receiving end, includes: The receiving module is used to receive multiple data packets sent by the sending end from the candidate paths based on the path status information of multiple candidate paths, selecting the target path from the candidate paths. Each data packet carries a flow identifier, a sequence field identifier, and a sequence number within the field. The flow identifier is used to identify the data flow, the sequence field identifier is used to identify the sequence field boundary, and the sequence number within the field is used to identify the order of data packets within the same sequence field. The reordering module is used to submit data packets within the same sequence field identifier in the order of the intra-domain sequence number, based on the flow identifier, the sequence field identifier, and the intra-domain sequence number.

14. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores a computer program executable by the processor; and the processor executes the computer program in the memory to implement the data transmission control method as described in any one of claims 1 to 9 or 10 to 11.

15. A computer-readable storage medium having a computer program stored thereon, wherein when the executable computer program in the storage medium is executed by a processor, it is capable of implementing the data transmission control method as described in any one of claims 1 to 9 or 10 to 11.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the data transmission control method as described in any one of claims 1 to 9 or 10 to 11.

Images