Network card testing methods and equipment

Abstract

This application discloses a network interface card (NIC) testing method and device, relating to the field of server technology. By configuring a software loopback path within the host operating system, this application enables closed-loop testing that does not rely on external physical devices, effectively avoiding protocol stack performance interference and ensuring hardware-level testing accuracy. Simultaneously, by flexibly injecting bypass channel faults into the software and comprehensively monitoring hardware counters and firmware logs, it can fully verify the NIC's throughput performance, stability, and NCSI protocol fault tolerance mechanism under extreme stress testing, significantly improving testing efficiency, coverage depth, and environmental adaptability.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to network interface card (NIC) testing methods and equipment. Background Technology

[0002] Network Controller Sideband Interface (NCSI) network cards are core components for efficient out-of-band management and redundant communication in modern data centers, and their performance and reliability directly affect the stability of the entire network. Therefore, comprehensive and accurate functional and performance testing of NCSI network cards is crucial.

[0003] In related technologies, network card performance testing usually relies on physical loopback connectors or external network devices, which is highly hardware-dependent. Summary of the Invention

[0004] This application provides a network card testing method and equipment to at least address the issue of high hardware dependency in related technologies.

[0005] This application provides a network card testing method, including:

[0006] Configure a loopback path in the host operating system. The loopback path is used to loop back traffic originating from the physical network interface card (NIC) under test to the NIC's ingress point.

[0007] Based on a preset data packet generation tool, test data packets are injected into the loopback path to achieve stress testing of the physical network card under test.

[0008] By injecting a bypass channel fault into the loopback path, the bypass channel function of the physical network card under test is verified.

[0009] Based on a preset cycle, monitoring data corresponding to stress testing and functional verification is collected, and the test results of the physical network interface card (NIC) under test are determined according to the monitoring data. The monitoring data includes performance data in the hardware register counters of the NIC under test and firmware log data obtained through the management controller interface.

[0010] This application also provides a network interface card (NIC) testing device, including:

[0011] The configuration module is used to configure the loopback path in the host operating system. The loopback path is used to loop back traffic originating from the physical network interface card under test to the entry point of the physical network interface card under test.

[0012] The load testing module is used to inject test data packets into the loopback path based on a preset data packet generation tool, thereby performing load testing on the physical network interface card under test.

[0013] The verification module is used to inject bypass channel faults into the loopback path to verify the bypass channel function of the physical network card under test.

[0014] The determination module is used to collect monitoring data corresponding to stress testing and functional verification at preset intervals, and determine the test results of the physical network interface card (NIC) under test based on the monitoring data. The monitoring data includes performance data in the hardware register counters of the NIC under test and firmware log data obtained through the management controller interface.

[0015] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the network card testing methods described above.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described network interface card (NIC) testing methods.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described network interface card (NIC) testing methods.

[0018] This application enables the configuration of a software loopback path within the host operating system, allowing for closed-loop testing that does not rely on external physical devices. This effectively avoids protocol stack performance interference and ensures hardware-level testing accuracy. Furthermore, by flexibly injecting bypass channel faults into the software and integrating hardware counters and firmware logs for multi-dimensional monitoring, the throughput performance, stability, and NCSI protocol fault tolerance mechanism of the network card under extreme stress testing can be comprehensively verified, significantly improving testing efficiency, coverage depth, and environmental adaptability. Attached Figure Description

[0019] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram illustrating an application scenario of the network card testing method provided in the embodiments of this application;

[0021] Figure 2 A flowchart illustrating the network card testing method provided in this application embodiment;

[0022] Figure 3 A schematic diagram illustrating the principle of the fault injection method in the network card testing method provided in this application embodiment;

[0023] Figure 4 A flowchart illustrating the network interface card (NIC) testing method based on virtual interface pairs and traffic redirection provided in this application embodiment;

[0024] Figure 5 A schematic diagram illustrating the principle of the MAC layer loopback-based network card testing method provided in this application embodiment;

[0025] Figure 6 This is a schematic diagram of the network card testing device provided in the embodiments of this application;

[0026] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

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

[0028] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] This application relates to a technology for hardware-level performance verification of network interface cards (NICs) supporting Network Controller Sideband Interface (NCSI) functionality in modern data center scenarios. NCSI is a key technology for achieving efficient, reliable, and secure network management and is widely used in the management channels of servers, storage devices, and network equipment.

[0030] Specific use cases may include: Data center server production line testing: In closed environments without network infrastructure (such as production lines), it is necessary to quickly verify whether the network card hardware functions meet design specifications. High-bandwidth network cards (25G+) extreme performance verification: Hardware-level stress testing is required to cover the extreme throughput and stability assessment of high-speed network cards. NCSI protocol fault tolerance testing: It is necessary to actively simulate scenarios such as network jitter, channel switching, and protocol layer failures to verify the fault tolerance mechanism and reliability of the network card.

