Packet receiving and sending test method and device driven by network card

Abstract

The invention provides a network card driven packet receiving and sending test method and device, and relates to the field of drive function test.A test message is generated through a test application based on an IOCTL interface, a network card driver is triggered by means of an IOCTL command to execute packet receiving and sending logic, direct interaction with the driver is achieved, and the physical transmission link of hardware is skipped; and the software logic processing capability of the driver is directly tested. The function correctness is verified through the test result returned by the driver, the data returned by the network card driver is determined by the software logic of the driver, only the driver processing result and the expected result need to be compared in the whole process, and whether hardware actually completes physical transmission of the message or not does not need to be concerned. And the dependence on hardware is fundamentally eliminated.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and in particular to a method and apparatus for testing the sending and receiving of network interface card (NIC) drivers. Background Technology

[0002] In the field of chip development, the verification phase is crucial, with its time and resource consumption constantly increasing. Efficient verification plays a decisive role in shortening chip development cycles, reducing costs, and ensuring product quality. As a key component of data communication, the correctness and stability of the network interface card (NIC) driver software have a profound impact on the overall chip performance. Traditionally, NIC drivers rely on the managed NIC hardware devices for packet transmission and reception testing. During the chip verification phase, when the NIC hardware platform is missing due to incomplete RTL design, verification of the NIC driver's packet transmission and reception channels cannot be performed.

[0003] There is a method for testing driver software logic in advance without relying on the network card hardware platform, namely, developing a VDK model. This method simulates the network card hardware behavior through software, connects to a virtual machine via a virtual PCIe bus, installs the network driver in the virtual machine, and then verifies the packet transmission and reception pathways of the driver software. However, this method has many drawbacks. For example, it requires developing software to simulate register-level network card hardware behavior, including PCIe enumeration and on-chip firmware operation, which involves a huge amount of development work and a long development cycle. Furthermore, it depends on a specific environment, requiring the purchase of additional licenses, resulting in high costs. In addition, this solution is essentially a software-level system-level test; the driver software needs to be integrated with the VDK model and firmware for testing.

[0004] Prior to this stage, from the perspective of network card driver developers, there is an urgent need for a unit testing method that targets only the driver's packet sending and receiving channels, so as to achieve independent and efficient verification of the network card driver during the chip verification stage, reduce dependence on hardware platforms, and shorten the chip verification cycle. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a method and apparatus for testing the packet transmission and reception of a network card driver, which can perform packet transmission and reception channel testing of the network card driver without relying on the network card hardware platform during the chip verification stage.

[0006] In a first aspect, embodiments of the present invention provide a method for testing the packet sending and receiving functions of a network interface card (NIC) driver, which is installed in an electronic device. The method includes: responding to a test command by generating a test message through a pre-configured IOCTL test application; wherein the IOCTL test application is an application implemented based on the IOCTL interface; sending an IOCTL command to the NIC driver based on the test message to trigger the NIC driver to perform packet sending or receiving tests; receiving test results returned by the NIC driver based on the IOCTL command; and testing the packet sending and receiving functions of the NIC driver based on the test results.

[0007] In conjunction with the first aspect, the present invention provides a first implementation of the first aspect, wherein the test instruction includes a packet sending test instruction or a packet receiving test instruction; the step of generating a test message through a pre-configured IOCTL test application includes: if the test instruction is a packet sending test instruction, then calling the IOCTL interface to generate a packet sending test message through the IOCTL interface.

[0008] In conjunction with the first aspect, this embodiment of the invention provides a second implementation of the first aspect, wherein the step of sending an IOCTL command to the network card driver based on a test message includes: receiving a packet sending test message through the network card driver, the packet sending test message being used to trigger the network card driver to perform a packet sending test; wherein the packet sending test process includes: receiving a socket buffer issued by the protocol stack through the packet sending channel of the network card driver, the socket buffer containing the packet sending test message; parsing the socket buffer, organizing the sending queue elements corresponding to the packet sending test message according to the software and hardware interface definition corresponding to the network card driver; writing the sending queue elements into the direct memory access address of the sending queue of the network card driver, and updating the producer index value of the sending queue.

[0009] In conjunction with the first aspect, this embodiment of the invention provides a third implementation of the first aspect, wherein the step of receiving the test result returned by the network interface card (NIC) driver based on the IOCTL command includes: responding to the IOCTL command through the IOCTL response module configured in the NIC driver; reading the sending queue element corresponding to the packet test message according to the current producer index value of the packet sending queue of the NIC driver; parsing the packet address corresponding to the packet test message based on the hardware and software interface definition of the NIC driver; reading the packet content from the packet address; and returning the packet content and the sending queue element to the IOCTL test application to obtain the test result of the NIC driver for the IOCTL command.

