A lossless ethernet emulation method and system based on DPU

Abstract

This application provides a lossless Ethernet simulation method and system based on a Digital Processing Unit (DPU), relating to the field of network simulation and testing technology. The method configures a lossless Ethernet network topology including virtual switching nodes and virtual terminal nodes at the simulation orchestration layer, deploys this topology to the DPU hardware platform to establish a mapping between virtual nodes and DPU hardware resources, generates configurable RDMA test traffic according to a preset traffic model through the DPU's packet processing engine, then simulates PFC flow control behavior within the DPU hardware based on a comparison of hardware queue occupancy depth and waterline threshold, and simulates ECN congestion marking based on a comparison of queue occupancy depth and ECN marking threshold. Finally, simulation performance indicators are collected through the DPU hardware telemetry interface. This invention utilizes the DPU hardware offloading capability to achieve hardware-level fidelity lossless Ethernet simulation, which can replace physical testbeds for RDMA network performance verification and fault injection testing.

Description

Technical Field

[0001] This application relates to the field of network simulation and testing technology, and more specifically, to a lossless Ethernet simulation method and system based on a DPU. Background Technology

[0002] Lossless Ethernet is a key infrastructure supporting RoCEv2 high-performance networks. It relies on two core mechanisms, Priority-based Flow Control (PFC) and Explicit Congestion Notification (ECN), to achieve zero packet loss transmission. In scenarios such as AI training clusters, distributed storage, and high-performance computing, the performance of lossless Ethernet directly determines the computing efficiency of upper-layer applications. However, the deployment and optimization of lossless Ethernet are extremely complex. Improper PFC waterline configuration can lead to head-of-line congestion, PFC storms, or even deadlocks, while deviations in ECN threshold settings can cause a sharp drop in bandwidth utilization. Therefore, it is crucial to conduct thorough simulation verification of the lossless Ethernet network before actual deployment.

[0003] In the prior art, patent CN202411936830.5 discloses a lossless Ethernet simulation model and data processing method. This scheme constructs a switch simulation model, a terminal simulation model, and a network system simulation model, simulating lossless Ethernet functions such as flow control, fault injection, and RDMA modeling in a pure software manner on a general-purpose computing platform. However, this scheme has the following drawbacks: First, its simulation model runs on a general-purpose CPU, and all packet queue management, PFC signal generation, and ECN tag calculation are completed by software. It cannot reproduce the nanosecond-level queue depth fluctuations and micro-burst behavior that actually exist in hardware switches, resulting in a deviation of hundreds of microseconds between the simulation results of PFC triggering timing and the actual hardware. Second, the throughput of pure software simulation is limited by CPU processing power. When the simulation scale expands to multiple cascaded switching nodes and the port rate reaches 100Gbps or more, the simulation engine itself becomes a performance bottleneck and cannot achieve line-speed simulation. Third, software simulation cannot utilize the hardware's native telemetry capabilities. The acquisition of all performance data depends on software instrumentation, introducing additional measurement noise and latency overhead.

[0004] In addition, patent CN202311475068.0 discloses a high-capacity lossless switching system and method based on PFC priority flow control. This solution implements the PFC flow control mechanism of input processing, multi-level buffering and output scheduling on the actual switching chip. However, this solution is aimed at the actual deployed switching equipment. Once its hardware design is fixed, it cannot flexibly change the topology, adjust the flow control strategy or inject abnormal faults. It does not have the reconfigurable capability for diverse simulation scenarios. Moreover, the cost of building a physical testbed containing multiple actual switching devices is extremely high, usually requiring a hardware investment of hundreds of thousands or even millions of yuan.

[0005] Therefore, there is an urgent need for a lossless Ethernet emulation solution that can balance hardware-level simulation fidelity, line-speed throughput, and flexible reconfigurability. Summary of the Invention

[0006] The purpose of this application is to provide a lossless Ethernet simulation method and system based on DPU. By utilizing the native packet processing capabilities and hardware queue management mechanism of the DPU hardware platform, it achieves high-fidelity, line-speed throughput and flexible configurability lossless Ethernet simulation, solving the problems of hardware timing distortion and throughput limitation in existing software simulation solutions, while avoiding the shortcomings of high cost and rigid configuration of physical testbeds.

[0007] The first aspect of this application provides a lossless Ethernet emulation method based on DPU, including the following steps:

[0008] A virtual lossless Ethernet network topology is configured in the simulation orchestration layer, wherein the virtual lossless Ethernet network topology includes at least one virtual switching node and at least one virtual terminal node;

[0009] The virtual lossless Ethernet network topology is deployed to the DPU hardware platform, and the mapping between the virtual switching node and the DPU switching simulation engine, as well as the mapping between the virtual terminal node and the DPU terminal simulation engine, are established.

[0010] The DPU's packet processing engine generates configurable RDMA test traffic according to a preset traffic model, and injects the RDMA test traffic into the DPU's hardware queue.

[0011] Inside the DPU hardware, PFC flow control behavior is simulated based on the comparison results between the actual occupied depth of each priority hardware queue and the configured waterline threshold, including generating PFC pause frames or resume frames.

[0012] Inside the DPU hardware, ECN congestion marking is simulated based on the comparison result between the occupancy depth of the hardware queue and the ECN marking threshold, and ECN bit marking is performed on data packets in the queue that exceed the ECN marking threshold;

[0013] Simulation performance metrics are collected through the hardware telemetry interface of the DPU, including throughput, end-to-end latency, PFC pause duration, and ECN tagging ratio.

[0014] Optionally, in the DPU-based lossless Ethernet simulation method described in this application, the step of simulating PFC flow control behavior within the DPU hardware based on the comparison result between the actual occupancy depth of each priority hardware queue and the configured waterline threshold includes:

[0015] Configure multi-level waterline thresholds, which include a PFC pause waterline threshold XOFF and a PFC resume waterline threshold XON, wherein XOFF is greater than XON;

[0016] When the occupancy depth of the hardware queue exceeds the XOFF, a PFC pause frame is generated and sent to the corresponding upstream port to pause the transmission of traffic of the corresponding priority.

[0017] When the occupancy depth of the hardware queue falls below the XON, a PFC recovery frame is generated and sent to the corresponding upstream port to restore the traffic transmission of the corresponding priority.

[0018] The values ​​of XOFF and XON are dynamically adjusted based on the rate of change of the occupancy depth of the hardware queue.

[0019] Optionally, the DPU-based lossless Ethernet emulation method described in this application further includes:

[0020] The PFC deadlock condition is detected inside the DPU hardware. The PFC deadlock condition includes continuously receiving PFC pause frames within a preset time window and the queue occupancy depth not decreasing.

