A network card testing method, device, system, medium and product

Abstract

This application relates to a method, device, system, medium, and product for testing network interface cards (NICs), comprising: after power-on, the test device invokes a pre-boot execution environment function to obtain a network boot loader from a remote boot device and loads and executes it; through the network boot loader, it sends a request carrying its own identification information to a remote storage device, and receives a boot configuration script generated by the remote storage device based on the identification information; it parses and executes the boot configuration script, establishes a connection with the remote storage device through the NVMe-oF protocol based on RDMA network transmission, maps the target NVMe namespace to the test device's NVMe block device as the system boot disk; loads and boots the target operating system, and executes the NIC test tasks. This application can improve NIC testing efficiency and hardware resource utilization.

Description

Technical Field

[0001] This application relates to the field of network interface card (NIC) testing technology, specifically to a NIC testing method, device, system, computer-readable storage medium, and computer program product. Background Technology

[0002] In the research and development and testing of network interface cards (NICs), to verify the compatibility and performance of NICs under different operating systems, it is usually necessary to build an operating system test matrix covering mainstream distributions. Existing operating system environment deployment and switching methods mainly fall into two categories: one is local deployment based on physical servers, where different operating systems are repeatedly reinstalled manually for testing; the other is a temporary loading method based on PXE (Preboot Execution Environment) network boot, which loads the operating system kernel and root file system into memory at once for execution. The local deployment method requires a complete image installation and environment configuration process when switching systems, which is time-consuming (tens of minutes to several hours) and requires manual intervention, making continuous automated testing across operating systems impossible. While the PXE temporary loading method does not require local deployment, the loaded operating system runs in memory and lacks persistence; the environment becomes invalid after a restart, failing to meet the complex testing requirements that require multiple restarts or long-term state maintenance. Summary of the Invention

[0003] In view of the above problems, this application proposes a testing method, device, system, computer-readable storage medium, and computer program product for network interface cards (NICs) to improve NIC testing efficiency and hardware resource utilization.

[0004] According to a first aspect of this application, a method for testing a network interface card (NIC) is provided, applied to a test device on which the NIC to be tested is installed, the method comprising:

[0005] After power-on startup, the pre-boot execution environment function of the network card is invoked to send a first request to the remote boot device to obtain the network boot loader; The network bootloader is loaded and executed, and a second request is sent to the remote storage device through the network bootloader; wherein the second request carries the identification information of the test device; The system receives a startup configuration script generated by the remote storage device based on the identification information of the test device. The startup configuration script includes at least remote storage connection parameters, which are used to indicate the access path of the target remote system disk. The startup configuration script is parsed and executed. Based on the remote storage connection parameters, a connection is established with the remote storage device via the NVMe-oF protocol based on RDMA network transmission. The target NVMe namespace in the remote storage device is mapped to the NVMe block device of the test device. The target NVMe namespace stores the system files of the target operating system. Using the NVMe block device as the system boot disk, the target operating system is loaded and started, and the network card test task is executed.

[0006] In some embodiments, invoking the pre-boot execution environment function of the network interface card to send a first request to the remote boot device to obtain a network bootloader includes: The pre-boot execution environment function of the network card is invoked to send a first request to the remote boot device, and the network boot parameters and network boot loader file address returned by the remote boot device are received. Configure the network environment of the test device according to the network startup parameters, and download the network bootloader according to the network bootloader file address.

[0007] In some embodiments, the remote storage device stores a boot mapping configuration file, which includes a correspondence between the identification information of the test device and the identification information of the target operating system; The startup configuration script is specifically a script generated by the remote storage device based on the identification information of the test device, which queries the startup mapping configuration file to determine the identification information of the target operating system.

[0008] In some embodiments, parsing and executing the startup configuration script, establishing a connection with the remote storage device via the NVMe-oF protocol based on RDMA network transmission according to the remote storage connection parameters, and mapping the target NVMe namespace in the remote storage device to the NVMe block device of the test device includes: The system loads the operating system kernel and initializes the memory file system. Based on the initialized memory file system, it enables the NVMe-oF client. Based on the NVMe-oF client, it sends a third request to the NVMe-oF server on the remote storage device, so that the NVMe-oF server maps the target NVMe namespace to the NVMe block device of the test device. The NVMe-oF server includes the target NVMe namespace.