[0010] In conjunction with the first aspect, this invention provides a fourth implementation of the first aspect, wherein the step of testing the packet sending and receiving functions of the network card driver based on the test results includes: performing data verification on the packet content and the sending queue elements respectively; when the data verification results of the packet content and the sending queue elements both indicate that the verification is passed, it is determined that the packet sending test of the network card driver is successful; otherwise, the packet sending test of the network card driver fails; the data verification of the packet content includes: performing consistency verification between the packet content and the packet sending test packet; the data verification of the sending queue elements includes: verifying the hardware and software interface definition of the network card driver on the sending queue elements.

[0011] In conjunction with the first aspect, this embodiment of the invention provides a fifth implementation of the first aspect, wherein the above method further includes: if a packet sent by the packet receiving interface of the network card driver is detected, then it is determined that a packet receiving test instruction has been received; the step of generating a test packet through a pre-configured IOCTL test application further includes: calling the IOCTL interface to generate a packet receiving test packet through the IOCTL interface.

[0012] In conjunction with the first aspect, this invention provides a sixth implementation of the first aspect, wherein the step of sending an IOCTL command to the network card driver based on a test message includes: responding to a received packet test message through the IOCTL response module configured in the network card driver; the received packet test message is used to trigger a packet test on the network card driver; wherein the packet test process includes: obtaining a free receive queue element from the memory of the packet receive channel of the network card driver through the IOCTL response module; extracting the packet address and completion queue element address from the receive queue element; writing the received packet test message to the packet address, and organizing a completion queue element for the received packet test message according to the hardware and software interface definition of the network card driver; and writing the completion queue element to the completion queue element address.

[0013] In conjunction with the first aspect, this embodiment of the invention provides a seventh implementation of the first aspect, wherein the step of receiving the test result returned by the network card driver based on the IOCTL command includes: obtaining the socket buffer uploaded by the network card driver from the monitored packets, and determining the socket buffer as the test result returned by the network card driver based on the IOCTL command; wherein the generation process of the socket buffer includes: polling the address of the completion queue element through the packet receiving channel of the network card driver, reading the corresponding completion queue element and packet content; and organizing the completion queue element and packet content into a socket buffer.

[0014] In conjunction with the first aspect, this embodiment of the invention provides an eighth implementation of the first aspect, wherein the step of testing the packet sending and receiving function of the network card driver based on the test results includes: performing data verification on the completion queue element and the packet content in the monitored packet respectively; when the verification results corresponding to the completion queue element and the packet content respectively indicate that the verification is passed, it is determined that the packet receiving test of the network card driver is successful; otherwise, the packet receiving test of the network card driver fails; the data verification of the packet content includes: performing consistency verification between the packet content and the packet receiving test packet; the data verification of the completion queue element includes: comparing and verifying the packet count statistics represented by the completion queue element with the packet count results pre-recorded for the packet receiving test packet.

[0015] Secondly, embodiments of the present invention provide a packet sending and receiving testing device for a network interface card (NIC) driver. The NIC driver is installed in an electronic device. The device includes: a response module, used to respond to test commands and generate test messages through a pre-configured IOCTL test application; wherein the IOCTL test application is an application implemented based on the IOCTL interface; an execution module, used to send IOCTL commands to the NIC driver based on the test messages to trigger the NIC driver to perform packet sending or receiving tests; a data receiving module, used to receive test results returned by the NIC driver based on the IOCTL commands; and an output module, used to test the packet sending and receiving functions of the NIC driver based on the test results.

[0016] In summary, the network interface card (NIC) driver packet transmission and reception testing method and apparatus provided in this invention focuses on the correctness of the driver's core functions, fundamentally eliminating dependence on hardware. Test packets are generated through a test application based on the IOCTL interface, and the NIC driver is triggered to execute packet transmission and reception logic via IOCTL commands. This allows direct interaction with the driver, bypassing the physical transmission stage of the hardware and directly testing the driver's software logic processing capabilities. The correctness of the function is then verified through the test results returned by the driver. The data returned by the NIC driver is determined by the driver's software logic; the entire process only requires comparing the "driver processing result" with the "expected result," without needing to consider whether the hardware actually completed the physical transmission of the packets, thus completely eliminating dependence on hardware.