[0021] In response to the detection of the PFC deadlock condition, the occurrence time, duration, and priority queues involved in the PFC deadlock are recorded using the PFC deadlock condition as a test stimulus signal.

[0022] In the user-configured fault injection mode, a controllable PFC pause frame sequence is injected into a specified priority queue to test the PFC storm tolerance capability of the system under test.

[0023] Based on the injected controllable PFC pause frame sequence and the response behavior of the system under test, a PFC storm tolerance assessment report is generated.

[0024] Optionally, in the DPU-based lossless Ethernet emulation method described in this application, the virtual lossless Ethernet network topology includes at least two cascaded virtual switching nodes, and further includes:

[0025] Map the at least two cascaded virtual switching nodes to different switching simulation engine instances of the DPU;

[0026] Inject multi-priority mixed traffic between the at least two cascaded virtual switching nodes, so that the shared buffer of the downstream switching node is occupied by multiple upstream ports simultaneously;

[0027] Monitor whether head-of-line blocking occurs at the downstream switching node, including monitoring forwarding stagnation caused by a priority queue waiting for another priority queue to release its buffer;

[0028] When the head-of-line blockage is detected, the triggering condition, duration, and affected traffic priority of the head-of-line blockage are recorded.

[0029] Optionally, the DPU-based lossless Ethernet emulation method described in this application further includes:

[0030] During the simulation, PFC status signals, ECN tag rate signals, and cache occupancy trend signals are synchronously acquired from the DPU hardware telemetry interface.

[0031] The PFC status signal, the ECN tag rate signal, and the buffer occupancy trend signal are input to the fusion decision module. The fusion decision module performs weighted fusion of the three signals based on preset weights to generate a congestion level assessment result.

[0032] When the congestion level assessment result exceeds the warning threshold, a congestion warning signal is output. The congestion warning signal includes the congestion level, the dominant signal type that triggered the warning, and the identifier of the affected port.

[0033] Optionally, the DPU-based lossless Ethernet emulation method described in this application further includes:

[0034] The simulation performance metrics collected by the DPU hardware telemetry interface are sent to an external traffic analysis platform via an external data channel;

[0035] Receive traffic feature analysis results returned by the external traffic analysis platform, the traffic feature analysis results including flow completion time distribution, out-of-order rate and retransmission rate;

[0036] The flow characteristic analysis results returned by the external flow analysis platform are compared with the simulation performance indicators collected by the DPU hardware telemetry interface to generate simulation calibration parameters.

[0037] The preset flow model and the waterline threshold are adjusted based on the simulation calibration parameters to form a closed-loop calibration.

[0038] Secondly, this application provides a lossless Ethernet simulation system based on a DPU. The system includes a memory and a processor. The memory includes a lossless Ethernet simulation method program based on a DPU. When the lossless Ethernet simulation method program based on a DPU is executed by the processor, it performs the following steps:

[0039] A virtual lossless Ethernet network topology is configured in the simulation orchestration layer, wherein the virtual lossless Ethernet network topology includes at least one virtual switching node and at least one virtual terminal node;

[0040] The virtual lossless Ethernet network topology is deployed to the DPU hardware platform, and the mapping between the virtual switching node and the DPU switching simulation engine, as well as the mapping between the virtual terminal node and the DPU terminal simulation engine, are established.

[0041] The DPU's packet processing engine generates configurable RDMA test traffic according to a preset traffic model, and injects the RDMA test traffic into the DPU's hardware queue.

[0042] Inside the DPU hardware, PFC flow control behavior is simulated based on the comparison results between the actual occupied depth of each priority hardware queue and the configured waterline threshold, including generating PFC pause frames or resume frames.

[0043] Inside the DPU hardware, ECN congestion marking is simulated based on the comparison result between the occupancy depth of the hardware queue and the ECN marking threshold, and ECN bit marking is performed on data packets in the queue that exceed the ECN marking threshold;

[0044] Simulation performance metrics are collected through the hardware telemetry interface of the DPU, including throughput, end-to-end latency, PFC pause duration, and ECN tagging ratio.

[0045] Optionally, in the DPU-based lossless Ethernet simulation system described in this application, the step of simulating PFC flow control behavior within the DPU hardware based on the comparison result between the actual occupancy depth of each priority hardware queue and the configured waterline threshold includes:

[0046] Configure multi-level waterline thresholds, which include a PFC pause waterline threshold XOFF and a PFC resume waterline threshold XON, wherein XOFF is greater than XON;

[0047] When the occupancy depth of the hardware queue exceeds the XOFF, a PFC pause frame is generated and sent to the corresponding upstream port to pause the transmission of traffic of the corresponding priority.

[0048] When the occupancy depth of the hardware queue falls below the XON, a PFC recovery frame is generated and sent to the corresponding upstream port to restore the traffic transmission of the corresponding priority.

[0049] The values ​​of XOFF and XON are dynamically adjusted based on the rate of change of the occupancy depth of the hardware queue.

[0050] Optionally, the DPU-based lossless Ethernet emulation system described in this application further includes:

[0051] The PFC deadlock condition is detected inside the DPU hardware. The PFC deadlock condition includes continuously receiving PFC pause frames within a preset time window and the queue occupancy depth not decreasing.

[0052] In response to the detection of the PFC deadlock condition, the occurrence time, duration, and priority queues involved in the PFC deadlock are recorded using the PFC deadlock condition as a test stimulus signal.

[0053] In the user-configured fault injection mode, a controllable PFC pause frame sequence is injected into a specified priority queue to test the PFC storm tolerance capability of the system under test.

[0054] Based on the injected controllable PFC pause frame sequence and the response behavior of the system under test, a PFC storm tolerance assessment report is generated.

[0055] Optionally, in the DPU-based lossless Ethernet emulation system described in this application, the virtual lossless Ethernet network topology includes at least two cascaded virtual switching nodes, and further includes:

[0056] Map the at least two cascaded virtual switching nodes to different switching simulation engine instances of the DPU;

[0057] Inject multi-priority mixed traffic between the at least two cascaded virtual switching nodes, so that the shared buffer of the downstream switching node is occupied by multiple upstream ports simultaneously;

[0058] Monitor whether head-of-line blocking occurs at the downstream switching node, including monitoring forwarding stagnation caused by a priority queue waiting for another priority queue to release its buffer;

[0059] When the head-of-line blockage is detected, the triggering condition, duration, and affected traffic priority of the head-of-line blockage are recorded.