[0009] In some embodiments, the startup configuration script further includes network initialization parameters and startup control instructions; The network initialization parameters are used to configure and activate the network environment of the test device after the operating system kernel is loaded. The boot control command is used to instruct the test device to load the operating system kernel and initialize the memory file system, trigger the NVMe-oF client to enable, and control the target operating system to be booted using the NVMe block device as the system boot disk after the NVMe block device is successfully mapped.

[0010] In some embodiments, the remote storage connection parameters include the identification information of the target NVMe subsystem, the identification information of the target NVMe namespace, the transmission protocol type, the network address of the remote storage device, and the port corresponding to the NVMe-oF server, wherein the transmission protocol type is the RDMA network transmission protocol.

[0011] In some embodiments, the NVMe-oF server includes at least one NVMe subsystem, the NVMe subsystem includes at least two NVMe namespaces, and each NVMe namespace stores system files for an operating system; The third request carries the identification information of the target NVMe namespace, which is used to enable the NVMe-oF server to expose the target NVMe namespace only to the test device, and other NVMe namespaces are not mapped to the NVMe block device of the test device during the current startup process.

[0012] In some embodiments, the method further includes: The automated control tool automatically updates the boot mapping configuration file, maps the identification information of the test device to the identification information of the new operating system, and restarts the test device to load the new operating system and execute the network card test task.

[0013] According to a second aspect of this application, a testing device for a network interface card (NIC) is provided, the testing device including a module for performing the method described in the first aspect of this application.

[0014] According to a third aspect of this application, a network interface card (NIC) testing system is provided, comprising a remote boot device, a remote storage device, and at least one NIC testing device as described in the second aspect of this application. The remote boot device is used to provide the network boot parameters and the address of the network boot loader file to the testing device; the remote storage device is used to provide the boot configuration script to the testing device and map the target NVMe namespace to the NVMe block device of the testing device.

[0015] According to a fourth aspect of this application, a computer-readable storage medium is provided, wherein computer program instructions are stored thereon, and when executed by a processor, the computer program instructions implement the network card testing method as described in the first aspect of this application.

[0016] According to a fifth aspect of this application, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the network card testing method as described in the first aspect of this application.

[0017] The testing method, equipment, system, computer-readable storage medium, and computer program product for a network interface card (NIC) proposed in this application have at least the following beneficial effects: This application decouples the operating system's boot source from the local hard drive. After power-on, the test device only needs to dynamically obtain the corresponding boot configuration script from the remote storage device based on its own identification information. It can then map the remote target NVMe namespace to the local system disk via the NVMe-oF protocol based on RDMA network transmission to complete the boot process. On one hand, this mechanism eliminates the time-consuming process of repeatedly executing the complete local operating system installation and environment configuration in traditional solutions, shortening the switching time for cross-system testing to a single restart cycle, significantly improving network card testing efficiency. On the other hand, the same physical test device can load different remote system disks as needed in different boot cycles, eliminating the need to deploy multiple independent physical servers to cover multiple operating systems. This significantly reduces hardware procurement and maintenance costs and greatly improves the utilization rate of server hardware resources. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying 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.

[0019] Figure 1 This is a flowchart illustrating a testing method for a network interface card (NIC) according to an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of the framework of a network card testing system according to an embodiment of this application. Detailed Implementation

[0021] The detailed description of the accompanying drawings is intended to illustrate the present preferred embodiments of this application and is not intended to represent only the forms in which this application can be implemented. It should be understood that the same or equivalent functions can be achieved by different embodiments intended to be included within the spirit and scope of this application.