[0017] In summary, the embodiments of the present invention can independently complete the testing of the network card driver's packet transmission and reception channels during the chip verification stage (before the hardware is ready), discovering driver software defects in advance and reducing the time spent on "cross-checking driver and hardware problems" during subsequent software and hardware integration debugging. Furthermore, the embodiments of the present invention do not require the development of a VDKmodel (reducing development workload), the purchase of a license (reducing costs), or the occupation of EMU / FPGA resources (improving hardware resource utilization), ultimately achieving the core effects of shortening the chip verification cycle and improving driver testing efficiency.

[0018] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description, claims, and drawings. To make the foregoing objects, features, and advantages of the invention more apparent and understandable, preferred embodiments are described in detail below with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 A flowchart of a packet sending and receiving test method for a network card driver provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another method for testing the packet transmission and reception of a network interface card (NIC) driver provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another method for testing the packet transmission and reception of a network interface card (NIC) driver provided in an embodiment of the present invention; Figure 4 This invention provides a network interface card (NIC) driver packet sending and receiving test architecture diagram. Figure 5 This is a schematic diagram of the structure of a network card driver packet sending and receiving test device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] Driver software is generally strongly tied to the hardware devices it manages, requiring the corresponding hardware devices to be installed on the host computer for the driver to function and be tested. The network interface card (NIC) chip design and verification process typically includes the following stages: 1. Designing the driver and defining the NIC chip's hardware and software interfaces; 2. The software team develops the network driver software, and the hardware team develops the chip's hardware RTL logic; 3. Compiling an image based on the developed RTL to run on the specific hardware platform (EMU / FPGA); 4. Performing basic version function tests (such as on-chip firmware operation, PCIe enumeration tests, etc.); 5. Installing the NIC driver on the host computer and performing joint debugging with the NIC hardware to test the NIC's packet transmission and reception pathways. Corresponding to the above background technology, traditional packet transmission and reception testing requires hardware DMA to move packets in the sending direction and hardware to generate CQE and trigger driver processing in the receiving direction. When the RTL design is incomplete or the hardware platform is missing, existing technologies cannot verify the driver's packet transmission and reception channel logic in advance, easily prolonging the subsequent hardware and software integration debugging cycle due to driver-related issues.

[0023] To address the aforementioned technical problems, this invention provides a method and apparatus for testing the packet transmission and reception of a network interface card (NIC) driver. The aim is to achieve early independent verification of the driver's packet transmission and reception channels by eliminating reliance on hardware and complex simulation environments through a software-level interaction mechanism.

[0024] To facilitate understanding of this embodiment, a method for testing the packet transmission and reception of a network card driver disclosed in this embodiment of the invention will first be described. This network card driver is installed in an electronic device, as described below. Figure 1 The method includes the following steps: Step S102: In response to the test command, generate a test message through the pre-configured IOCTL test application.

[0025] IOCTL (Input / Output Control) is a system call interface provided by the operating system that enables direct interaction between user-mode applications and kernel-mode device drivers, transmitting control commands, test data, and result information. It is a key technology channel that bypasses the complex traditional "user-mode-protocol stack-driver" chain and achieves driver-oriented control.

[0026] This invention employs an IOCTL testing application based on the IOCTL interface to perform packet sending and receiving tests on network interface card (NIC) drivers. This IOCTL testing application is deployed in user space and, in one implementation, is developed based on the operating system's IOCTL interface. Upon receiving an external command to "trigger packet sending test" or "trigger packet receiving test," the application determines the specific type of the test packet based on the corresponding test scenario. For example, for packet sending tests, it generates ordinary Layer 2 packets or Checksum offload packets; for packet receiving tests, it generates normal packets or Checksum error packets, ensuring that the generated packets accurately correspond to the functionalities that the driver needs to verify (such as Checksum offload logic and error packet detection logic).

[0027] Step S104: Send an IOCTL command to the network card driver based on the test message to trigger the network card driver to perform packet sending or receiving tests.

[0028] After generating test packets based on the IOCTL test application, structured commands (i.e., IOCTL commands) are sent to the network card driver through the IOCTL channel formed between the IOCTL test application and the network card driver. This triggers the driver to execute the packet sending or receiving test process, without relying on the network card hardware (EMU / FPGA) or VDK model.

[0029] Step S106: Receive the test results returned by the network card driver based on the IOCTL command.

[0030] Step S108: Test the packet sending and receiving functions of the network card driver based on the test results.