[0060] As described above, the lossless Ethernet simulation method and system based on a DPU provided in this application deploys a virtual network topology onto a DPU hardware platform, utilizes the DPU's packet processing engine to generate line-rate RDMA test traffic, and implements PFC flow control simulation and ECN congestion labeling within the DPU hardware based on the actual hardware queue depth. Finally, high-precision simulation performance indicators are collected through a hardware telemetry interface. This invention uses a DPU as the platform to achieve a flexibly reconfigurable, hardware-level fidelity lossless Ethernet simulation environment on a single hardware device. This avoids the timing distortion and throughput bottlenecks of pure software simulation schemes and eliminates the need to build expensive multi-device physical testbeds, providing an efficient and low-cost solution for RoCEv2 network performance tuning, fault injection testing, and protocol stack verification.

[0061] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

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

[0063] Figure 1 A flowchart illustrating the lossless Ethernet emulation method based on DPU provided in this application embodiment;

[0064] Figure 2 A high-level flowchart of the lossless Ethernet emulation method based on DPU provided in the embodiments of this application;

[0065] Figure 3 A schematic diagram illustrating PFC deadlock detection and generation of a PFC storm tolerance assessment report using a DPU-based lossless Ethernet simulation method provided in this application embodiment;

[0066] Figure 4 This is a schematic diagram of the structure of a lossless Ethernet simulation system based on a DPU provided in an embodiment of this application. Detailed Implementation

[0067] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

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

[0069] Firstly, please refer to Figure 1 , Figure 1 This is a flowchart of a DPU-based lossless Ethernet emulation method according to some embodiments of this application. This DPU-based lossless Ethernet emulation method is used in servers or workstations configured with a DPU hardware platform. The DPU-based lossless Ethernet emulation method includes the following steps:

[0070] S11. Configure a virtual lossless Ethernet network topology in the simulation orchestration layer. The virtual lossless Ethernet network topology includes at least one virtual switching node and at least one virtual terminal node.

[0071] S12. Deploy the virtual lossless Ethernet network topology to the DPU hardware platform, and establish the mapping between the virtual switching node and the DPU switching simulation engine, as well as the mapping between the virtual terminal node and the DPU terminal simulation engine.

[0072] S13. The DPU's packet processing engine generates configurable RDMA test traffic according to a preset traffic model, and injects the RDMA test traffic into the DPU's hardware queue.

[0073] S14. Inside the DPU hardware, PFC flow control behavior is simulated based on the comparison results between the actual occupied depth of each priority hardware queue and the configured waterline threshold, including generating PFC pause frames or resume frames.

[0074] S15. Inside the DPU hardware, based on the comparison result between the occupancy depth of the hardware queue and the ECN marking threshold, simulate ECN congestion marking, and mark the ECN bit of the data packets in the queue that exceed the ECN marking threshold.

[0075] S16. Collect simulation performance indicators through the hardware telemetry interface of the DPU. The simulation performance indicators include throughput, end-to-end latency, PFC pause duration and ECN tag ratio.

[0076] In this embodiment, the DPU hardware platform uses a data processing unit with a programmable packet processing pipeline and multi-priority hardware queues. The simulation orchestration layer runs on the host side, providing a graphical or declarative topology configuration interface. Users define the number of ports, buffer capacity, and scheduling policy of virtual switching nodes, as well as the RDMA protocol stack parameters of virtual terminal nodes, through this interface. During the topology deployment phase, the orchestration layer maps virtual switching nodes to DPU switching simulation engine instances, with each instance allocated an independent hardware queue group and buffer partition. Virtual terminal nodes are mapped to DPU terminal simulation engine instances, with each instance bound to an independent RDMA connection context and QP (Queue Pair) resource. The mapping relationship is established through the DPU's PCIe... Once the DMA channel configuration is completed and distributed, the latency of the entire deployment process is typically controlled within milliseconds. During the traffic generation phase, the preset traffic model supports specifying the source / destination terminals, message size distribution (e.g., a mix of 4KB / 64KB / 1MB), injection rate, and runtime for each RDMA flow. The DPU's packet processing engine constructs RoCEv2 packets in real time based on the traffic model, including the padding of the RDMA Extended Transport Header (RETH), IP header, and UDP header. Because the packet processing engine operates in hardware pipeline mode, it can still send packets at line speed at a single port rate of 100Gbps, which is unattainable by pure software solutions, which typically only maintain an effective throughput of 40-60Gbps under the same conditions. In the PFC simulation phase, the hardware queue depth of the DPU is maintained in real time by the packet processing engine's transmit / receive counters, with nanosecond-level update accuracy.When the queue depth exceeds the pause waterline, the DPU's flow control module can generate an IEEE 802.1Qbb standard PFC pause frame within hundreds of nanoseconds and send it through the physical port. Its response latency is on the same order of magnitude as that of a real switching chip. ECN marking is also based on hardware queue depth. When the depth exceeds the ECN marking threshold, the DPU directly sets the ECN flag in the IP header in the packet processing pipeline, without diverting the packet to the software path, ensuring zero additional latency for the marking operation. Taking a typical AI training cluster lossless network verification scenario as an example, the network scale consists of 8 GPU servers interconnected through 1 leaf switch. Each server has 2 100GbE RDMA network card ports, and All-Reduce aggregate communication is running between the servers. When implementing this solution, the user configures a topology containing 1 virtual switching node (16 ports, 100Gbps per port) and 8 virtual terminal nodes in the simulation orchestration layer. The orchestration layer deploys this topology to a single BlueField-3 chip. On the DPU, the entire deployment took approximately 200 milliseconds. The traffic model was configured in All-Reduce mode, with message sizes evenly distributed between 128KB and 4MB. The injection rate was 100% line-rate, and the runtime was 60 seconds. After the simulation, the telemetry interface output showed: average throughput of 95.8Gbps / port, average end-to-end latency of 4.2μs, 312 PFC pauses, and an ECN tagging rate of 18.7%. Compared with a physical testbed of the same scale, the deviations of all indicators were within 5%. Through this implementation scheme, the native queue management, flow control signal generation, and telemetry acquisition mechanisms within the DPU hardware work together to ensure that the simulation results are highly consistent with the real hardware in terms of PFC triggering timing, queue depth fluctuation characteristics, and micro-burst behavior. At the same time, it supports flexible adjustment of topology and parameters to adapt to different verification needs.

[0077] Please refer to Figure 2 , Figure 2 This is a high-level flowchart of a lossless Ethernet emulation method based on DPU in some embodiments of this application.

[0078] Please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating the PFC deadlock detection and generation of a PFC storm tolerance assessment report using a DPU-based lossless Ethernet simulation method in some embodiments of this application.

[0079] According to an embodiment of the present invention, the step of simulating PFC flow control behavior within the DPU hardware based on a comparison between the actual occupancy depth of each priority hardware queue and the configured waterline threshold includes:

[0080] Configure multi-level waterline thresholds, which include a PFC pause waterline threshold XOFF and a PFC resume waterline threshold XON, wherein XOFF is greater than XON.