[0031] In the aforementioned scenarios, testing methods relying on physical devices in related technologies have significant limitations. There is an urgent need for a network interface card (NIC) testing solution that is hardware-independent, supports local closed-loop testing, and is compatible with NCSI functional verification. For example, in related technologies, a test environment can be built using physical loopback connectors or switches, but this requires matching specific network port types and cannot be used in environments without external connectivity (such as production lines). Testing can also be based on the operating system protocol stack, but due to protocol stack limitations, it cannot reflect true hardware performance, and the testing error can reach 20%.

[0032] To address the aforementioned technical problems, the inventors of this application have discovered that local closed-loop testing without physical loopback devices can be achieved through operating system kernel virtualization technology. Furthermore, pure software fault injection can be implemented using the eXpress Data Path (XDP) layer protocol. This allows for hardware-level bandwidth stress testing, stability assessment, and bypass channel fault injection verification of network cards with NCSI enabled, without relying on physical loopback devices or external network connections, while avoiding protocol stack performance interference. Based on this, this application provides a network card testing method.

[0033] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0034] This section describes the specific application environment architecture or hardware architecture upon which the network interface card (NIC) testing methods depend. (References) Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the network card testing method provided in this application embodiment. For example... Figure 1 As shown, the test host hardware system provides the physical hardware foundation, with the core being the physical network interface card (NIC) under test (DUT) and the management controller. The two interact via the NCSI management channel. Simultaneously, the NIC connects to the host's Central Processing Unit (CPU) via the Peripheral Component Interconnect Express (PCIe) bus. Hardware registers record real performance data. The software testing logic layer implements zero-physical-dependency testing based on the host hardware. It constructs a software loopback path (replacing the physical loopback device) through a kernel virtualization module, performs hardware-level stress testing using a packet generation tool, and simulates protocol / channel failures using a fault injection engine, completely avoiding interference from the operating system protocol stack.

[0035] In the specific implementation process, the test host configures a loopback path in the host operating system. The loopback path is used to loop back the traffic sent by the physical network interface card (NIC) under test (PNIC) to the entry point of the PNIC. Based on a preset data packet generation tool, test data packets are injected into the loopback path to achieve stress testing of the PNIC. Bypass channel faults are injected into the loopback path to verify the bypass channel function of the PNIC. Based on a preset period, monitoring data corresponding to the stress test and functional verification are collected. The test results of the PNIC are determined based on the monitoring data. The monitoring data includes performance data in the hardware register counters of the PNIC and firmware log data obtained through the management controller interface. The NIC testing method provided in this application embodiment, by configuring a software loopback path in the host operating system, can achieve closed-loop testing without relying on external physical devices, effectively avoiding protocol stack performance interference and ensuring hardware-level testing accuracy. At the same time, by flexibly injecting bypass channel faults in software and combining hardware counters and firmware logs for multi-dimensional monitoring, the throughput performance, stability, and NCSI protocol fault tolerance mechanism of the NIC under extreme stress testing can be comprehensively verified, significantly improving testing efficiency, coverage depth, and environmental adaptability.

[0036] Figure 2 This is a flowchart illustrating the network card testing method provided in the embodiments of this application, as shown below. Figure 2 As shown, embodiments of this application provide a network card testing method, which is described in detail below:

[0037] 201. Configure the loopback path in the host operating system. The loopback path is used to loop back traffic originating from the physical network interface card under test to the entry point of the physical network interface card under test.

[0038] The execution subject of this embodiment can be a terminal device or server equipped with the physical network card to be tested. Its core feature is that it does not rely on any external physical device.

[0039] Specifically, a virtual data channel is created within the host operating system using software technology, allowing data packets originating from the network interface card under test to be recycled by the card itself, thus forming a closed-loop test condition. To improve testing efficiency, the test environment can be bound to the target processor core and its corresponding Non-Uniform Memory Access (NUMA) node.

[0040] In one possible approach, a packet processing framework provided by the operating system kernel, such as the extended Berkeley Packet Filter (eBPF) and XDP, can be utilized. A specific XDP program can be written and loaded into the driver of the physical network interface card (NIC) under test (NIC). This XDP program, acting as the logical core of the loopback path, is configured to hook onto the NIC's transmit (TX) path and intercept individual or specified egress packets. Subsequently, by calling the `XDP_REDIRECT` action, the destination of the intercepted packets is modified to the same NIC's receive queue (RQ), thus directly looping the packets back to the NIC's entry point, completing a software-level self-transmission and self-reception operation. This method runs entirely in kernel mode, bypassing the traditional network protocol stack and ensuring high efficiency and low latency in test traffic.

[0041] In another possible approach, a loopback path can be constructed based on kernel-based virtual network devices (such as Virtual Ethernet Pair, veth pair, or MAC Virtual Local Area Network) combined with network address translation or routing rules.