[0031] Upon receiving the corresponding IOCTL command, the network card driver triggers the execution of the corresponding test process, thereby obtaining the corresponding structured test data (i.e., the test results mentioned above). By analyzing and verifying this structured test data, the test status of the network card driver's packet sending and receiving functions can be determined. In one implementation, the test results can be determined by using the operating system's native IOCTL system call channel to pass data back from kernel mode to the user-mode IOCTL test application. This transmission path reuses the "IOCTL command issuance path" in step S104 above, eliminating the need to establish an additional communication link. Data backhaul can be achieved solely through software interaction between the driver and the IOCTL test application, forming a network card driver packet sending and receiving channel unit test system that is completely independent of network card hardware or VDK model.

[0032] In summary, the network card driver packet sending and receiving test method provided by this embodiment of the invention generates test packets through a test application based on the IOCTL interface, triggers the network card driver to execute packet sending and receiving logic with the help of IOCTL commands, and then verifies the correctness of the function through the test results returned by the driver. This allows for the early detection of driver-side problems before the hardware is ready, thus shortening the chip verification cycle.

[0033] In this embodiment of the invention, the driver interacts directly via the IOCTL interface, bypassing the physical transmission stage of the hardware and directly testing the driver's software logic processing capabilities. It focuses on the correctness of the driver's core functions, fundamentally eliminating dependence on hardware. This embodiment generates test packets corresponding to the required test types through an IOCTL test application implemented based on the IOCTL interface. The test packets generated in user space simulate the packets "received" by the hardware, eliminating the need for external packet injection via network card hardware or simulating hardware packet injection behavior using the VDK model.

[0034] Furthermore, IOCTL (Input / Output Control) is the standard interface for interaction between user-space and kernel-space drivers. By customizing IOCTL commands, user-space generated test packets can be directly "injected" into the driver's packet transmission and reception process, triggering the network card driver's test process in a targeted manner. Based on the data returned by the network card driver, packet transmission and reception functionality is tested. The data returned by the network card driver is determined by the driver's software logic and is independent of the hardware's physical transmission capabilities. By verifying the correctness of this returned data, the driver's packet transmission and reception functions can be tested independently. The entire process only requires comparing the "driver processing result" with the "expected result," without needing to concern oneself with whether the hardware actually completed the physical transmission of the packets, completely eliminating dependence on the hardware.

[0035] In summary, the embodiments of the present invention can independently complete the testing of the network card driver's packet transmission and reception channels during the chip verification stage (before the hardware is ready), discovering driver software defects in advance and reducing the time spent on "cross-checking driver and hardware problems" during subsequent software and hardware integration debugging. Furthermore, the embodiments of the present invention do not require the development of a VDKmodel (reducing development workload), the purchase of a license (reducing costs), or the occupation of EMU / FPGA resources (improving hardware resource utilization), ultimately achieving the core effects of shortening the chip verification cycle and improving driver testing efficiency.

[0036] Furthermore, based on the above embodiments, this embodiment of the invention also provides another method for testing the packet sending and receiving of a network card driver, wherein the test command includes a packet sending test command or a packet receiving test command; this embodiment of the invention first describes the steps for packet sending testing. (Refer to...) Figure 2 The method includes the following steps: Step S202: Respond to the test command. If the test command is a packet sending test command, call the IOCTL interface to generate a packet sending test message through the IOCTL interface.

[0037] IOCTL commands can be predefined and corresponding test instructions can be issued according to test requirements. When the test system initiates a "packet sending test," the user-space IOCTL test application acts as the execution entity, first identifying the test instruction type as a "packet sending test instruction." At this time, the IOCTL test application starts the linkage process of packet generation and instruction issuance. The core purpose is to pass the test stimulus (packet sending test message) to the kernel-space network card driver through the IOCTL interface, triggering its packet sending channel logic processing. "Calling the IOCTL interface" does not directly generate packets through IOCTL, but rather makes the IOCTL interface act as the interaction channel between user space and kernel space throughout the entire process. In specific implementation, packet sending test messages can be generated first through the raw socket interface of the TCP / IP protocol stack. Depending on the test requirements, the message can be constructed as: a normal Layer 2 message (such as a standard Ethernet frame); or a Checksum offload message (before generation, the Checksum offload function of the network interface under test needs to be enabled via the ethtool command to simulate a hardware offload scenario). After generating a packet, the IOCTL test application sends the packet to the protocol stack via the raw socket interface, and then the protocol stack passes it to the packet sending channel of the network card driver (during this process, the packet is encapsulated in an SKB (socket buffer)). Simultaneously, the IOCTL test application records the original content of the packet (such as data and length) and its offload attributes as a basis for subsequent verification.