[0081] When the occupancy depth of the hardware queue exceeds the XOFF, a PFC pause frame is generated and sent to the corresponding upstream port to pause the transmission of traffic of the corresponding priority.

[0082] When the occupancy depth of the hardware queue falls below the XON, a PFC recovery frame is generated and sent to the corresponding upstream port to restore the traffic transmission of the corresponding priority.

[0083] The values ​​of XOFF and XON are dynamically adjusted based on the rate of change of the occupancy depth of the hardware queue.

[0084] Among these improvements, multi-level dynamic waterlines are the core design enhancement of this solution. In traditional RoCEv2 deployments, XOFF / XON is typically set to fixed values ​​by network administrators based on experience, such as XOFF set to 80% of the cache capacity and XON set to 60%. However, this fixed setting exhibits significant differences in performance under different traffic patterns: In bursty traffic scenarios, an 80% XOFF setting may lead to excessively frequent PFC triggering, introducing unnecessary flow control overhead, with measured average bandwidth utilization loss reaching 15%-20%. In continuous high-traffic scenarios, a 60% XON setting may cause the queue to be in a prolonged state of pause and recovery oscillation, resulting in periodic bandwidth jitter and affecting upper-layer RDMA applications. Due to latency sensitivity, this solution employs a dynamic adjustment mechanism based on the queue depth change rate. Let the current queue depth be Q(t), and the sampling period be ΔT (100μs). The depth change rate ΔQ / ΔT is calculated by the DPU flow control management daemon at fixed intervals. The dynamic adjustment rules are as follows: First, when ΔQ / ΔT exceeds the preset aggressive growth threshold (15% / ms of the total cache capacity), it indicates that a traffic burst is rapidly filling the queue. At this time, XOFF is automatically shifted from the default 80% to the 65%-70% range to trigger PFC in advance, reserving sufficient cache to absorb subsequent bursts. Simultaneously, XON is shifted from 60% to 45%-50%, thus avoiding the impact of XOFF-XON on the queue. The oscillations are caused by excessively narrow ON intervals; secondly, when ΔQ / ΔT is lower than the preset slack threshold (set to be below 5% / ms of the total cache capacity), it indicates that the traffic is stabilizing. At this time, restoring XOFF to the default 80% and appropriately increasing XON to 65% can improve cache utilization and reduce unnecessary PFC pauses. Taking a storage cluster backend backup scenario as an example, if a distributed storage cluster performs a full backup at night, the traffic exhibits typical intermittent characteristics, that is, a batch of large files (average 64MB) is sent every 50ms, and the network is almost idle between the two batches. When using a fixed waterline (XOFF=80%, XON=60%), the simulation shows that PFC triggers are as high as 428 times / minute, and the bandwidth utilization is extremely high. The initial efficiency was only 78%. However, after switching to the dynamic waterline of this technical solution, the ΔQ / ΔT was detected to be approximately 28% / ms during each burst, exceeding the aggressive growth threshold of 15% / ms. The system automatically reduced XOFF to 67% and XON to 47%, triggering PFC to absorb the burst in advance. During the idle period between the two batches, ΔQ / ΔT was close to 0, and the system automatically restored XOFF to 80% and XON to 65%. Ultimately, the number of PFC triggers was reduced to 178 times / minute (a reduction of 58%), and the bandwidth utilization rate was increased to 91%. The deviations between the simulation results and the physical testbed measurements (bandwidth utilization rate of 92%, PFC count of 165 times / minute) were 1% and 8%, respectively, which verified the significant effect of the dynamic waterline mechanism.By dynamically adjusting the flow rate, this solution reduces the number of PFC triggers by approximately 35% in scenarios with burst traffic and compresses the bandwidth oscillation amplitude from ±12% to within ±3% in scenarios with sustained high traffic. This significantly improves the accuracy and stability of PFC flow control simulation, making the simulation results closer to the actual measured performance of real hardware switches under the same traffic model.

[0085] According to an embodiment of the present invention, it further includes:

[0086] The PFC deadlock condition is detected inside the DPU hardware. The PFC deadlock condition includes continuously receiving PFC pause frames within a preset time window and the queue occupancy depth not decreasing.

[0087] In response to the detection of the PFC deadlock condition, the occurrence time, duration, and priority queues involved in the PFC deadlock are recorded using the PFC deadlock condition as a test stimulus signal.

[0088] In the user-configured fault injection mode, a controllable PFC pause frame sequence is injected into a specified priority queue to test the PFC storm tolerance of the system under test.

[0089] Based on the injected controllable PFC pause frame sequence and the response behavior of the system under test, a PFC storm tolerance assessment report is generated.

[0090] PFC deadlock is a troublesome fault phenomenon in lossless Ethernet, but this technology reverses this problem by integrating PFC deadlock detection, recording, and controlled injection into a single testing method. Traditional network testing tools can only construct normal PFC interactions and cannot precisely control the timing, duration, and priority of PFC pause frames at the hardware level, making it difficult to assess the PFC storm tolerance boundary of the system under test. This technology utilizes the programmable interface of the DPU flow control module to support three fault injection modes during the fault injection phase, selectable by the user through the simulation orchestration layer. Mode one is continuous injection, which continuously sends PFC pause frames to a specified priority queue, observing the timeout detection mechanism, RDMA connection reconstruction behavior, and upper-layer application recovery time under complete flow stop conditions. Mode two is intermittent injection, with a configurable duty cycle (e.g., 70% pause, 30% recovery) and period (e.g., 2m). The test involves sending PFC frame sequences (per cycle) to simulate flow control oscillations under network congestion jitter scenarios. Mode 3 is cascaded injection, which involves simultaneously injecting PFC pause frames into multiple ports at the leaf and ridge layers to trigger multi-hop PFC backpressure propagation, testing the network's PFC storm diffusion suppression capability, and focusing on assessing the risk of a sudden drop in network throughput due to backpressure propagation. The generated evaluation report includes a PFC storm tolerance curve, which uses the PFC pause frame injection intensity (pause frame duty cycle, range 0%-100%) as the horizontal axis and the throughput attenuation ratio of the tested system as the vertical axis, which can intuitively reflect the elasticity boundary of the tested system. The evaluation report also includes: lock auto-recovery time (MTTR), queue backlog depth variation curves under different injection modes, a list of affected ports, and deviation analysis from theoretical expectations. Taking the robustness verification of the HPC cluster MPI communication network as an example, the cluster contains 256 compute nodes interconnected through an 8-layer Clos topology, running MPI. The AlltoAll cluster communication load test aimed to verify the recovery capability of the cluster communication layer when a PFC storm occurs in the leaf layer switch. Cascading injection mode 3 was initiated on the leaf layer virtual switch node of the simulated topology, injecting a continuous PFC pause frame into the priority 3 queue for 500ms. Simulation records showed that approximately 12ms after the injection began, the spine layer virtual switch node detected PFC backpressure, and throughput began to decrease. Approximately 85ms after the injection began, the overall cluster MPI communication throughput dropped to 23% of the normal level. Approximately 260ms after the injection stopped, the throughput fully recovered. Finally, compared with the actual measured data from the physical testbed: throughput dropped to 22% (deviation 4.5%), and the recovery time was approximately 248ms (deviation 4.5%).The 8% figure verifies the reliability of the simulation results. Through PFC deadlock detection and fault injection mechanisms, a comprehensive assessment of the robustness of lossless Ethernet is achieved without relying on external hardware fault injection devices. Actual test data shows that when using this technical solution for PFC storm tolerance testing, the test time can be reduced from 4-8 hours using traditional physical testbed methods to 30-60 minutes. Simultaneously, the critical point at which the throughput of the tested system begins to drop sharply when the PFC pause duty cycle exceeds 78% is detected.