[0042] 202. Based on the preset data packet generation tool, inject test data packets into the loopback path to achieve stress testing of the physical network card under test.

[0043] Specifically, high-intensity test traffic can be injected into the configured software loopback path using high-performance packet generation tools to stress test the physical network card under test and evaluate its extreme performance indicators.

[0044] In this embodiment, the preset packet generation tool can be a high-performance packet generator (e.g., pktgen-dpdk) developed based on user-space I / O frameworks such as DPDK (Data Plane Development Kit) or PF_RING. This tool runs in user space and, by bypassing the operating system kernel protocol stack and directly manipulating the network card's driver queue, can generate and inject customized test packet streams at line speed, thereby maximizing the hardware forwarding capabilities of the network card and preventing the testing tool itself from becoming a performance bottleneck.

[0045] The process of injecting test packets into the loopback path can involve a packet generation tool sending generated test packets into the transmit buffer of the physical network card under test (NIC) via kernel bypass or Direct Memory Access (DMA). The NIC driver then processes these packets and sends them to the configured software loopback path (i.e., the aforementioned XDP program). The XDP program then takes over the packets and redirects them back to the NIC's receive channel, thus forming a complete internal stress test loop.

[0046] Stress testing includes, but is not limited to: adjusting the packet generation rate and packet length distribution (e.g., 64-byte small packets to test the packet forwarding rate in the worst case, or 1518-byte large packets to test bandwidth throughput) to evaluate the throughput, packet loss rate, latency, and jitter of the physical network card under test under different loads, and ultimately verify whether it meets the designed hardware performance specifications.

[0047] 203. Inject bypass channel faults into the loopback path to verify the bypass channel function of the physical network card under test.

[0048] Specifically, by leveraging the flexibility of software-defined systems, various fault conditions are proactively and precisely introduced into the established loopback path to verify the fault tolerance and reliability of the bypass channel (NCSI channel) of the physical network card under test, thereby completing in-depth testing of the network card management function.

[0049] Optionally, various destructive operations can be performed on data packets flowing through the loopback path to simulate abnormal scenarios that may occur in a real network environment.

[0050] These operations include, but are not limited to: Dropping: Randomly or proportionally dropping specified data packets to simulate severe network congestion or link interruption. Corruption: Modifying the packet payload or checksum to simulate bit errors during transmission. Delay: Temporarily storing specific data packets in a queue before releasing them to simulate network jitter or delay. Redirection: Forcing data packets destined for the primary channel to be routed to a backup channel, or vice versa, to simulate channel switching anomalies.

[0051] Through the above operations, various fault-tolerance mechanisms defined in the NCSI protocol state machine can be actively triggered. For example, after continuous packet loss on the primary channel, the NCSI controller of the network card under test should be able to automatically switch to the backup channel; upon receiving a corrupted control command packet, it should be able to discard invalid packets and request retransmission. By observing whether the network card can correctly respond to these injected faults according to the NCSI protocol specification, testers can verify the reliability and robustness of the bypass channel function. This method achieves highly controllable and repeatable fault testing without any external hardware, greatly improving testing depth and efficiency.

[0052] In some embodiments, injecting bypass channel faults into the loopback path to achieve functional verification of the physical network interface card (NIC) under test includes: loading an extended Berkeley packet filter (eBPF) program in the host operating system and attaching the extended Berkeley packet filter program to the NIC under test, thereby achieving functional verification of the NIC under test. In this embodiment, by loading the eBPF program in the host operating system and attaching it to the NIC under test, fine-grained, kernel-level control of the packet processing flow can be achieved. This allows for flexible and precise injection of various faults such as packet loss, packet errors, and latency without introducing additional hardware overhead. This not only provides a highly controllable and repeatable software-defined testing environment for the functional verification of the bypass channel but also effectively ensures high performance and high reliability of the testing process, significantly improving the depth and efficiency of verification of NIC fault tolerance mechanisms and protocol compliance.

[0053] In some embodiments, an extended Berkeley packet filter is loaded in the host operating system and attached to the physical network interface card under test to perform functional verification of the physical network interface card under test, including: deploying a preset program hook in the network driver layer of the kernel.

[0054] The test data packets received by the physical network card under test are detected in real time through a preset program hook.

[0055] If the received test data packet is detected to be a preset protocol management packet, the extended Berkeley packet filter program is invoked to perform corresponding operations on the management packet according to the preset fault injection strategy, so as to simulate a bypass channel fault and realize the functional verification of the physical network card under test.

[0056] The preset fault injection strategy includes at least one of the following: generating random numbers by extending the Berkeley packet filter program, and discarding preset protocol management packets based on the comparison result of the random numbers and preset thresholds.