[0038] Step S204: Receive packet sending test messages through the network card driver to trigger the network card driver to perform packet sending tests.

[0039] This invention embodiment uses the network interface card (NIC) driver to receive packet sending test messages and initiate its own execution logic to perform packet sending tests. The packet sending test process includes: 1) Receiving a socket buffer from the protocol stack through the NIC driver's packet sending channel; the socket buffer containing the packet sending test message; 2) Parsing the socket buffer and organizing the sending queue elements corresponding to the packet sending test message according to the NIC driver's corresponding hardware and software interface definitions; 3) Writing the sending queue elements to the NIC driver's direct memory access address for the sending queue and updating the producer index value of the sending queue.

[0040] In practice, the test packets are generated by the IOCTL test application through the raw socket interface of the TCP / IP protocol stack and sent to the network card driver's packet sending channel in the form of SKB (Socket Buffer). Upon receiving the SKB, the network card driver automatically initiates its core execution logic: 1- Parse the packet sending test packets in the SKB, extracting key information such as packet length, data content, and checksum unloading attributes; 2- Organize this information into SQE (Send Queue Element) according to the hardware and software interface definition agreed upon between the network card driver and the hardware; 3- Write the SQE to the DMA address of the send queue (SQ) and update the PI (Producer Index) value of the send queue. This process is automatically handled by the network card driver without external intervention, thus enabling verification of the driver's own software logic.

[0041] Step S206: Receive the test results returned by the network card driver based on the IOCTL command.

[0042] Based on the IOCTL interface, direct interaction between user-mode applications and kernel-mode device drivers can be achieved. In this embodiment of the invention, an IOCTL response module is added to the network card driver as a dedicated kernel-mode processing unit, forming a closed-loop test architecture of "host-side IOCTL test application - IOCTL channel - network card driver IOCTL response module". Independent testing of the driver's packet sending and receiving channels is achieved only through software interfaces, completely eliminating the dependence on network card hardware (EMU / FPGA) or VDK model.

[0043] After the message is sent to the driver, the IOCTL test application also sends a customized IOCTL command corresponding to the above test requirements to the network card driver by calling the IOCTL interface to initiate a verification request. Furthermore, the IOCTL response module configured in the network card driver responds to the received IOCTL command, identifying it as a "packet sending test result retrieval request," distinguishing it from packet receiving tests or other commands. Corresponding to the above test process, the IOCTL response module marks the location of the latest written SQE based on the current producer index (PI) value of the network card driver's send queue (SQ), which is automatically updated by the driver after receiving an SKB. Further, based on the PI value, it locates the DMA (Direct Memory Access) address corresponding to the send queue and reads the SQE (send queue element) stored at that location. The SQE is a key data structure generated by the driver according to the hardware and software interface definition, containing information such as message length, memory address, and checksum unloading field.

[0044] Furthermore, based on the software and hardware interface definitions agreed upon by the driver and hardware (such as SQE field format and memory address mapping rules), the message address is parsed: The "memory storage address of the packet test message" (i.e., the actual memory location where the message data is stored after the driver processes the SKB) is extracted from the read SQE. The message content is then read: based on the parsed message address, the complete message data is read from memory to ensure that the actual content after driver processing is obtained (forming a comparison benchmark with the original sent message).

[0045] Furthermore, the processed data is returned to the user-space IOCTL test application via the IOCTL channel. The returned content includes: 1- Send Queue Element (SQE): Complete SQE structure data, used to verify whether the queue element generated by the driver conforms to the hardware and software interface definition (e.g., field integrity, format correctness). 2- Message Content: The actual message data read from the memory address, used to verify whether the driver completely retains the message information during processing (no loss or tampering).

[0046] Step S208: Test the packet sending and receiving functions of the network card driver based on the test results.

[0047] Corresponding to the above steps, data verification is performed on the message content and the sending queue elements respectively. When the data verification results of both the message content and the sending queue elements indicate that the verification has passed, the packet sending test of the network card driver is determined to be successful; otherwise, the packet sending test of the network card driver fails.

[0048] The data validation of the message content includes: verifying the consistency of the message content with the packet sending test message. In practice, this involves comparing the returned message content with the initially sent original message to verify the accuracy of the driver's data transmission. The data validation of the sending queue elements includes: verifying the hardware and software interface definitions of the network card driver for the sending queue elements. In practice, this includes: checking whether the SQE message length, Checksum unload field, etc., conform to the interface definition, and verifying the driver's logic for processing message attributes. If both validations pass, the network card driver's packet sending channel logic is deemed correct.