[0091] According to an embodiment of the present invention, the virtual lossless Ethernet network topology includes at least two cascaded virtual switching nodes, and further includes:

[0092] Map the at least two cascaded virtual switching nodes to different switching simulation engine instances of the DPU;

[0093] Inject multi-priority mixed traffic between the at least two cascaded virtual switching nodes, so that the shared buffer of the downstream switching node is occupied by multiple upstream ports simultaneously;

[0094] Monitor whether head-of-line blocking occurs at the downstream switching node, including monitoring forwarding stagnation caused by a priority queue waiting for another priority queue to release its buffer;

[0095] When the head-of-line blockage is detected, the triggering condition, duration, and affected traffic priority of the head-of-line blockage are recorded.

[0096] Head-of-Line Blocking (Head-of-Line Blocking) is another serious performance issue in lossless Ethernet. It occurs when multiple upstream ports simultaneously forward traffic to the same downstream port. If the buffer overflow of one priority queue triggers PFC (Pre-Frequency Control) pause, other priority queues may also be forced to wait due to shared buffer exhaustion, leading to mutual interference between priorities. This technical solution utilizes the independence of the DPU (Digital Processing Unit) switching simulation engine instance to support the simultaneous running of simulations of multiple serial switching nodes, realistically reproducing head-of-line blocking behavior in multi-hop scenarios. Monitoring of head-of-line blocking is achieved through fine-grained counters in the DPU telemetry engine. In the priority queue, the telemetry engine samples queue length changes with a 1μs granularity. When it detects that the dequeue rate of a certain queue is consistently 0 but no PFC pause command is issued at the corresponding entry point, it determines that a head-of-queue blocking event caused by shared cache contention has occurred, and records the trigger time (100ns precision), duration (1μs precision), and affected priority number. Taking the multi-tenant isolation test of the spine leaf data center network as an example, if tenant A is running high-priority latency-sensitive RDMA storage traffic (priority 3) and tenant B is running low-priority batch data replication traffic (priority 1), at the leaf layer simulation node L1 and In the cascaded topology of node S1 in the ridge layer simulation, five ports of priority 1 traffic (50% line speed) and three ports of priority 3 traffic (90% line speed) were simultaneously injected from the eight inlet ports of L1. The simulation monitored that after approximately 35ms, the priority 1 queue filled 75% of S1's shared buffer, and the queuing delay for priority 3 traffic at the S1 outlet ports spiked from the baseline of 2.1μs to 18.7μs, indicating significant head-of-line congestion. The simulation then adjusted the shared buffer allocation strategy of S1 to: a minimum of 30% reserved buffer for the priority 3 queue, and a maximum of 60% available buffer for the priority 1 queue. After adjustment, the latency for priority 3 was restored to 3.4μs, while tenant A's SLA target (<5μs) was guaranteed. Through multi-node serial simulation capabilities, this technical solution can assess the head-of-line blocking risk on end-to-end multi-hop paths. This is a scenario that pure software simulation solutions cannot effectively support due to throughput bottlenecks. Through actual testing, it has been proven that in a 3-hop serial scenario, this technology can stably reproduce the head-of-line blocking phenomenon that inevitably occurs when the number of ingress ports of downstream switching nodes exceeds 8 and the proportion of low-priority traffic in mixed traffic exceeds 40%. The detection accuracy is less than 10% compared with the physical test bed, showing significant results.

[0097] According to an embodiment of the present invention, it further includes:

[0098] During the simulation, PFC status signals, ECN tag rate signals, and cache occupancy trend signals are synchronously acquired from the DPU hardware telemetry interface.

[0099] The PFC status signal, the ECN tag rate signal, and the buffer occupancy trend signal are input to the fusion decision module. The fusion decision module performs weighted fusion of the three signals based on preset weights to generate a congestion level assessment result.

[0100] When the congestion level assessment result exceeds the warning threshold, a congestion warning signal is output. The congestion warning signal includes the congestion level, the dominant signal type that triggered the warning, and the identifier of the affected port.

[0101] In lossless Ethernet simulation, a single indicator is often insufficient to accurately determine network congestion status. This is because the PFC status signal reflects an already occurring buffer overflow threat, but it suffers from response lag. The ECN tag rate signal detects congestion signs earlier, but after PFC takes effect, the ECN tag may be artificially reduced due to traffic pauses. The buffer occupancy trend signal provides the most direct view of buffer saturation, but it does not reflect traffic priority distribution. Therefore, the fusion decision module of this technical solution adopts a weighted fusion strategy, with the default weight configuration as follows: PFC status signal weight 0.4, ECN tag rate signal weight 0.35, and buffer occupancy trend signal weight 0.35. The occupancy trend signal weight is 0.25. After weighted fusion, a congestion index in the range of 0 to 1 is obtained. When the congestion index exceeds the preset warning threshold (default 0.7), a congestion warning is triggered. The fusion decision module runs on the ARM processor of the DPU, with a sampling period of 500μs. The CPU time for a single fusion calculation is about 8μs, which does not affect the normal simulation workload of the DPU. Taking the low-latency network monitoring of the financial exchange data center as an example, the market data distribution traffic (priority 7) and order matching traffic (priority 5) share the leaf switch port. In a simulated sudden market storm, the market data traffic from... The line rate surged from 40% to 95%, while order matching traffic remained at 55% line rate. The fusion decision module monitored in real-time that the ECN marking rate rose from 0% to 28% within 400μs, and cache usage increased from 35% to 68%. No PFC pause frames appeared, and the fusion congestion index was 0.268. After another 300μs, PFC was triggered, and the congestion index rose to 0.508. After another 150μs, the congestion index rose to 0.73, exceeding the 0.7 warning threshold. The system issued a congestion warning in advance, driving the traffic engineering controller to divert some low-priority packets to alternative paths. The order matching traffic... The jitter was reduced from a peak of 42μs to less than 8μs. If an alarm mechanism relying solely on the PFC signal is used, the alarm will be triggered approximately 1.2ms after PFC is triggered, at which point the peak order matching latency will reach 68μs, exceeding the SLA requirement. This implementation reduces false alarms by approximately 62% and the missed alarm rate by approximately 41% compared to a single-signal alarm scheme by a multi-signal fusion congestion warning mechanism. The average advance time of the warning relative to the PFC trigger time can reach 2.8ms, which provides the network controller with a more ample active scheduling window, increasing the effectiveness of traffic engineering intervention from 43% to 76%, a significant improvement.