[0022] See Figure 1 One embodiment of this application provides a method for testing a network interface card (NIC), applied to a test device on which the NIC to be tested is installed. The method includes the following steps: Step S10: After power-on startup, the pre-boot execution environment function of the network card is invoked to send a first request to the remote boot device to obtain the network boot loader; Specifically, after powering on, the test device's Basic Input / Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) calls the Preboot Execution Environment (PXE) function integrated in the network card under test. PXE is an industry-standard protocol for booting computers over a network. It allows the test device to make a first request to a remote boot device on the network, relying on the basic network stack embedded in the network card, to obtain a network boot loader (iPXE) to replace the traditional basic PXE firmware, even without a local operating system or storage media.

[0023] Step S20: Load and execute the network bootloader, and send a second request to the remote storage device through the network bootloader; wherein the second request carries the identification information of the test device; Specifically, after the network bootloader is loaded and acquires boot control, it initiates a second request to the boot control service on the remote storage device according to the preset script logic built into the network bootloader. The second request carries the unique identification information of the test device, such as the physical address (MAC address) of the network card or the device number, so that the remote storage device can accurately identify the specific physical node that is currently initiating the boot request.

[0024] Step S30: Receive the startup configuration script generated by the remote storage device based on the identification information of the test device. The startup configuration script includes at least remote storage connection parameters, which are used to indicate the access path of the target remote system disk. Specifically, after receiving the second request, the remote storage device extracts the identification information of the test device, queries the local boot mapping configuration to determine the target operating system to be loaded, and dynamically generates a boot configuration script (such as the boot.php script) for the test device. The boot configuration script contains remote storage connection parameters, indicating the addressing path and access credentials of the target remote system disk in the network.

[0025] Step S40: Parse and execute the startup configuration script; establish a connection with the remote storage device through the NVMe-oF protocol based on RDMA network transmission according to the remote storage connection parameters; and map the target NVMe namespace in the remote storage device to the NVMe block device of the test device; wherein, the target NVMe namespace stores the system files of the target operating system; Specifically, after parsing the startup configuration script, the test device, based on the remote storage connection parameters within it, employs a network-based high-speed non-volatile memory protocol and establishes a high-speed data connection with the remote storage device via Remote Direct Memory Access (RDMA). The NVMe-oF protocol is an extension protocol that encapsulates and maps the high-performance NVMe storage instruction set, originally dedicated to the local PCIe bus, onto general network architectures such as Ethernet, enabling the test device to access remote storage with standard NVMe block device semantics. Simultaneously, this embodiment uses RDMA as the underlying network transmission mechanism, allowing applications on different computers to directly read and write each other's memory, completely... No kernel intervention from either operating system is required for data copying and context switching; RDMA networks, with their ability to bypass the kernel protocol stack and zero-copy capabilities, enable the connection between the test device and the remote storage device to provide access performance close to that of local storage. This effectively overcomes the high latency and CPU overhead caused by multi-layer protocol parsing in traditional TCP / IP-based network storage (such as iSCSI), thus meeting the stringent requirements for read / write performance and stability when the operating system boots as the system disk. After the connection is established, the target NVMe namespace, which is pre-configured in the remote storage device and stores the target operating system's system files, is logically mapped to a standard NVMe block device that the test device can recognize locally.

[0026] Step S50: Using the NVMe block device as the system boot disk, load and start the target operating system, and execute the network card test task.

[0027] Specifically, after completing the remote system disk mapping, the test device performs a root file system switch operation, migrating the system operating environment from the temporary initial memory file system to the real root file system on the mapped NVMe block device. The target operating system takes over control and enters normal operation. At this time, the remote NVMe block device provides read and write services as a persistent system boot disk. After the operating system boots up, the test device automatically performs functional verification or performance testing tasks for the network card under test.

[0028] In some embodiments, step S10 includes: Step S101: Invoke the pre-boot execution environment function of the network card, send a first request to the remote boot device, and receive the network boot parameters and network boot loader file address returned by the remote boot device; Specifically, the test device uses the PXE function of the network card to send a first request to the remote boot device via Dynamic Host Configuration Protocol (DHCP). The DHCP protocol is based on UDP and is specifically used to dynamically allocate network parameters such as IP addresses, subnet masks, and gateways to network nodes during the early boot phase, thereby solving the fundamental problem that the test device cannot perform subsequent network communication without local configuration. The remote boot device responds to this request, assigns network protocol (IP) addresses and other network boot parameters to the test device, and at the same time returns the specific file address of the network bootloader on the Simple File Transfer Protocol (TFTP) server.