[0049] Furthermore, a detailed explanation of the packet reception test is provided. (Refer to...) Figure 3 The method includes the following steps: Step S302: If a packet sent by the packet receiving interface of the network card driver is detected, it is confirmed that the packet receiving test command has been received.

[0050] The packet reception test simulates the driver's processing flow after the hardware receives a packet, and the driver uploads the packet to the protocol stack after receiving it. Therefore, the IOCTL test application determines that the preconditions for the packet reception test have been met (i.e., "received packet reception test command") by listening for packet activity on this interface (even if it is the preset signal for test start), and then starts the subsequent packet generation and sending process.

[0051] Step S304: Call the IOCTL interface to generate a packet reception test message.

[0052] The message generation logic is the same as above. The IOCTL test application can generate receive test messages through the IOCTL interface in conjunction with a raw socket. These messages can include the following: Normal messages: Standard messages conforming to the Ethernet frame format, used to verify the driver's processing logic for normal reception; Checksum error messages: Used to verify the driver's error detection capability. Before generation, the initial Checksum error count of the network interface under test needs to be recorded using the ethtool command (as a benchmark for subsequent statistical verification).

[0053] Step S306: The network card driver responds to the packet reception test message through the IOCTL response module configured in the network card driver to trigger a packet reception test on the network card driver.

[0054] The logic of the packet receiving test is the same as that of the packet sending test. In this embodiment of the invention, the software interaction between the IOCTL test application and the IOCTL response module of the network card driver is used to simulate the complete process of "hardware receiving packets - driver processing - protocol stack uploading". It does not rely on the actual network card hardware, but only reuses the core data structure and logic of the driver's packet receiving channel to realize the triggering and execution of the packet receiving test.

[0055] In practice, the IOCTL test application sends the generated packet receiving test message to the network card driver via IOCTL commands as a test stimulus. After processing the message, the IOCTL response module uploads the message to the protocol stack through the driver's packet receiving channel. Finally, the IOCTL test application listens for and verifies the message, forming a closed loop of "send-process-feedback".

[0056] Specifically, the packet reception test process includes: First, retrieving a free receive queue element (RQE, pre-allocated by the driver) from the memory of the network card driver's receive channel via the IOCTL response module. Next, extracting the packet address and completion queue element address (CQE address) from the receive queue element to represent the hardware's "receive buffer descriptor," simulating the hardware's behavior of reserving memory space for received packets. Then, extracting the "packet address" (the memory buffer address reserved by the driver for received packets) from the free RQE, and writing the receive test packet issued by the IOCTL test application to this address. Finally, according to the hardware-software interface definition agreed upon by the driver and hardware, organizing a CQE (completion queue element) containing the receive test packet attributes (such as length and checksum status), and writing it to the "CQE address" extracted from the RQE. The CQE is equivalent to the hardware's "reception completion signal," used by the IOCTL response module to simulate notifying the driver that "the packet has been received and written to the buffer, and can be further processed."

[0057] Step S308: Receive the test results returned by the network card driver based on the IOCTL command.

[0058] Through the above hardware behavior simulation, the core logic of the driver's packet receiving channel is actually triggered. The driver's packet receiving channel polls the CQE memory address. When it detects a new CQE written by the IOCTL response module, it automatically executes the packet receiving process: reading the test packet from the packet address, encapsulating it into an SKB (Socket Buffer), and uploading it to the TCP / IP protocol stack. This SKB is used to characterize the corresponding test result. Throughout the process, the driver's packet receiving logic (such as packet parsing, SKB encapsulation, and protocol stack uploading) is completely consistent with the real hardware receiving scenario, ensuring that the test results reflect the actual correctness of the driver's packet receiving function.

[0059] Step S310: Test the packet sending and receiving functions of the network card driver based on the test results.

[0060] In one implementation, the IOCTL test application listens for packets uploaded by the protocol stack via a raw socket interface. Upon receiving a test packet from the driver, it initiates verification logic: it performs data verification on the completion queue element and the packet content within the received packet. If the verification results for both the completion queue element and the packet content indicate that the verification has passed, the network card driver's packet reception test is considered successful; otherwise, the network card driver's packet reception test fails.

[0061] The data verification of the message content includes: verifying the consistency between the message content and the received test message; specifically, comparing the received message with the original test message content to verify the accuracy of the driver's data transmission. The data verification of the completed queue elements includes: comparing the message count statistics representing the completed queue elements with the pre-recorded message count results for the received test message. In one implementation, if it is a Checksum error message, the error count before and after the test is compared using the ethtool command to verify the driver's error detection capability. In summary, by transmitting test messages through the IOCTL channel and relying on the IOCTL response module to simulate the core hardware reception behavior (RQE buffer allocation, CQE completion notification), the driver's received channel logic is truly triggered. Finally, a closed loop is formed through protocol stack upload and verification, achieving hardware-independent received test triggering and execution.