[0102] According to an embodiment of the present invention, it further includes:

[0103] The simulation performance metrics collected by the DPU hardware telemetry interface are sent to an external traffic analysis platform via an external data channel;

[0104] Receive traffic feature analysis results returned by the external traffic analysis platform, the traffic feature analysis results including flow completion time distribution, out-of-order rate and retransmission rate;

[0105] The flow characteristic analysis results returned by the external flow analysis platform are compared with the simulation performance indicators collected by the DPU hardware telemetry interface to generate simulation calibration parameters.

[0106] The preset flow model and the waterline threshold are adjusted based on the simulation calibration parameters to form a closed-loop calibration.

[0107] Closed-loop calibration is a key mechanism to ensure the sustainable reliability of simulation results. The external traffic analysis platform receives the simulation performance index data stream in JSON format through the DPU's 100GbE out-of-band management port, completes the flow completion time FCT distribution fitting, out-of-order rate statistics, and retransmission rate analysis, and returns the analysis results to the simulation orchestration layer. The core algorithm for joint comparison is based on the least squares method. Let the mean FCT of the simulation output be FCT(sim), and the mean FCT measured by the external platform be FCT(ref). Then, the FCT deviation rate δ is calculated as follows:

[0108] ;

[0109] If δ exceeds the default deviation tolerance threshold of 5%, the calibration process is triggered: XOFF / XON is adjusted with a preset step size ΔW (default waterline step size 2% of cache capacity), the simulation is re-executed and δ is calculated, iterating until δ drops below 5%. During the calibration process, the ECN marker threshold is simultaneously calibrated to ensure that the two core parameters converge synchronously. Taking RoCEv2 network tuning of a cloud-native Kubernetes cluster as an example, when a production cluster is performing machine learning model inference, the measured FCT is 285μs, which is lower than the expected 200μs SLA target. This solution is used for tuning simulation: First, the simulation is run with default parameters (XOFF=80%, ECN threshold=40KB). The DPU telemetry output FCT(sim)=241μs. When compared with the measured results of the external traffic analysis platform, δ=15.4%. The deviation rate exceeds the 5% threshold, so calibration is triggered. The first round of calibration is: XOFF=78%, ECN=15.4%. The first round had a threshold of 38KB, FCT(sim) = 263μs, and δ = 7.7%. The second round had XOFF = 76%, ECN threshold = 36KB, FCT(sim) = 278μs, and δ = 2.5%, resulting in convergence. Applying the calibrated parameters to the production cluster, the actual FCT measurement after deployment was 192μs, achieving the SLA target. This validated the practical guiding role and effectiveness of closed-loop calibration. The closed-loop calibration mechanism ensured continuous alignment between simulation parameters and the real network state. In a typical 100Gbps, 32-node test scenario, after 5 to 8 iterations (each iteration averaging approximately 45 seconds), the FCT deviation rate converged from the initial 18%-25% to within 4%, the out-of-order rate deviation converged from the initial 22% to within 6%, and the retransmission rate deviation converged from the initial 31% to within 8%. The overall simulation accuracy after calibration was approximately 3.5 times higher than before calibration, demonstrating a significant improvement.

[0110] According to an embodiment of the present invention, the preset traffic model includes an RDMA operation type configuration item, and the step of generating configurable RDMA test traffic according to the preset traffic model through the packet processing engine of the DPU includes:

[0111] The distribution of RDMA operation types is determined based on the RDMA operation type configuration item, and the RDMA operation types include RDMA SEND, RDMA WRITE, RDMA READ, and RDMA ATOMIC operations;

[0112] Based on the RDMA operation type distribution, generate RDMA messages corresponding to the operation type, and assign message length, source QP and target QP to each RDMA message;

[0113] The generated RDMA message is encapsulated into a RoCEv2 data packet, the RETH header of which contains the operation type encoding and remote memory address information.

[0114] The network behaviors of different RDMA operation types differ significantly: RDMA WRITE and SEND are unilateral operations where the peer CPU does not participate in data transmission, but they put a lot of pressure on network bandwidth and cache; RDMA READ is a bilateral operation requiring two network interactions, ReadRequest and Read Response, and is sensitive to latency; ATOMIC operations produce extremely small packets but require the switch to provide atomicity guarantees. This solution's traffic model supports proportional mixing of these four operation types. For example, when simulating a typical distributed training scenario, a mixing ratio of "80% WRITE + 15% READ + 5% ATOMIC" can be used to make the simulated traffic closer to actual business characteristics, rather than simply generating indiscriminate background traffic.

[0115] Furthermore, according to embodiments of the present invention, it also includes:

[0116] Receive user input of a simulation test intent description, which includes the type of the object under test, the performance metrics to be monitored, and the type of the desired test scenario;

[0117] The simulation test intent is described and parsed as topology requirements, traffic requirements, and fault injection requirements.

[0118] The topology parameters of the virtual lossless Ethernet network topology are automatically generated according to the topology requirements, the traffic parameters of the preset traffic model are automatically generated according to the traffic requirements, and the corresponding fault injection rules are automatically configured according to the fault injection requirements.

[0119] The topology parameters, traffic parameters, and fault injection rules are automatically sent to the DPU hardware platform to complete the dynamic reconstruction of the simulation environment.

[0120] Intent-driven reconfiguration eliminates the need for manual configuration of each item when setting up the simulation environment. Users only need to declare the simulation intent, such as testing the PFC behavior of a 3-layer Clos topology in all-to-all traffic mode. The orchestration layer automatically completes topology generation, traffic model instantiation, and fault injection strategy matching. In practical applications, the orchestration layer maintains a pre-set scenario template library. The templates cover common test intents such as fat tree topology throughput testing, ridge leaf topology PFC deadlock testing, and single-arm ECN parameter scanning. After selecting a template, users only need to adjust a few key parameters to start the simulation. In this way, even upper-layer application developers who are not familiar with DPU low-level programming can efficiently use the simulation environment to perform performance tuning of RoCEv2 networks.