[0057] By extending the Berkeley packet filter program to modify the channel identifier field in the header of the default protocol management packet, the communication channel specified by the default protocol management packet can be tampered with, triggering a channel switch.

[0058] The Berkeley packet filter program is extended to change the response status code in the default protocol management packet payload from a normal status code to a default error status code.

[0059] In this embodiment, the preset protocol is the network controller sideband interface protocol. The preset program hook is the eXpress Data Path (XDP) hook program.

[0060] For example, such as Figure 3As shown, in the network interface card (NIC) driver layer, the XDP hook program triggers the eBPF program to work. For NCSI protocol packets, the eBPF program can modify their channel ID; for management packets (i.e., default protocol management packets), the eBPF program uses a default fault injection strategy, such as packet loss, modification of the channel ID, or tampering with the program code, or even discarding them directly via XDP_DROP, to simulate bypass channel failures and verify the NIC's fault tolerance capabilities. NCSI protocol packets are data packets conforming to the NCSI protocol specification, used for normal communication and management operations of the NIC bypass channel (NCSI channel), such as transmitting control commands and status queries. Management packets, a type of NCSI protocol packet, are specifically used for managing and controlling the NIC, such as configuring NIC parameters and obtaining NIC status.

[0061] In this embodiment, by deploying program hooks at the network driver layer and using eBPF programs to perform real-time detection and policy-based tampering of management packets such as NCSI, specific fault scenarios such as packet loss, channel identification errors, and abnormal status codes can be accurately simulated. This not only achieves comprehensive and fine-grained verification of the network card bypass channel fault tolerance mechanism, but also ensures the targeting and repeatability of fault injection, significantly improving the realism of the test scenario and the reliability of the verification conclusion.

[0062] Optionally, commands can be sent to the network card driver via user-space command-line tools to modify the NCSI channel configuration register of the network card hardware, thereby triggering a forced switchover of the NCSI primary / backup channel at the hardware level. The eBPF program attaches to and captures the kernel events triggered by the forced switchover operation, and records the timestamps of the events and system response information. In this embodiment, by combining user-space command-line tools to directly manipulate the network card hardware registers to trigger a forced channel switchover, and using the eBPF program to synchronously capture and record the kernel events and precise timestamps triggered thereby, joint tracking and precise correlation of hardware operations and software responses can be achieved. This not only realizes full-link visual monitoring from hardware drivers to system kernels, but also accurately measures channel switching latency and verifies hard real-time performance indicators, providing millisecond-level precision data support for evaluating the reliability of the network card redundancy mechanism and system robustness, significantly improving the comprehensiveness and authority of the test.

[0063] 204. Based on a preset cycle, collect monitoring data corresponding to stress testing and functional verification, and determine the test results of the physical network interface card (NIC) under test based on the monitoring data. The monitoring data includes performance data in the hardware register counters of the NIC under test and firmware log data obtained through the management controller interface.

[0064] Specifically, after completing the stress test and functional verification, comprehensive and objective quantitative data can be obtained from both the hardware performance counter and the management controller firmware through periodic data collection, so as to form the final test conclusion on the performance and functional reliability of the network card under test.

[0065] In practice, the system automatically executes data acquisition tasks according to a pre-set sampling period. Performance data acquisition is accomplished by reading counters in the hardware registers of the physical network interface card (NIC) under test. These counters include key indicators such as the number of bytes received, bytes sent, number of dropped packets received, number of erroneous packets sent, and number of packets received, which directly reflect the actual working status of the NIC under stress testing. Firmware log data acquisition is achieved through the management controller interface, such as the intelligent platform management interface of the baseboard management controller or the NIC's own out-of-band management interface, to read the operation logs of firmware such as the NCSI controller. These logs record key functional information such as channel switching events, link status changes, protocol timeouts, and error alarms.

[0066] The system correlates and analyzes the collected performance data and firmware log data to determine the test results. In the performance evaluation phase, performance counter data is compared with the theoretical traffic values ​​injected by the testing tool to determine whether the network interface card (NIC) meets its nominal performance specifications. In the functional and reliability verification phase, firmware logs are used to verify whether the NIC's behavior meets expectations during injected faults or forced switching. For example, if the firmware log shows a primary channel link failure alarm followed by a switch to the backup channel, and the performance counter shows that traffic recovers after a brief interruption, it proves that the bypass channel's redundancy function is normal. Finally, the system generates a comprehensive test report, providing a clear conclusion based on monitoring data regarding whether the performance of the tested physical NIC meets standards and whether its functions are normal. By simultaneously collecting hardware counters and firmware logs, cross-validation and correlation analysis of NIC performance and internal status are achieved. This allows the test results to not only quantify performance bottlenecks but also deeply diagnose the root causes of functional abnormalities, thus providing a comprehensive, accurate, and highly convincing evaluation conclusion.