[0062] In summary, the execution architecture of this invention embodiment refers to... Figure 4 , Figure 4 The system includes a user-space layer: the IOCTL test application acts as the packet producer, the IOCTL channel acts as the command sender, and result verification terminals correspond to packet reception and packet sending tests, respectively. For example, in the packet reception scenario, it listens for packet uploads from the TCP / IP protocol stack, and in the packet sending scenario, it returns data through the IOCTL interface (i.e., the IOCTL response module). The driver-space layer: the IOCTL response module receives user-space commands forwarded by the "IOCTL interface," simulating the hardware interaction process. The hardware layer: PCIe devices. In this embodiment, the PCIe device is only used to trigger the driver Probe process (making the driver believe the hardware exists and complete initialization), and there is no real data interaction throughout the test. The vendor ID / device ID of existing PCIe devices can be obtained through lspci and added to the driver device support list to determine if the driver loading conditions are met.

[0063] Based on the above embodiments, this invention also provides a network card driver packet sending and receiving test device, corresponding to the above embodiments, wherein the network card driver is installed on an electronic device. Figure 5 A schematic diagram of an embodiment of the present invention is shown, with reference to... Figure 5 The device includes: a response module 100, used to respond to test commands and generate test messages through a pre-configured IOCTL test application; wherein the IOCTL test application is an application implemented based on the IOCTL interface; an execution module 200, used to send IOCTL commands to the network card driver based on the test messages to trigger the network card driver to perform packet sending or receiving tests; a data receiving module 300, used to receive test results returned by the network card driver based on the IOCTL commands; and an output module 400, used to test the packet sending and receiving functions of the network card driver based on the test results.

[0064] The network card driver packet sending and receiving test device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0065] This invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described... Figures 1 to 3 The steps of any of the methods shown. Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the above-described steps. Figures 1 to 3 The steps of any of the methods shown. Embodiments of the present invention also provide a structural schematic diagram of an electronic device, such as... Figure 6 The diagram shown is a structural schematic of the electronic device, which includes a processor 61 and a memory 60. The memory 60 stores computer-executable instructions that can be executed by the processor 61. The processor 61 executes the computer-executable instructions to implement the above-mentioned... Figures 1 to 3 Any of the methods shown.

[0066] exist Figure 6In the illustrated embodiment, the electronic device further includes a bus 62 and a communication interface 63, wherein the processor 61, the communication interface 63, and the memory 60 are connected via the bus 62. The memory 60 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk drive. Communication between this system network element and at least one other network element is achieved through at least one communication interface 63 (which can be wired or wireless), using the Internet, wide area network, local area network, metropolitan area network, etc. Bus 62 can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, or an AMBA (Advanced Microcontroller Bus Architecture) bus. AMBA defines three types of buses: APB (Advanced Peripheral Bus), AHB (Advanced High-performance Bus), and AXI (Advanced deXtensible Interface). Bus 62 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6The diagram uses only a single double-headed arrow, but this does not imply a single bus or a single type of bus. Processor 61 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed through integrated logic circuits in the hardware of processor 61 or through software instructions. Processor 61 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor 61 reads information from the memory and, in conjunction with its hardware, completes the aforementioned tasks. Figures 1 to 3 Any of the methods shown.

[0067] The computer program product of the network card driver packet sending and receiving test method and apparatus provided in this embodiment of the invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the preceding method embodiments, which will not be repeated here. In addition, in the description of the embodiments of the invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "connection" should be interpreted broadly. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances. If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0068] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Finally, it should be noted that the above embodiments are merely specific implementations of the invention, used to illustrate the technical solutions of the invention, and not to limit it. The scope of protection of the invention is not limited thereto. Although the invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in this invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this invention, and should all be covered within the scope of protection of this invention. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A method for testing the packet transmission and reception of a network card driver, characterized in that, The network card driver is installed in the electronic device, and the method includes: In response to test commands, test messages are generated through a pre-configured IOCTL test application; wherein, the IOCTL test application is an application implemented based on the IOCTL interface; Based on the test message, an IOCTL command is sent to the network card driver to trigger the network card driver to perform packet sending or receiving tests; Receive the test results returned by the network card driver based on the IOCTL command; The packet sending and receiving functions of the network card driver were tested based on the test results.