[0121] Furthermore, according to embodiments of the present invention, it also includes:

[0122] Inside the DPU hardware, a PFC pause frame loss fault is simulated, including randomly discarding the generated PFC pause frame with a preset discard probability after it is generated, in order to simulate abnormal scenarios such as link bit errors or PFC frames being incorrectly discarded by the switch.

[0123] Inside the DPU hardware, an ECN error marking failure is simulated, including marking data packets that have not reached the ECN marking threshold with ECN according to a preset error rate, or incorrectly not marking data packets that have reached the ECN marking threshold with ECN.

[0124] Inside the DPU hardware, link interruption failures are simulated, including periodically shutting down and restoring links between specified virtual switching nodes with configurable interruption duration and interval.

[0125] Fault injection is one of the core values ​​that distinguishes lossless Ethernet simulation from ordinary functional testing. In actual data center operation, although the probability of PFC pause frame loss is very low, usually below 10⁻¹², once it occurs, it may cause continuous transmission from upstream, leading to buffer overflow and packet loss, thus destroying the lossless characteristics. In software simulation, since there is no real PFC frame transmission and reception path, it is impossible to accurately assess the cascading impact after PFC frame loss. In this solution, the DPU flow control module immediately enters the drop decision after generating the PFC pause frame. The decision logic is based on a hardware random number generator and is executed with a preset probability. The dropped PFC frame will not enter the transmission queue, so the upstream port is completely unaware of the flow control request, which truly reproduces the end-to-end behavior under the PFC loss scenario. The duration of the link flash failure can be configured to be in the range of microseconds to seconds. With the hardware timestamp function of the DPU, the QoS renegotiation latency of the RoCEv2 connection after the link is restored can be accurately measured.

[0126] Furthermore, according to embodiments of the present invention, it also includes:

[0127] The simulation performance indicators are compared with the calculation results of the theoretical reference model item by item, and the simulation deviation rate of each performance indicator is calculated.

[0128] When the simulation deviation rate of any performance index exceeds the preset deviation tolerance threshold, the simulation round is marked as a state to be calibrated.

[0129] In the state to be calibrated, the waterline threshold and the ECN mark threshold are adjusted by a preset step size, the simulation is re-executed and the simulation deviation rate is calculated, and the iteration continues until the simulation deviation rate drops below the preset deviation tolerance threshold.

[0130] The final calibrated waterline threshold and ECN tag threshold are recorded as a simulation calibration parameter set, and the simulation calibration parameter set is associated with the current virtual lossless Ethernet network topology and traffic model.

[0131] Simulation calibration is a crucial step in ensuring the reliability of simulation results. The theoretical reference model can be the M / G / 1 / K model based on queuing theory or the RoCEv2 analytical model based on a fluid model, which respectively provides the theoretical expected values ​​of PFC trigger frequency and ECN tag probability. The preset deviation tolerance threshold is generally set at 10%-15%, depending on the simulation accuracy requirements. In actual parameter tuning of this solution, it was found that in a 100Gbps single-port scenario, the deviation rate can usually be converged to within 10% after about 5 to 8 iterations. The consistency between the calibrated simulation output and the measured value of the actual physical test bed can reach more than 92%. For simulation scenarios with long-term operation, this solution also supports adaptive time acceleration: during the simulation process, the stability of the flow arrival is monitored. When the flow arrival rate fluctuation is lower than the preset stability threshold in multiple consecutive sampling periods, the simulation clock advance step size is automatically increased to shorten the total time of long-cycle simulation. The time acceleration factor is usually between 2 and 10 times. After acceleration, the consistency of simulation results is verified through the aforementioned calibration mechanism to ensure that acceleration does not introduce additional simulation errors.

[0132] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a DPU-based lossless Ethernet simulation system in some embodiments of this application. Secondly, the present invention also discloses a DPU-based lossless Ethernet simulation system, which includes a memory and a processor. The memory includes a DPU-based lossless Ethernet simulation method program, which, when executed by the processor, implements the steps of the DPU-based lossless Ethernet simulation method.

[0133] This invention discloses a lossless Ethernet simulation method and system based on a Data Processing Unit (DPU). By deploying a virtual network topology onto a DPU hardware platform, utilizing the DPU's packet processing engine to generate line-rate RDMA test traffic, and implementing PFC flow control simulation and ECN congestion labeling within the DPU hardware based on actual hardware queue depth, high-precision simulation performance indicators are finally collected through a hardware telemetry interface. This invention uses the DPU as the platform to achieve a flexibly reconfigurable, hardware-level fidelity lossless Ethernet simulation environment on a single hardware device. It avoids the timing distortion and throughput bottlenecks of pure software simulation schemes and eliminates the need to build expensive multi-device physical testbeds, providing an efficient and low-cost solution for RoCEv2 network performance tuning, fault injection testing, and protocol stack verification.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0135] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0137] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0138] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

Claims

1. A lossless Ethernet emulation method based on DPU, characterized in that, Includes the following steps: A virtual lossless Ethernet network topology is configured in the simulation orchestration layer, wherein the virtual lossless Ethernet network topology includes at least one virtual switching node and at least one virtual terminal node; The virtual lossless Ethernet network topology is deployed to the DPU hardware platform, and the mapping between the virtual switching node and the DPU switching simulation engine, as well as the mapping between the virtual terminal node and the DPU terminal simulation engine, are established. The DPU's packet processing engine generates configurable RDMA test traffic according to a preset traffic model, and injects the RDMA test traffic into the DPU's hardware queue. Inside the DPU hardware, PFC flow control behavior is simulated based on the comparison results between the actual occupied depth of each priority hardware queue and the configured waterline threshold, including generating PFC pause frames or resume frames. Inside the DPU hardware, ECN congestion marking is simulated based on the comparison result between the occupancy depth of the hardware queue and the ECN marking threshold, and ECN bit marking is performed on data packets in the queue that exceed the ECN marking threshold; Simulation performance metrics are collected through the hardware telemetry interface of the DPU, including throughput, end-to-end latency, PFC pause duration, and ECN tagging ratio.

2. The lossless Ethernet emulation method based on DPU according to claim 1, characterized in that, The process of simulating PFC flow control behavior within the DPU hardware, based on a comparison between the actual occupancy depth of each priority hardware queue and the configured waterline threshold, includes: Configure multi-level waterline thresholds, which include a PFC pause waterline threshold XOFF and a PFC resume waterline threshold XON, wherein XOFF is greater than XON. When the occupancy depth of the hardware queue exceeds the XOFF, a PFC pause frame is generated and sent to the corresponding upstream port to pause the transmission of traffic of the corresponding priority. When the occupancy depth of the hardware queue falls below the XON, a PFC recovery frame is generated and sent to the corresponding upstream port to restore the traffic transmission of the corresponding priority. The values ​​of XOFF and XON are dynamically adjusted based on the rate of change of the occupancy depth of the hardware queue.