[0067] In some embodiments, monitoring data corresponding to stress testing and functional verification is collected based on a preset period, and the test results of the physical network card under test are determined based on the monitoring data, including: collecting performance data from the hardware registers of the physical network card under test by executing a preset query instruction. The performance data includes at least one of the following: number of received packet losses, number of transmitted packet losses, number of cyclic redundancy check errors, number of direct memory access errors, and preset protocol counter.

[0068] Firmware log data is collected from the preset protocol function unit of the management controller by executing preset management interface commands. The firmware log data includes at least one of the following: channel switching event records, link timeout event records, and protocol interaction error records.

[0069] Real-time monitoring of data.

[0070] If a timeout event is detected on the network controller's sideband interface channel, the host operating system sends a preset signal to the virtual machine to trigger a virtual machine restart, simulating a physical reset operation.

[0071] In this embodiment, the preset query command can be the ethtool command, which is used to query statistical information of network interfaces.

[0072] The network interface card (NIC) testing method provided in this application, by configuring a software loopback path within the host operating system, enables closed-loop testing independent of external physical devices, effectively avoiding protocol stack performance interference and ensuring hardware-level testing accuracy. Simultaneously, by flexibly injecting bypass channel faults into the software and comprehensively monitoring hardware counters and firmware logs, it can fully verify the NIC's throughput performance, stability, and NCSI protocol fault tolerance mechanism under extreme stress testing, significantly improving testing efficiency, coverage depth, and environmental adaptability.

[0073] In some embodiments, the configuration of the loopback path in step 201 and the stress test in step 202 can be achieved through multiple paths.

[0074] In one feasible approach, configuring a loopback path within the host operating system includes: creating a virtual interface pair (virtual Ethernet interface pair) within the host operating system. The virtual interface pair comprises a first virtual interface and a second virtual interface. The physical address (Media Access Control Address, MAC) of the first virtual interface is set to the physical address of the physical network interface card (NIC) under test. By configuring traffic control rules on the NIC under test, the outgoing traffic of the NIC under test is redirected to the first virtual interface, enabling the first virtual interface to return the outgoing traffic to the NIC under test via the second virtual interface based on the physical address, thus forming a loopback path.

[0075] For example, such as Figure 4 As shown, traffic control (TC) rules can be used to redirect the outgoing traffic from the eth0 egress of the physical network interface card under test to the virtual interface veth0. The traffic is then transmitted from veth0 to veth1 and received by the test program. The test program then sends the response packet (or the original packet) out through the kernel protocol stack. Finally, the packet enters the ingress of the eth0 of the physical network interface card under test. This forms a relatively long loopback path that requires the participation of the protocol stack, and the starting point is the outgoing traffic of the physical network interface card eth0.

[0076] In some embodiments, based on a preset packet generation tool, test packets are injected into the loopback path to perform stress testing on the physical network interface card under test. This includes: loading a kernel packet generator module (e.g., pktgen) and configuring the kernel packet generator module to send test packets at line speed through the second virtual interface in the virtual interface pair to perform stress testing on the physical network interface card under test.

[0077] This application embodiment loads a kernel packet generator module and configures it to send test data packets at line speed through the second virtual interface in the virtual interface pair. This enables the direct generation of high-speed test traffic at the kernel level, effectively avoiding the data copy overhead from user space to kernel space. This allows for stress testing of the physical network card under test at near-theoretical bandwidth. This method not only significantly improves the efficiency and accuracy of test traffic generation but also realistically simulates extreme network load scenarios, providing strong technical support for evaluating the performance stability and reliability of network cards under high throughput conditions.

[0078] In another possible implementation, a loopback path is configured in the host operating system, including: in the host operating system, the physical network card under test is unbound from the kernel driver via Virtual Function Input / Output (VFIO) and the physical network card under test is passed through to the virtual machine (VM).

[0079] In the virtual machine, the test program of the user-space Data Plane Development Kit (DPDK) is configured to work in Media Access Control (MAC) layer loopback mode to form a loopback path.

[0080] Specifically, the physical network interface card (NIC) under test (NIC) can be configured to operate in user-mode. A large page pool is allocated in system memory, and a Direct Memory Access (DMA) engine is configured for the NIC to use physical addresses for data transfer. A loopback start command is sent to the NIC; this command instructs the NIC to loop back the data signal from the transmit channel to the receive channel within the Media Access Control (MAC) layer, thus obtaining a closed internal test path.