2. The method according to claim 1, characterized in that, The test instructions include packet sending test instructions or packet receiving test instructions; The steps for generating test messages using a pre-configured IOCTL test application include: If the test instruction is a packet sending test instruction, then the IOCTL interface is invoked to generate a packet sending test message.

3. The method according to claim 2, characterized in that, The steps of sending an IOCTL command to the network card driver based on the test message include: The network card driver receives the packet sending test message, which is used to trigger the network card driver to perform a packet sending test. The packet sending test process includes: The network card driver receives a socket buffer sent by the protocol stack through the packet sending channel. The socket buffer contains the packet sending test message. The socket buffer is parsed, and according to the software and hardware interface definition corresponding to the network card driver, the sending queue elements corresponding to the packet test message are organized. Write the sending queue element to the direct memory access address of the sending queue in the network card driver, and update the producer index value of the sending queue.

4. The method according to claim 2, characterized in that, The step of receiving the test results returned by the network card driver based on the IOCTL command includes: The IOCTL command is received by the IOCTL response module configured in the network card driver. Based on the current producer index value of the packet sending queue of the network card driver, read the sending queue element corresponding to the packet sending test message; and based on the software and hardware interface definition of the network card driver, parse out the packet address corresponding to the packet sending test message. The message content is read from the message address, and the message content and the sending queue element are returned to the IOCTL test application to obtain the test results of the network card driver for the IOCTL command.

5. The method according to claim 4, characterized in that, The steps for testing the packet sending and receiving functions of the network card driver based on the test results include: Data verification is performed on the message content and the sending queue elements respectively; When both the message content and the data verification results of the sending queue element indicate that the verification is passed, the packet sending test of the network card driver is determined to be successful; otherwise, the packet sending test of the network card driver fails. The data verification of the message content includes: Perform a consistency check between the message content and the packet sending test message; The data verification of the sending queue elements includes: The hardware and software interface definitions of the network card driver are verified for the sending queue elements.

6. The method according to claim 2, characterized in that, The method further includes: If a packet sent by the packet receiving interface of the network card driver is detected, it is determined that the packet receiving test command has been received. The steps for generating test messages using a pre-configured IOCTL test application also include: The IOCTL interface is invoked to generate a packet reception test message.

7. The method according to claim 6, characterized in that, The steps of sending an IOCTL command to the network card driver based on the test message include: The network interface card (NIC) driver receives the packet reception test message through its IOCTL response module configuration; the packet reception test message is used to trigger a packet reception test on the NIC driver. The packet receiving test process includes: The IOCTL response module retrieves an idle receive queue element from the memory of the packet receiving channel of the network card driver. Extract the message address and the completion queue element address from the receive queue element; Write the packet receiving test message to the packet address, and organize the completion queue elements of the packet receiving test message according to the software and hardware interface definition of the network card driver; Write the completed queue element to the address of the completed queue element.

8. The method according to claim 7, characterized in that, The step of receiving the test results returned by the network card driver based on the IOCTL command includes: From the monitored packets, obtain the socket buffer uploaded by the network card driver, and determine the socket buffer as the test result returned by the network card driver based on the IOCTL command; The process of generating the socket buffer includes: The network card driver polls the address of the completion queue element through the packet receiving channel to read the corresponding completion queue element and message content; the completion queue element and the message content are then organized into a socket buffer.

9. The method according to claim 6, characterized in that, The steps for testing the packet sending and receiving functions of the network card driver based on the test results include: For the completed queue elements and message content in the monitored messages, data verification is performed separately; When the verification results corresponding to the completed queue element and the message content both indicate that the verification has passed, the packet receiving test of the network card driver is determined to be successful; otherwise, the packet receiving test of the network card driver fails. The data verification of the message content includes: performing a consistency verification between the message content and the received test message; The data verification of the completed queue element includes: comparing and verifying the message count statistics represented by the completed queue element with the message count results pre-recorded for the received test message.

10. A network card driver packet sending and receiving testing device, characterized in that, The network interface card driver is installed in the electronic device, and the device includes: The response module is used to respond to test commands and generate test messages through a pre-configured IOCTL test application; wherein, the IOCTL test application is an application implemented based on the IOCTL interface; The execution module is used to send an IOCTL command to the network card driver based on the test message to trigger the network card driver to perform packet sending test or packet receiving test; The data receiving module is used to receive the test results returned by the network card driver based on the IOCTL command; The output module is used to test the packet sending and receiving functions of the network card driver based on the test results.

Images