3. The lossless Ethernet emulation method based on DPU according to claim 1, characterized in that, The method further includes: The PFC deadlock condition is detected inside the DPU hardware. The PFC deadlock condition includes continuously receiving PFC pause frames within a preset time window and the queue occupancy depth not decreasing. In response to the detection of the PFC deadlock condition, the occurrence time, duration, and priority queues involved in the PFC deadlock are recorded using the PFC deadlock condition as a test stimulus signal. In the user-configured fault injection mode, a controllable PFC pause frame sequence is injected into a specified priority queue to test the PFC storm tolerance of the system under test. Based on the injected controllable PFC pause frame sequence and the response behavior of the system under test, a PFC storm tolerance assessment report is generated.

4. The lossless Ethernet emulation method based on DPU according to claim 1, characterized in that, The virtual lossless Ethernet network topology includes at least two cascaded virtual switching nodes, and the method further includes: Map the at least two cascaded virtual switching nodes to different switching simulation engine instances of the DPU; Inject multi-priority mixed traffic between the at least two cascaded virtual switching nodes, so that the shared buffer of the downstream switching node is occupied by multiple upstream ports simultaneously; Monitor whether head-of-line blocking occurs at the downstream switching node, including monitoring forwarding stagnation caused by a priority queue waiting for another priority queue to release its buffer; When head-of-line congestion is detected, the triggering conditions, duration, and affected traffic priority of the head-of-line congestion are recorded.

5. The lossless Ethernet emulation method based on DPU according to claim 1, characterized in that, The method further includes: During the simulation, PFC status signals, ECN tag rate signals, and cache occupancy trend signals are synchronously acquired from the DPU hardware telemetry interface. The PFC status signal, the ECN tag rate signal, and the buffer occupancy trend signal are input to the fusion decision module. The fusion decision module performs weighted fusion of the three signals based on preset weights to generate a congestion level assessment result. When the congestion level assessment result exceeds the warning threshold, a congestion warning signal is output. The congestion warning signal includes the congestion level, the dominant signal type that triggered the warning, and the identifier of the affected port.

6. The lossless Ethernet emulation method based on DPU according to claim 1, characterized in that, The method further includes: The simulation performance metrics collected by the DPU hardware telemetry interface are sent to an external traffic analysis platform via an external data channel; Receive traffic feature analysis results returned by the external traffic analysis platform, the traffic feature analysis results including flow completion time distribution, out-of-order rate and retransmission rate; The flow characteristic analysis results returned by the external flow analysis platform are jointly compared with the simulation performance indicators collected by the DPU hardware telemetry interface to generate simulation calibration parameters. The preset flow model and the waterline threshold are adjusted based on the simulation calibration parameters to form a closed-loop calibration.

7. A lossless Ethernet emulation system based on a DPU, characterized in that, The system includes a memory and a processor. The memory includes a DPU-based lossless Ethernet simulation method program. When the processor executes the DPU-based lossless Ethernet simulation method program, it performs the following steps: A virtual lossless Ethernet network topology is configured in the simulation orchestration layer, wherein the virtual lossless Ethernet network topology includes at least one virtual switching node and at least one virtual terminal node; The virtual lossless Ethernet network topology is deployed to the DPU hardware platform, and the mapping between the virtual switching node and the DPU switching simulation engine, as well as the mapping between the virtual terminal node and the DPU terminal simulation engine, are established. The DPU's packet processing engine generates configurable RDMA test traffic according to a preset traffic model, and injects the RDMA test traffic into the DPU's hardware queue. Inside the DPU hardware, PFC flow control behavior is simulated based on the comparison results between the actual occupied depth of each priority hardware queue and the configured waterline threshold, including generating PFC pause frames or resume frames. Inside the DPU hardware, ECN congestion marking is simulated based on the comparison result between the occupancy depth of the hardware queue and the ECN marking threshold, and ECN bit marking is performed on data packets in the queue that exceed the ECN marking threshold; Simulation performance metrics are collected through the hardware telemetry interface of the DPU, including throughput, end-to-end latency, PFC pause duration, and ECN tagging ratio.

8. The DPU-based lossless Ethernet emulation system according to claim 7, characterized in that, The process of simulating PFC flow control behavior within the DPU hardware, based on a comparison between the actual occupancy depth of each priority hardware queue and the configured waterline threshold, includes: Configure multi-level waterline thresholds, which include a PFC pause waterline threshold XOFF and a PFC resume waterline threshold XON, wherein XOFF is greater than XON. When the occupancy depth of the hardware queue exceeds the XOFF, a PFC pause frame is generated and sent to the corresponding upstream port to pause the transmission of traffic of the corresponding priority. When the occupancy depth of the hardware queue falls below the XON, a PFC recovery frame is generated and sent to the corresponding upstream port to restore the traffic transmission of the corresponding priority. The values ​​of XOFF and XON are dynamically adjusted based on the rate of change of the occupancy depth of the hardware queue.

9. The DPU-based lossless Ethernet emulation system according to claim 7, characterized in that, Also includes: The PFC deadlock condition is detected inside the DPU hardware. The PFC deadlock condition includes continuously receiving PFC pause frames within a preset time window and the queue occupancy depth not decreasing. In response to the detection of the PFC deadlock condition, the occurrence time, duration, and priority queues involved in the PFC deadlock are recorded using the PFC deadlock condition as a test stimulus signal. In the user-configured fault injection mode, a controllable PFC pause frame sequence is injected into a specified priority queue to test the PFC storm tolerance of the system under test. Based on the injected controllable PFC pause frame sequence and the response behavior of the system under test, a PFC storm tolerance assessment report is generated.

10. The DPU-based lossless Ethernet emulation system according to claim 7, characterized in that, The virtual lossless Ethernet network topology includes at least two cascaded virtual switching nodes, and also includes: Map the at least two cascaded virtual switching nodes to different switching simulation engine instances of the DPU; Inject multi-priority mixed traffic between the at least two cascaded virtual switching nodes, so that the shared buffer of the downstream switching node is occupied by multiple upstream ports simultaneously; Monitor whether head-of-line blocking occurs at the downstream switching node, including monitoring forwarding stagnation caused by a priority queue waiting for another priority queue to release its buffer; When head-of-line congestion is detected, the triggering conditions, duration, and affected traffic priority of the head-of-line congestion are recorded.

Images