[0029] Step S102: Configure the network environment of the test device according to the network startup parameters, and download the network bootloader according to the network bootloader file address.

[0030] Specifically, the test device uses the obtained network boot parameters to complete the initial configuration of its own basic network environment. Then, according to the provided network boot loader file address, it downloads the network boot loader from the remote boot device to local memory for execution via the TFTP protocol. TFTP is a very simple file transfer protocol based on UDP. Because its implementation code is very small and its memory usage is very low, it is very suitable for use in early boot firmware environments such as BIOS or network cards where resources are extremely limited. After completing the basic PXE network boot, control is transferred to the network boot loader.

[0031] In some embodiments, the remote storage device stores a boot mapping configuration file, which includes a correspondence between the identification information of the test device and the identification information of the target operating system; Specifically, the boot mapping configuration file is centrally maintained on the remote storage device in the form of structured data. As the control center of the boot strategy, the boot mapping configuration file records the binding relationship between the identification information of the test device and the identification information of the operating system, thereby realizing the centralized and differentiated allocation of boot targets for multiple test devices. This enables a single storage server to manage the boot scheduling of multiple operating system images and multiple test devices simultaneously.

[0032] The startup configuration script is specifically a script generated by the remote storage device based on the identification information of the test device, which queries the startup mapping configuration file to determine the identification information of the target operating system.

[0033] Specifically, after parsing the identification information of the test device, the boot control service of the remote storage device uses the identification information of the test device as an index key to search and match in the boot mapping configuration file. After successfully obtaining the identification information of the target operating system, the boot control service extracts the underlying connection parameters such as network address and namespace number associated with the operating system, and dynamically assembles and generates a boot configuration script according to a predetermined script syntax format, thereby giving the same test device the ability to flexibly load different operating systems in different boot cycles.

[0034] In some embodiments, step S40 includes: The system loads the operating system kernel and initializes the memory file system. Based on the initialized memory file system, it enables the NVMe-oF client. Based on the NVMe-oF client, it sends a third request to the NVMe-oF server on the remote storage device, so that the NVMe-oF server maps the target NVMe namespace to the NVMe block device of the test device. The NVMe-oF server includes the target NVMe namespace.

[0035] Specifically, during the early boot phase, the test device first loads the kernel file corresponding to the target operating system and initializes a memory file system (as a temporary root file system). During the execution of this initialization of the memory file system, the test device dynamically loads an NVMe-oF client. Based on this NVMe-oF client, it initiates a third request (i.e., an NVMe-oF connection request) to the NVMe-oF server of the remote storage device. This triggers the NVMe-oF server of the remote storage device to execute NVMe device mapping logic, mapping the target NVMe namespace on the NVMe-oF server to the NVMe block device of the test device. It should be noted that the boot configuration script also includes the network address of the kernel file and the initialization of the memory file system. Based on the network address, the test device downloads the kernel file corresponding to the target operating system and the initialization of the memory file system from the remote storage device to its local memory via the HTTP protocol and executes the loading.

[0036] In some embodiments, the startup configuration script further includes network initialization parameters and startup control instructions; The network initialization parameters are used to configure and activate the network environment of the test device after the operating system kernel is loaded. Specifically, during the transition from the basic network boot phase to the kernel loading phase, the network environment of the test device needs to be reconfigured to adapt to the requirements of RDMA communication. The network initialization parameters are used to instruct the test device to correctly configure network attributes such as the IP address, subnet mask, and routing of the RDMA network card after loading the kernel, so as to ensure network connectivity for establishing an RDMA link with the remote storage device.

[0037] The boot control command is used to instruct the test device to load the operating system kernel and initialize the memory file system, trigger the NVMe-oF client to enable, and control the target operating system to be booted using the NVMe block device as the system boot disk after the NVMe block device is successfully mapped.