[0081] This embodiment of the application uses VFIO to debind the physical network interface card (NIC) under test from the host kernel driver and directly connect it to the virtual machine, granting the virtual machine exclusive hardware access to the NIC and effectively eliminating the performance overhead and interference of the host operating system protocol stack. Simultaneously, a DPDK-based test program is deployed in the virtual machine and configured in MAC layer loopback mode. Utilizing DPDK's user-space polling and zero-copy mechanism, a high-performance data plane is constructed, forming an efficient loopback path directly from the NIC hardware to the user-space test program. This configuration not only achieves a clean environment for testing the physical functions of the NIC but also fully leverages the hardware's performance potential, providing a near-line-speed testing environment for high-precision, high-throughput NIC performance verification.

[0082] In some embodiments, test data packets are injected into the loopback path based on a preset data packet generation tool to achieve stress testing of the physical network interface card under test. This includes: generating test data packets in a virtual machine using a test data packet generation tool (e.g., testpmd) from a user-space data plane development kit and injecting the test data packets into the loopback path to achieve stress testing of the physical network interface card under test.

[0083] This application embodiment generates and injects test data packets by directly calling the test data packet generation tool of the user-space data plane development kit within the virtual machine. It fully utilizes the efficient data packet processing capabilities of the user-space polling and zero-copy mechanism of the data plane development kit, enabling test traffic to directly act on the physical network card under test at near hardware line speed. This method not only completely avoids the network protocol stack overhead and performance jitter of the virtual machine monitor, but also achieves extreme stress testing of the network card's data processing capabilities, providing a stable and reliable testing environment for accurately evaluating key performance indicators such as throughput, latency, and packet loss rate of the network card under real high-load scenarios.

[0084] In some embodiments, within a virtual machine, a test packet is generated using the test packet generation tool of the user-space data plane development kit and injected into the loopback path to perform stress testing on the physical network interface card under test. This includes: within a virtual machine, generating a test packet using the test packet generation tool of the user-space data plane development kit and storing the descriptor of the test packet in a first memory buffer allocated for the sending ring.

[0085] The descriptor in the first memory buffer is read by the Direct Memory Access (DMA) engine of the physical network card under test. The physical address of the test data packet is obtained based on the descriptor, and the test data packet is transferred to the network card cache of the physical network card under test through direct memory access operation based on the physical address of the test data packet.

[0086] Inside the physical network interface card (NIC) under test, based on the media access control layer loopback mode, the test data packets buffered by the NIC are redirected from the NIC's sending channel to its receiving channel to obtain the loopback-backed test data packets.

[0087] The loopback test data packets are written into the second memory buffer allocated for the receive loop via the Direct Memory Access engine of the physical network interface card under test.

[0088] Test packets are retrieved from a second memory buffer using a test packet generation tool. Performance metrics are then calculated based on the sent and received test packets to perform stress testing on the physical network interface card (NIC) under test. Performance metrics include one or more of throughput, bandwidth, packet loss rate, and latency. The user-space testing tool calculates these metrics by comparing the number and duration of sent and received packets.

[0089] For example, such as Figure 5 As shown, in the DPDK user space, the testpmd tool generates test data packets based on the register design, stores them in the transmit ring (Tx Ring), and then writes them to the network card hardware layer buffer via DMA. The network card hardware layer uses MAC layer loopback to guide the data from the transmit channel to the receive ring (Rx Ring), and then reads it into the memory pool via DMA. The memory pool manages the relevant data, thereby achieving efficient loopback testing for network card performance stress testing.

[0090] This application embodiment uses a user-space data plane development toolkit to finely control the direct memory access transmission process of test data packets between the kernel and the network interface card (NIC). It also utilizes the NIC media access control layer loopback mode to achieve closed-loop data packet flow within the hardware, constructing a complete high-performance test path from user-space memory to the NIC hardware and back to user-space memory. Specifically, by storing the data packet descriptor in the transmit loop memory buffer, the NIC's direct memory access engine is triggered to autonomously acquire and transmit data packets to the NIC buffer. Then, the NIC's internal loopback mechanism automatically redirects data from the transmit channel to the receive channel. Finally, direct memory access operations write the loopback data packets into the receive loop memory buffer, achieving zero-copy, high-speed flow of test traffic between user space and the NIC hardware. This approach not only completely avoids the system call overhead and context switching loss of the virtual machine kernel protocol stack, but also fully leverages the parallel processing capabilities and hardware-level loopback features of the network card's direct memory access engine. This allows test packets to complete the entire process of sending, looping back, and receiving at a rate close to the theoretical limit, providing a nanometer-precision measurement environment for accurately measuring the core performance indicators of the network card under extreme loads, such as throughput, latency, and packet loss rate. This greatly improves the accuracy and authority of the test results.

[0091] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0092] Figure 6 This is a schematic diagram of the network card testing device provided in an embodiment of this application. Figure 6 As shown, embodiments of this application also provide a network interface card (NIC) testing device 60, including: a configuration module 601, a stress testing module 602, a verification module 603, and a determination module 604.

[0093] Configuration module 601 is used to configure the loopback path in the host operating system; the loopback path is used to loop back the traffic sent by the physical network interface card under test to the entry point of the physical network interface card under test.

[0094] The load testing module 602 is used to inject test data packets into the loopback path based on a preset data packet generation tool to achieve load testing of the physical network card under test;

[0095] The verification module 603 injects a bypass channel fault into the loopback path to verify the bypass channel function of the physical network card under test.

[0096] The determination module 604 collects monitoring data corresponding to stress testing and functional verification based on a preset cycle, and determines the test results of the physical network interface card under test based on the monitoring data; the monitoring data includes performance data in the hardware register counters of the physical network interface card under test and firmware log data obtained through the management controller interface.

[0097] For a description of the features in the embodiment corresponding to the network card testing equipment, please refer to the relevant description of the embodiment corresponding to the network card testing method, which will not be repeated here.

[0098] In some embodiments, the configuration module 601 is specifically used to: create a virtual interface pair in the host operating system. The virtual interface pair includes a first virtual interface and a second virtual interface.

[0099] Set the physical address of the first virtual interface to the physical address of the physical network card under test.

[0100] By configuring traffic control rules on the physical network interface card (NIC) under test, the outgoing traffic of the NIC under test is redirected to the first virtual interface. This allows the first virtual interface to return the outgoing traffic to the NIC under test through the second virtual interface based on the physical address, thus forming a loopback path.

[0101] In some embodiments, the stress testing module 602 is specifically used to: load the kernel packet generator module and configure the kernel packet generator module to send test data packets at line speed through the second virtual interface in the virtual interface pair to realize stress testing of the physical network card under test.

[0102] In some embodiments, the configuration module 601 is specifically used to: in the host operating system, unbind the physical network card under test from the kernel driver through the virtual function input / output driver and pass the physical network card under test to the virtual machine.

[0103] In the virtual machine, the test program of the user-mode data plane development toolkit is configured to work in media access control layer loopback mode to form a loopback path.

[0104] In some embodiments, the stress testing module 602 is specifically used to: generate test data packets within a virtual machine using the test data packet generation tool of the user-space data plane development kit and inject the test data packets into the loopback path to achieve stress testing of the physical network card under test.

[0105] In some embodiments, the load testing module 602 is specifically used to: generate test data packets within a virtual machine using the test data packet generation tool of the user-space data plane development kit, and store the descriptor of the test data packets into a first memory buffer allocated for the sending ring.

[0106] The system reads the descriptor from the first memory buffer using the direct memory access engine of the physical network card under test, obtains the physical address of the test data packet based on the descriptor, and transfers the test data packet to the network card cache of the physical network card under test through direct memory access operation based on the physical address of the test data packet.

[0107] Inside the physical network interface card (NIC) under test, based on the media access control layer loopback mode, the test data packets buffered by the NIC are redirected from the NIC's sending channel to its receiving channel to obtain the loopback-backed test data packets.

[0108] The loopback test data packets are written into the second memory buffer allocated for the receive loop via the Direct Memory Access engine of the physical network interface card under test.

[0109] Test packets are obtained from the second memory buffer using a test packet generation tool. Performance metrics are then calculated based on the sent and received test packets to perform stress testing on the physical network card under test.

[0110] In some embodiments, the verification module 603 is specifically used to: load the extended Berkeley packet filter program in the host operating system and attach the extended Berkeley packet filter program to the physical network card under test, thereby realizing the functional verification of the physical network card under test.

[0111] In some embodiments, the verification module 603 is specifically used to: deploy a preset program hook in the network driver layer of the kernel.

[0112] The test data packets received by the physical network card under test are detected in real time through a preset program hook.

[0113] If the received test data packet is detected to be a preset protocol management packet, the extended Berkeley packet filter program is invoked to perform corresponding operations on the management packet according to the preset fault injection strategy, so as to simulate a bypass channel fault and realize the functional verification of the physical network card under test.

[0114] The preset fault injection strategy includes at least one of the following:

[0115] Random numbers are generated by extending the Berkeley packet filter program. Based on the comparison result of the random numbers with a preset threshold, preset protocol management packets are discarded.

[0116] By extending the Berkeley packet filter program to modify the channel identifier field in the header of the default protocol management packet, the communication channel specified by the default protocol management packet can be tampered with, triggering a channel switch.

[0117] The Berkeley packet filter program is extended to change the response status code in the default protocol management packet payload from a normal status code to a default error status code.

[0118] In some embodiments, the determining module 604 is specifically used to: collect performance data from the hardware registers of the physical network card under test by executing a preset query instruction. The performance data includes at least one of the following: number of received packet losses, number of transmitted packet losses, number of cyclic redundancy check errors, number of direct memory access errors, and preset protocol counter.

[0119] Firmware log data is collected from the preset protocol function unit of the management controller by executing preset management interface commands. The firmware log data includes at least one of the following: channel switching event records, link timeout event records, and protocol interaction error records.