[0038] Specifically, the boot control instructions form the execution logic skeleton of the boot configuration script, strictly defining the timing of each boot operation. First, they instruct the loading of the kernel and the initialization of the memory file system, then trigger the connection operation of the NVMe-oF client, and finally execute the root file system switch after detecting the status signal of successful NVMe block device mapping, ensuring the rigor and automated execution of the remote system disk boot process.

[0039] In some embodiments, the remote storage connection parameters include the identification information of the target NVMe subsystem, the identification information of the target NVMe namespace, the transmission protocol type, the network address of the remote storage device, and the port corresponding to the NVMe-oF server, wherein the transmission protocol type is the RDMA network transmission protocol.

[0040] Specifically, these parameters constitute a complete addressing and authentication set for establishing an NVMe-oF RDMA connection. The identification information of the target NVMe subsystem is used to locate the specific storage service entity on the storage side; the identification information of the target NVMe namespace is used to accurately locate the operating system image volume; the transport protocol type is explicitly specified as RDMA to ensure low latency; and the network address and port provide the specific communication endpoints for the network layer and transport layer.

[0041] In some embodiments, the NVMe-oF server includes at least one NVMe subsystem, the NVMe subsystem includes at least two NVMe namespaces, and each NVMe namespace stores system files for an operating system; Specifically, the remote storage device adopts a logically isolated centralized storage architecture. By dividing multiple independent NVMe namespaces under an NVMe subsystem, different versions or distributions of operating system system files are stored separately. This architecture allows multiple operating system images to be logically independent and non-interfering, and are centrally stored on the same physical storage medium, which greatly facilitates the unified operation and maintenance and elastic expansion of the test system disk.

[0042] The third request carries the identification information of the target NVMe namespace, which is used to enable the NVMe-oF server to expose the target NVMe namespace only to the test device, and other NVMe namespaces are not mapped to the NVMe block device of the test device during the current startup process.

[0043] Specifically, based on the fine-grained access control mechanism of the NVMe-oF protocol, the test device accurately specifies the namespace identifier to be mounted in the third request. When processing the connection, the NVMe-oF server executes a strict selective mapping strategy, exposing only the target namespace to the test device, while hiding other unspecified namespaces under the same subsystem. This effectively avoids device identifier conflicts, file system mounting chaos, or data interference caused by the simultaneous exposure of multiple operating system root partitions.

[0044] In some embodiments, the method further includes: Step S60: Automatically update the boot mapping configuration file using an automated control tool, map the identification information of the test device to the identification information of the new operating system, and restart the test device to load the new operating system and execute the network card test task.

[0045] Specifically, after completing the network card testing task for the current operating system, if cross-system testing is required, the automated control tool will directly modify the boot mapping configuration file on the remote storage device (for example, changing the system corresponding to the test device's MAC address to the new operating system identifier). After the configuration is updated, the test device is triggered to restart. In the next boot cycle, the test device will automatically obtain the boot configuration script containing the new system connection parameters, thereby seamlessly loading and switching to the new operating system environment. The entire switching process does not require manual login intervention, realizing unattended continuous operation in multi-operating system testing scenarios.

[0046] To more clearly illustrate the specific application process of the above testing methods in multi-operating system switching scenarios, the following detailed explanation is based on a specific example of smart network card compatibility testing.

[0047] Suppose we need to perform multi-operating system compatibility verification on a certain model of smart network interface card (such as the Crete standard card). We need to test its network connectivity under Ubuntu 22.04 and RHEL 8.6 operating systems respectively. The test environment includes a test device (its network card MAC address for PXE boot is 44:1a:4c:0f:c6:23), a remote boot device, and a remote storage device. The remote storage device is configured with an NVMe-oF subsystem, which is divided into Namespace1 (for storing Ubuntu 22.04 system files) and Namespace 2 (for storing RHEL 8.6 system files).

[0048] Phase 1: Performing network card testing in the Ubuntu 22.04 environment; First, the test scheduling system sets the boot mapping configuration file on the remote storage device to {"44:1a:4c:0f:c6:23": "ubuntu-22.04"}.

[0049] After the test device is powered on, steps S10 to S20 in the above embodiment are executed: the BIOS of the test device calls the PXE function of the network card, obtains the IP address and TFTP download address from the remote boot device through the DHCP protocol, and downloads and runs the network boot loader (iPXE).

[0050] Next, step S30 is executed: iPXE sends a second request to the remote storage device with the MAC address 44:1a:4c:0f:c6:23 of the test device. The boot control service of the remote storage device queries the boot mapping configuration file, determines that the target operating system is Ubuntu 22.04, and dynamically generates a boot configuration script containing the Namespace 1 connection parameter and sends it to the test device.

[0051] Then, steps S40 to S50 are executed: The test device parses the startup configuration script, enables the NVMe-oF client in the initialization of the memory file system, connects to the NVMe-oF server of the remote storage device via RDMA network, and requests mapping of Namespace 1. After successful mapping, the test device switches the root file system to the remote NVMe block device, completes the boot of the Ubuntu 22.04 system, and after the operating system is ready, the test device automatically loads the Ubuntu version driver for the smart network card and performs a network ping test.

[0052] Phase Two: Quickly switch to the RHEL 8.6 environment and perform network card testing. After the Ubuntu test is completed, the cross-system switching process in step S60 begins: the automated control tool of the test scheduling system directly updates the boot mapping configuration file on the remote storage device to {"44:1a:4c:0f:c6:23": "rhel-8.6"} and issues a restart command to the test device.

[0053] After the test device restarts, the process from S10 to S30 is repeated. This time, because the startup mapping configuration file has been changed, the startup configuration script issued by the remote storage device now contains the connection parameters for Namespace 2.

[0054] When step S40 is executed again, the third request sent by the NVMe-oF client of the test device to the remote storage device carries the identifier of Namespace 2. The remote storage device performs a selective mapping policy, exposing only Namespace 2 (RHEL system disk) to the test device, while hiding Namespace 1 (Ubuntu system disk), thus avoiding mount conflicts.

[0055] Finally, in step S50, the test device boots from the mapped Namespace 2 as the system disk, enters the RHEL8.6 environment, and automatically executes the network card test task under this system.

[0056] Based on the complete execution process of the above test examples, it can be seen that the embodiments of this application have the following significant technical effects compared with the prior art: (1) In the above example, switching from Ubuntu to RHEL is essentially just "changing a string value in the configuration file from ubuntu-22.04 to rhel-8.6 and restarting", which completely eliminates the manual intervention process that takes tens of minutes in the traditional solution, such as "entering BIOS to change the boot entry → formatting the local hard disk → writing the RHEL image → configuring the network environment". The test device can autonomously sense the configuration change and load the corresponding environment each time it restarts, realizing continuous automated testing across operating systems and greatly improving the absolute efficiency of network card testing.

[0057] (2) In the traditional testing architecture, two physical servers must be purchased to cover both Ubuntu and RHEL simultaneously. However, in the architecture described in this application embodiment, a test device is "without a system disk" at the physical level; it exists merely as a temporary computing node. All operating system entities (Namespace 1 and Namespace 2) are intensively sliced ​​and stored on a remote storage server. If testing of systems such as CentOS and Rocky needs to be added, no additional test physical machines are required; only a Namespace needs to be added to the storage server. This "one machine, multiple systems, dynamic allocation on demand" model maximizes the utilization of hardware resources and significantly reduces the procurement and maintenance costs of the network card test cluster.

[0058] (3) While the traditional PXE memory boot solution is flexible, it becomes invalid upon reboot. In this embodiment, the test device is mapped to an NVMe block device based on an RDMA network. When the network card undergoes a stability stress test in the Ubuntu environment for several hours, all test logs and crash dump files are persistently written to the remote Namespace 1. Even if the test device is unexpectedly powered off and restarted, as long as the configuration remains unchanged, it can still enter the original Ubuntu environment to restore the scene. At the same time, due to the use of RDMA network to bypass the kernel protocol stack and zero-copy technology, the read and write latency of this remote persistent disk is extremely low, ensuring that the performance indicators (such as throughput and latency) of the tested smart network card are not interfered with while the operating system is booted through the network disk, thus guaranteeing the accuracy and reliability of the test results.

[0059] Another embodiment of this application provides a network interface card (NIC) testing device, the testing device including a module for performing the methods described in the above embodiments of this application.

[0060] Specifically, the test equipment in this embodiment can be logically divided into the following functional modules that work together: The power-on startup module is used to call the pre-boot execution environment function of the network card after power-on startup, and send a first request to the remote startup device to obtain the network boot loader; A network boot module is used to load and execute the network bootloader, and send a second request to a remote storage device through the network bootloader; wherein the second request carries the identification information of the test device; and receive a startup configuration script generated by the remote storage device based on the identification information of the test device, wherein the startup configuration script includes at least remote storage connection parameters, and the remote storage connection parameters are used to indicate the access path of the target remote system disk; The startup configuration module is used to parse and execute the startup configuration script, establish a connection with the remote storage device through the NVMe-oF protocol based on RDMA network transmission according to the remote storage connection parameters, and map the target NVMe namespace in the remote storage device to the NVMe block device of the test device; wherein, the target NVMe namespace stores the system files of the target operating system; The test control module is used to load and start the target operating system using the NVMe block device as the system boot disk, and to execute the test tasks of the network card; and The test configuration module is used to automatically update the boot mapping configuration file through an automated control tool, map the identification information of the test device to the identification information of the new operating system, and restart the test device so that the test device loads the new operating system and executes the test task of the network card.

[0061] It should be noted that the testing equipment in this embodiment corresponds to the method in the above embodiments. Therefore, any details of the testing equipment not described in this embodiment can be obtained by referring to the testing method in the above embodiments, and will not be repeated in this embodiment.

[0062] See Figure 2 Another embodiment of this application provides a network interface card (NIC) testing system, including a remote boot device 20, a remote storage device 30, and at least one NIC testing device 10 as described in the above embodiments of this application. The remote boot device 20 is used to provide the network boot parameters and the network boot loader file address to the testing device 10; the remote storage device 30 is used to provide the boot configuration script to the testing device 10 and map the target NVMe namespace to the NVMe block device of the testing device 10.

[0063] Specifically, the test system in this embodiment forms a network boot architecture that coordinates basic booting and centralized storage. The remote boot device 20 is responsible for providing initial network boot services, while the remote storage device 30 serves as a centralized storage pool and boot policy scheduling center. On one hand, it provides high-speed remote block device mapping through an NVMe-oF server; on the other hand, it dynamically generates and distributes boot configuration scripts by maintaining boot mapping configuration files, thereby centrally allocating the target operating system to be loaded by each test device 10 at each boot. This system architecture enables centralized management and on-demand distribution of operating system images, allowing a small number of basic network and storage nodes to support parallel testing of multiple operating systems across a large cluster of test devices 10.

[0064] Another embodiment of this application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the network card testing method described in the above embodiments of this application.

[0065] Specifically, the computer-readable storage medium can be any medium that can contain, store, transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device; for example, the computer-readable storage medium can include, but is not limited to: electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media; specific examples include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, or any suitable combination of the foregoing; when the computer program is loaded onto a computer or other programmable data processing device, it causes the computer or other programmable data processing device to perform a series of operational steps to produce computer-implemented processing, such that the instructions executed on the computer or other programmable device can implement the steps in the methods of the above embodiments.

[0066] Another embodiment of this application provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the network card testing method as described in the above embodiments of this application.

[0067] Specifically, the computer program product may be embodied as program code for causing a computer system to perform some or all of the steps of the method described in the embodiments of this application; the computer program product may be one or more computer-readable media on which computer-readable program code is stored; the computer-readable program code may be accessed, retrieved, loaded and executed by one or more processors; various components of the computer program product may be implemented according to various programming languages ​​and / or technologies; the program code may be written using any combination of one or more programming languages ​​including assembly language, C / C++, Perl, Python, etc.; the program code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server; in the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a local area network or a wide area network, or may be connected to an external computer.

[0068] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many updates and modifications will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for testing a network interface card (NIC), applied to a test device with the NIC to be tested installed, characterized in that, The method includes: After power-on startup, the pre-boot execution environment function of the network card is invoked to send a first request to the remote boot device to obtain the network boot loader; The network bootloader is loaded and executed, and a second request is sent to the remote storage device through the network bootloader; wherein the second request carries the identification information of the test device; The system receives a startup configuration script generated by the remote storage device based on the identification information of the test device. The startup configuration script includes at least remote storage connection parameters, which are used to indicate the access path of the target remote system disk. The startup configuration script is parsed and executed. Based on the remote storage connection parameters, a connection is established with the remote storage device via the NVMe-oF protocol based on RDMA network transmission. The target NVMe namespace in the remote storage device is mapped to the NVMe block device of the test device. The target NVMe namespace stores the system files of the target operating system. Using the NVMe block device as the system boot disk, the target operating system is loaded and started, and the network card test task is executed.

2. The method according to claim 1, characterized in that, The step of invoking the pre-boot execution environment function of the network card to send a first request to the remote boot device to obtain the network boot loader includes: The pre-boot execution environment function of the network card is invoked to send a first request to the remote boot device, and the network boot parameters and network boot loader file address returned by the remote boot device are received. Configure the network environment of the test device according to the network startup parameters, and download the network bootloader according to the network bootloader file address.

3. The method according to claim 1, characterized in that, The remote storage device stores a boot mapping configuration file, which includes the correspondence between the identification information of the test device and the identification information of the target operating system. The startup configuration script is specifically a script generated by the remote storage device based on the identification information of the test device, which queries the startup mapping configuration file to determine the identification information of the target operating system.

4. The method according to claim 1, characterized in that, The process of parsing and executing the startup configuration script, establishing a connection with the remote storage device via the NVMe-oF protocol based on RDMA network transmission according to the remote storage connection parameters, and mapping the target NVMe namespace in the remote storage device to the NVMe block device of the test device includes: The system loads the operating system kernel and initializes the memory file system. Based on the initialized memory file system, it enables the NVMe-oF client. Based on the NVMe-oF client, it sends a third request to the NVMe-oF server on the remote storage device, so that the NVMe-oF server maps the target NVMe namespace to the NVMe block device of the test device. The NVMe-oF server includes the target NVMe namespace.

5. The method according to claim 4, characterized in that, The startup configuration script also includes network initialization parameters and startup control commands; The network initialization parameters are used to configure and activate the network environment of the test device after the operating system kernel is loaded. The boot control command is used to instruct the test device to load the operating system kernel and initialize the memory file system, trigger the NVMe-oF client to enable, and control the target operating system to be booted using the NVMe block device as the system boot disk after the NVMe block device is successfully mapped.

6. The method according to claim 5, characterized in that, The remote storage connection parameters include the identification information of the target NVMe subsystem, the identification information of the target NVMe namespace, the transmission protocol type, the network address of the remote storage device, and the port corresponding to the NVMe-oF server. The transmission protocol type is RDMA network transmission protocol.

7. The method according to claim 4, characterized in that, The NVMe-oF server includes at least one NVMe subsystem, and the NVMe subsystem includes at least two NVMe namespaces, each of which stores system files for an operating system. The third request carries the identification information of the target NVMe namespace, which is used to enable the NVMe-oF server to expose the target NVMe namespace only to the test device, and other NVMe namespaces are not mapped to the NVMe block device of the test device during the current startup process.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The automated control tool automatically updates the boot mapping configuration file, maps the identification information of the test device to the identification information of the new operating system, and restarts the test device to load the new operating system and execute the network card test task.

9. A testing device for network interface cards (NICs), characterized in that, The testing equipment includes a module for performing the method according to any one of claims 1 to 8.

10. A network interface card (NIC) testing system, characterized in that, The test device includes a remote boot device, a remote storage device, and at least one network interface card as described in claim 9. The remote boot device is used to provide the network boot parameters and the network bootloader file address to the test device. The remote storage device is used to provide the boot configuration script to the test device and map the target NVMe namespace to the NVMe block device of the test device.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the test method for the network interface card as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the test method for a network interface card as described in any one of claims 1 to 8.

Images