[0120] Real-time monitoring of data.

[0121] If a timeout event is detected on the network controller's sideband interface channel, the host operating system sends a preset signal to the virtual machine to trigger a virtual machine restart, simulating a physical reset operation.

[0122] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus.

[0123] In the specific implementation process, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to execute the above-described network card testing method embodiment.

[0124] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0125] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0126] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0127] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0128] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the network interface card testing method embodiments described above when running.

[0129] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0130] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the network interface card testing method embodiments described above.

[0131] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the network interface card testing method embodiments described above.

[0132] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0133] The above provides a detailed description of a network interface card (NIC) testing method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method of testing a network card, the method comprising: The application relates to a method for testing a physical network card, and belongs to the technical field of network card testing. The method comprises the following steps: configuring a loopback path in a host operating system; the loopback path is used for looping back traffic sent by a physical network card to be tested to an inlet of the physical network card to be tested; based on a preset data packet generation tool, test data packets are injected into the loopback path to realize stress testing of the physical network card to be tested; a bypass channel fault is injected into the loopback path to realize bypass channel function verification of the physical network card to be tested; based on a preset period, monitoring data corresponding to the stress testing and the function verification is collected, and a test result of the physical network card to be tested is determined according to the monitoring data; the monitoring data comprises performance data in a hardware register counter of the physical network card to be tested and firmware log data obtained through a management controller interface; the step of injecting the bypass channel fault into the loopback path to realize the function verification of the physical network card to be tested comprises the following steps: deploying a preset program hook in a network driver layer of a kernel; real-time detection is performed on the test data packets received by the physical network card to be tested through the preset program hook; if the received test data packets are preset protocol management packets, an extended Berkeley packet filter program is called to execute corresponding operations on the management packets according to a preset fault injection strategy, so as to simulate a bypass channel fault and realize function verification of the physical network card to be tested; the preset fault injection strategy comprises at least one of the following: a random number is generated through the extended Berkeley packet filter program, and the preset protocol management packets are discarded according to a comparison result of the random number and a preset threshold; a channel identifier field in a packet header of the preset protocol management packets is modified through the extended Berkeley packet filter program, so as to tamper with a communication channel specified by the preset protocol management packets and trigger channel switching; 2. The method of claim 1, wherein, a response status code in a payload of the preset protocol management packets is tampered from a normal status code to a preset error status code through the extended Berkeley packet filter program. The step of configuring the loopback path in the host operating system comprises the following steps: a virtual interface pair is created in the host operating system; the virtual interface pair comprises a first virtual interface and a second virtual interface; a physical address of the first virtual interface is set as a physical address of the physical network card to be tested; 3. The method of claim 2, wherein, an outlet traffic of the physical network card to be tested is redirected to the first virtual interface through configuration of a traffic control rule on the physical network card to be tested, so that the first virtual interface returns the outlet traffic to the physical network card to be tested through the second virtual interface based on the physical address, to form a loopback path. The step of injecting the test data packets into the loopback path to realize the stress testing of the physical network card to be tested based on the preset data packet generation tool comprises the following steps:

4. The method of claim 1, wherein, a kernel packet generator module is loaded and configured to send test data packets based on line speed through the second virtual interface in the virtual interface pair, to realize stress testing of the physical network card to be tested. The step of configuring the loopback path in the host operating system comprises the following steps: In the host operating system, the to-be-tested physical network card is unbound from a kernel driver by a virtual function input / output driver and is directly connected to a virtual machine; In the virtual machine, a test program of a user mode data plane development kit is configured to work in a medium access control layer loopback mode to form a loopback path.

5. The method of claim 4, wherein, The preset data packet generation tool injects test data packets into the loopback path to implement stress test of the to-be-tested physical network card, including: In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card.

6. The method of claim 5, wherein, The test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path in the virtual machine to implement stress test of the to-be-tested physical network card, including: In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card.

7. The method of claim 1-6, wherein, In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. The test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path in the virtual machine to implement stress test of the to-be-tested physical network card, including: In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. The test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path in the virtual machine to implement stress test of the to-be-tested physical network card, including: In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. In the virtual machine, a test data packet generation tool of the user mode data plane development kit generates test data packets and injects the test data packets into the loopback path to implement stress test of the to-be-tested physical network card. According to the performance data and the firmware log data, the test result of the to-be-tested physical network card is determined; The monitoring data is detected in real time; If a network controller sideband interface lane timeout event is detected, a preset signal is sent to the virtual machine through a host operating system to trigger the virtual machine to restart, so as to simulate a physical reset operation.

8. An electronic device, comprising: The method comprises the steps that: a memory for storing a computer program; a processor for executing the computer program to realize the steps of the network card testing method according to any one of claims 1 to 7.

Images