Method and system for testing performance of virtual network device based on inter-process shared memory

Abstract

This application provides a method and system for performance testing of virtual network devices based on inter-process shared memory, relating to the field of virtual network device testing technology. One embodiment of the method runs on a single physical server. The test execution process allocates a shared memory region containing a service and independent monitoring ring buffer, generates a socket file, and listens for connections. The test management process establishes a shared memory communication channel, writes test packets in non-blocking mode, increments the channel overflow counter when writing fails, and periodically sends heartbeat packets through the monitoring ring to detect process activity. In case of anomalies, a tiered reset command is sent through an independent control channel. Finally, performance test results are generated based on send / receive statistics. This application solves the problems of test pressure distortion, difficulty in distinguishing packet loss, and the need for manual recovery of deadlocks in existing architectures through a three-layer observability mechanism, achieving fully automated, highly reliable continuous testing. The physical meaning of the test data is clear, and hardware costs are reduced.

Description

Technical Field

[0001] This invention belongs to the field of virtual network device performance testing technology, and particularly relates to a method and system for testing the performance of virtual network devices based on inter-process shared memory. Background Technology

[0002] Currently, when performing single-machine dual-process shared memory performance tests on virtual network devices, the sending process and the process under test exchange test data packets through the same circular buffer, without the independent hardware buffer isolation provided by the physical network card. When the process under test stops reading data from the circular buffer due to insufficient processing power or software defects, the circular buffer will be filled in a very short time, causing the sending process to be unable to continue writing new packets. If the sending process adopts a blocking and waiting strategy, its packet sending rate will be constrained by the device under test, and the maximum throughput cannot be determined; if a dropping strategy is adopted, all packets dropped due to the buffer being full will be statistically mixed with packets lost after being forwarded by the process under test, and the test results can only present a general packet loss rate, unable to distinguish whether the packet loss occurred on the test channel side or inside the device under test. More seriously, when the process under test is logically deadlocked, the test traffic completely stops after the circular buffer is full, but the test system cannot obtain any clear fault signal, and can only observe the vague phenomenon of zero throughput. Fault diagnosis and recovery both rely on manual intervention. These gray-area faults make it difficult for single-machine dual-process shared memory test architectures to achieve highly reliable and fully automated continuous performance evaluation, hindering the large-scale application of this architecture in real production environments. Summary of the Invention

[0003] This application provides a method and system for testing the performance of virtual network devices based on inter-process shared memory. By constructing a three-layer observability mechanism for a single-machine dual-process shared memory testing architecture, including path separation, packet loss tracing, and hierarchical self-healing, namely, establishing an independent service and monitoring ring buffer, non-blocking drop combined with channel overflow counting, and hierarchical out-of-band reset, the system can accurately distinguish the root cause of packet loss, sense process activity, and automatically recover from deadlock.

[0004] The first aspect of this application discloses a performance testing method for virtual network devices based on inter-process shared memory, running on a single physical server. The single physical server runs a test management process and a test execution process. The method includes: The test execution process allocates a shared memory region, establishes a service ring buffer and a monitoring ring buffer independent of the service ring buffer within the shared memory region, generates a socket file, and listens for connection requests from the test management process. The test management process connects to the test execution process through the socket file, maps the shared memory region to its own address space, and establishes a shared memory communication channel. The service ring buffer is used to transmit test data packets, and the monitoring ring buffer is used to transmit activity detection heartbeat packets. The test management process writes test data packets to the service ring buffer in non-blocking mode and increments the channel overflow counter when writing fails; the test execution process reads the test data packets from the service ring buffer, processes them, and writes the processed data packets back to the service ring buffer; simultaneously, the test management process periodically sends heartbeat request packets to the test execution process through the monitoring ring buffer and detects the heartbeat response packets returned by the test execution process to determine the activity of the test execution process; When the channel overflow counter indicates an overflow or the heartbeat response packet fails to arrive within a preset time period, the test management process sends a reset command to the test execution process through a control channel independent of the shared memory communication channel, and generates the performance test results of the virtual network device based on the collected packet sending and receiving statistics.

[0005] Optionally, the test execution process allocates a shared memory region, and establishes a service ring buffer and a monitoring ring buffer independent of the service ring buffer within the shared memory region, including: The test execution process creates the socket file in the file system and registers a unique identifier; Create a shared memory interface instance with the master role, and allocate the service ring buffer and the monitoring ring buffer in the shared memory area; The file descriptors of the business ring buffer and the monitoring ring buffer are passed to the test management process through the socket file.

[0006] Optionally, allocating the service ring buffer and the monitoring ring buffer in the shared memory region includes: Divide the shared memory region into a first region and a second region; In the first region, a first service ring is allocated for the test management process to write and the test execution process to read, and a second service ring is allocated for the test execution process to write and the test management process to read. The second region is allocated a request ring for the test management process to write heartbeat request packets and the test execution process to read request rings, and a response ring for the test execution process to write heartbeat response packets and the test management process to read response rings.

[0007] Optionally, the test management process writes test data packets to the service ring buffer in non-blocking mode, and increments the channel overflow counter when the write fails, including: Before writing each test data packet, the test management process checks the current writable space of the service ring buffer. If space is insufficient, the current test data packet is discarded directly without waiting, and the channel overflow counter is incremented simultaneously. If there is sufficient space, the test data packet is written and the producer head pointer is updated.

[0008] Optionally, the channel overflow counter is stored in the control header structure of the service ring buffer, and is located in the same shared memory page as the producer head pointer and consumer tail pointer.

[0009] Optionally, the test management process periodically sends heartbeat request packets to the test execution process through the monitoring ring buffer, and detects the heartbeat response packets returned by the test execution process to determine the activity of the test execution process, including: The monitoring thread of the test management process writes a heartbeat request packet containing the current sequence number and the generation timestamp to the request ring every first time interval; The test execution process polls the request ring, and after reading the heartbeat request packet, it constructs a heartbeat response packet carrying the same sequence number and receiving timestamp and writes it into the response ring. The test management process polls the response ring. If no response packet corresponding to the sent sequence number is received within a second time interval, the test execution process is deemed to have lost its activity.

[0010] Optionally, when the channel overflow counter indicates an overflow or the heartbeat response packet fails to arrive within a preset time period, the test management process sends a reset command to the test execution process through a control channel independent of the shared memory communication channel, including: When the heartbeat response packet does not arrive within a preset time period, the test management process sends a data plane soft reset command to the test execution process through the control channel; Upon receiving the data plane soft reset command, the test execution process sets the consumer tail pointer of the service ring buffer to the current value of the producer head pointer.

[0011] Optional, also includes: After the data plane soft reset command is executed, if the test management process detects that the heartbeat response packet has not arrived again in a subsequent cycle, it sends a process termination signal to the test execution process through the control channel. After the test execution process exits, the test management process cleans up the socket file and the shared memory area, and restarts the test execution process to enter the next round of testing.

[0012] Optionally, after generating the performance test results of the virtual network device, the method further includes: The test management process records the number of channel overflow packet loss, the number of forwarding packet loss by the device under test, and the heartbeat activity events in this round of testing; The test execution process clears the internal counter and releases the mapping of the shared memory region; Determine if there is a next test parameter. If so, re-execute the shared memory channel establishment and test process; otherwise, end the test.

[0013] The second aspect of this application discloses a virtual network device performance testing system based on inter-process shared memory, comprising a single physical server, wherein the single physical server is deployed with: The test execution process module is used to allocate a shared memory area containing a business ring buffer and a monitoring ring buffer independent of the business ring buffer, create socket files, and listen for connections; The test management process module is used to establish a shared memory mapping with the test execution process module through the socket file to form a shared memory communication channel; The test management process module is also used to write test data packets to the service ring buffer in non-blocking mode, and increment the channel overflow counter when writing fails; and to periodically send heartbeat request packets and detect heartbeat response packets through the monitoring ring buffer to determine the activity of the test execution process module; The test management process module is also used to send a reset command to the test execution process module through a control channel independent of the shared memory communication channel when the channel overflow counter indicates an overflow or the heartbeat response packet times out and fails to arrive, and to generate performance test results based on the collected send and receive statistics.

[0014] This application proposes a performance testing method for virtual network devices based on inter-process shared memory. During operation, the test execution process allocates both a service ring buffer and a monitoring ring buffer to the shared memory region. After mapping via file descriptors, the test management process allows the two ring buffers to run independently within the same shared memory channel. The service ring buffer carries test traffic, while the monitoring ring buffer carries heartbeat packets. They do not compete for each other's slots and descriptor resources, ensuring that the transmission of monitoring signals is not affected by service congestion under high load. When the test management process writes packets to the service ring buffer in non-blocking mode, if insufficient writable space is detected, packets are discarded and the channel overflow counter is incremented. The write operation itself does not block the packet sending engine, thus maintaining the test pressure at a set value, unaffected by fluctuations in the consumption speed of the tested process. Simultaneously, the tested process continues to maintain its internal packet loss count after reverse write-back processing. At the end of the test, the channel overflow counter reflects packet loss solely due to insufficient receiving end consumption capacity, belonging to a different statistical dimension than packets discarded by the tested process itself. The sum of these two counts represents the total packet volume, allowing for precise attribution of packet loss causes. Heartbeat request packets in the monitoring circular buffer are sent at fixed intervals by an independent thread of the test management process. As long as the main scheduling loop is still running, the process under test (DUT) can immediately construct a response packet and write it back. When the DUT experiences a logical deadlock, the main loop stops, and the heartbeat response is interrupted. The test management process receives a clear liveness loss signal the instant the heartbeat times out, no longer relying on guesswork based on throughput data. The liveness loss event triggers a data plane soft reset command, which is sent to the RPC service thread of the test execution process via the control channel. This service thread is independent of the potentially deadlocked thread and has the ability to forcibly advance the consumer tail pointer of the business circular buffer, instantly releasing all backlogged slots, allowing the business circular buffer to immediately return to a writable state. If the deadlock cannot be resolved by a soft reset, the test management process further terminates the DUT and rebuilds the shared memory region and the DUT instance, automatically entering the next round of testing. Thus, non-blocking write and channel overflow counter sever the coupling between test traffic pressure and congestion at the phenomenological level, heartbeat loop opens up the visibility of faults at the activity level, and graded reset transforms manual intervention into automatic closed-loop operation at the recovery level. The progressive effect of the three enables single-machine dual-process shared memory performance testing to run continuously at a fully automated and highly reliable level. The obtained throughput and packet loss rate data have definite physical meaning and no longer leave gray fault areas. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of a virtual network device performance testing method based on inter-process shared memory in an embodiment of this application; Figure 2 This is a flowchart of S100 of the virtual network device performance testing method based on inter-process shared memory in the embodiments of this application; Figure 3 This is a flowchart of S120 of the virtual network device performance testing method based on inter-process shared memory in the embodiments of this application; Figure 4 This is a flowchart of S200 of the virtual network device performance testing method based on inter-process shared memory in the embodiments of this application; Figure 5 This is a flowchart of S300 of the virtual network device performance testing method based on inter-process shared memory in the embodiments of this application; Figure 6 This is a further flowchart of S300 of the virtual network device performance testing method based on inter-process shared memory in the embodiments of this application; Figure 7 This is a flowchart of steps S400-S600 of the virtual network device performance testing method based on inter-process shared memory in the embodiments of this application; Figure 8 This is a structural block diagram of the virtual network device performance testing system with inter-process shared memory in the embodiments of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] Currently, there is a long-standing and widespread perception in this field that network device performance testing must rely on physical network interface cards (NICs) and external cables to form a data plane channel. This perception stems from the traditional testing methods for hardware network devices. The electrical isolation characteristics of the physical layer allow for independent transmission and reception of test traffic. Insufficient processing power at the receiving end will not negatively affect the packet transmission rate at the sending end, and statistical data from both sides can be collected independently and accurately compared. Based on this perception, when faced with the performance testing needs of virtual network devices, those skilled in the art have consistently limited their improvement strategies to optimizing the performance of physical hardware, such as selecting higher-bandwidth physical NICs, reducing PCIe bus transmission latency, and developing more streamlined NIC drivers. They have never considered fundamentally eliminating the physical NIC as a communication medium itself. This technological bias has resulted in the single-machine dual-process shared memory testing architecture being largely overlooked by those skilled in the art for a considerable period.

[0019] It's important to note that migrating the test architecture from a dual-physical-machine (DTM) to a single-machine dual-process architecture presents a technical challenge that doesn't exist in the DTM architecture. In a DTM architecture, the physical network interface card (NIC) has an independent on-chip hardware buffer. When the device under test (DUT) lacks sufficient processing power, data packets are temporarily stored in the NIC's hardware buffer. Packet loss only occurs when this buffer is full. At this point, the sending rate remains unaffected and can continue sending data packets at the set rate, allowing the test system to accurately measure the DUT's forwarding performance under extreme load. However, in a single-machine dual-process shared memory architecture, the sending process and the DUT share the same circular buffer, lacking independent hardware buffers for isolation. When the DUT stops reading data from the circular buffer due to insufficient processing power or software defects, the buffer fills up very quickly, preventing the sending process from writing new data packets. The sending process then faces two choices: either adopt a blocking wait strategy until there is free space in the circular buffer, or adopt a non-blocking discard strategy to directly discard unwriteable data packets. If a blocking wait strategy is adopted, the packet sending rate of the sending process will be constrained by the consumption rate of the process under test, making it impossible to maintain the set maximum packet sending rate. This leads to distorted test pressure and makes it impossible to accurately measure the maximum throughput of the device under test. If a non-blocking drop strategy is adopted, all packets dropped due to a full ring buffer will statistically be mixed with packets lost after being forwarded by the process under test. The test system can only obtain a general total packet loss rate and cannot distinguish whether packet loss occurred on the test channel side or inside the device under test. More seriously, when the process under test experiences a logical deadlock, its main scheduling loop stops running and no longer reads data from the ring buffer. After the ring buffer is quickly filled, test traffic completely stops. At this time, the test system can only observe the phenomenon of zero throughput and cannot determine whether the forwarding performance of the device under test is zero or the process under test has deadlocked. This ambiguity of the fault state makes fault diagnosis and recovery dependent on manual intervention, making fully automated continuous performance testing impossible.

[0020] Based on the above issues, such as Figure 1 As shown, this application provides a performance testing method for virtual network devices based on inter-process shared memory, running on a single physical server. The single physical server runs a test management process and a test execution process. The method includes: S100: The test execution process allocates a shared memory region, establishes a service ring buffer and a monitoring ring buffer independent of the service ring buffer within the shared memory region, generates a socket file, and listens for connection requests from the test management process; the test management process connects to the test execution process through the socket file, maps the shared memory region to its own address space, and establishes a shared memory communication channel; wherein, the service ring buffer is used to transmit test data packets, and the monitoring ring buffer is used to transmit heartbeat packets for activity detection; S200: The test management process writes test data packets to the service ring buffer in non-blocking mode, and increments the channel overflow counter when writing fails; the test execution process reads the test data packets from the service ring buffer and processes them, then writes the processed data packets back to the service ring buffer; simultaneously, the test management process periodically sends heartbeat request packets to the test execution process through the monitoring ring buffer, and detects the heartbeat response packets returned by the test execution process to determine the activity of the test execution process; S300: When the channel overflow counter indicates an overflow or the heartbeat response packet does not arrive within a preset time period, the test management process sends a reset command to the test execution process through a control channel independent of the shared memory communication channel, and generates the performance test results of the virtual network device based on the collected packet sending statistics and packet receiving statistics.

[0021] This embodiment employs a three-layer observability mechanism for a single-machine, dual-process shared memory testing architecture. When establishing a data plane channel, the test execution process simultaneously establishes a service ring buffer and an independent monitoring ring buffer within the shared memory region. The former handles the forwarding of test data packets, while the latter specifically transmits heartbeat packets with sequence numbers and timestamps. These two physically independent channels, sharing memory but logically and statistically independent, constitute the first layer of path separation. Before each write to the service ring buffer, the test management process pre-judges the writable space. If space is insufficient, it performs non-blocking discarding and atomically increments the channel overflow counter stored in the buffer control header. This ensures that backpressure packet loss within the channel is accurately separated from packet loss forwarded by the device under test, constituting the second layer of packet loss tracing. The monitoring ring buffer carries periodically sent and forced loopback heartbeat packets. When the heartbeat response times out, the test management process issues a data plane soft reset command to the test execution process through a control channel independent of the data plane, forcibly pushing the consumer tail pointer to the producer head pointer to clear the buffer. If consecutive resets are ineffective, further process-level termination and reconstruction are performed, constituting the third layer of hierarchical self-healing mechanism. The three-layer mechanism combination in this embodiment enables the stand-alone shared memory testing system to accurately distinguish the root cause of packet loss, sense process activity, and automatically recover from deadlock.

[0022] Specifically, this embodiment systematically solves the aforementioned technical problems through an organic combination of three observability mechanisms. A business ring buffer and an independent monitoring ring buffer are simultaneously established in the shared memory region. The business ring buffer is used to transmit test data packets, while the monitoring ring buffer is dedicated to transmitting heartbeat detection data packets. The two ring buffers are physically located in the same shared memory region, but logically and statistically completely independent of each other, without occupying each other's slots and descriptor resources. This design ensures that even if the business ring buffer is completely full, the monitoring ring buffer can still transmit heartbeat data packets normally, enabling the test management process to perceive the running status of the test execution process in real time. Secondly, the test management process writes test data packets to the business ring buffer in a non-blocking mode, checking the current writable space of the ring buffer before each write. If the writable space is insufficient, the current data packet is discarded directly, and the channel overflow counter stored in the control header of the business ring buffer is atomically incremented. The channel overflow counter, producer head pointer, and consumer tail pointer reside in the same shared memory page, ensuring the atomicity and visibility of the counter update operation. In this way, packet loss due to test channel fullness is accurately separated from packet loss during internal forwarding by the device under test. The test system can separately calculate the packet loss rate for the two different causes, giving the test results a clear physical meaning. Finally, the test management process communicates with the test execution process through an independent control channel. When the channel overflow counter reaches a preset threshold or the heartbeat response times out, a tiered reset command is sent to the test execution process through the control channel. First, a data plane soft reset command is sent. The RPC service thread of the test execution process is independent of the main scheduling loop and can receive and execute the soft reset command, setting the consumer tail pointer of the business ring buffer to the current value of the producer head pointer, instantly clearing all backlogged data in the ring buffer, and restoring the business ring buffer to a writable state. If multiple soft resets are ineffective, a process termination signal is further sent to stop the test execution process, clean up residual shared memory resources, and then restart the test execution process and establish a new shared memory channel, automatically entering the next round of testing.

[0023] This embodiment addresses the unique technical challenges of a single-machine, dual-process shared memory testing architecture by implementing a three-layer observability mechanism. An independent monitoring ring buffer resolves the issue of liveness detection signals failing to transmit under high load; non-blocking writes combined with a channel overflow counter resolve the inability to distinguish the causes of packet loss; and a tiered out-of-band reset mechanism resolves the inability to automatically recover from deadlock. These three mechanisms form a complete causal chain during runtime: the monitoring ring buffer provides accurate detection of liveness events, non-blocking writes and channel counting provide accurate attribution of packet loss events, and the tiered reset mechanism unifies these two types of events as trigger conditions for automatic recovery.

[0024] Specifically, the virtual network device performance testing method based on inter-process shared memory provided in this application runs on a single physical server. A single physical server refers to a computer device with an independent processor, memory, storage, and operating system, whose hardware resources are shared by all processes running on it. Two independent user-mode processes run on the single physical server: a test management process and a test execution process. The test management process is responsible for orchestrating the test flow, configuring test parameters, generating and sending test data packets, collecting and analyzing test statistics, and generating test results. The test execution process is responsible for running the virtual network device instance under test, receiving and processing test data packets, forwarding the processed data packets back to the test management process, and responding to control commands sent by the test management process. The two processes are independent of each other through the operating system's process isolation mechanism and do not interfere with each other, but they can exchange data through the inter-process communication mechanism provided by the operating system.

[0025] For example, the test execution process first allocates a contiguous shared memory region in the operating system's shared memory space. A shared memory region refers to a physical memory region managed by the operating system that can be mapped to the respective virtual address spaces of multiple processes simultaneously. Read and write operations on the same shared memory region by multiple processes directly affect physical memory, without requiring data copying through the kernel, thus achieving extremely high data transfer rates. Within the allocated shared memory region, the test execution process establishes two independent circular buffers: a service circular buffer and a monitoring circular buffer. The service circular buffer is used to transmit actual test data packets; its size is configured according to test requirements, typically set to accommodate thousands of Ethernet packets of maximum length. The monitoring circular buffer is used to transmit liveness detection heartbeat packets; its size is relatively small, usually only needing to accommodate a few dozen heartbeat packets. The two circular buffers occupy different address ranges within the shared memory region and do not overlap, ensuring the independence of data transmission.

[0026] It's important to note that after establishing the circular buffer, the test execution process generates a socket file in a specified path on the file system. A socket file is a special type of file used as a rendezvous point for establishing connections between processes. The socket file itself does not transmit any business data; it is only used for exchanging connection information and access permissions to shared memory regions between processes. After generating the socket file, the test execution process listens for connection requests from the test management process on that socket file using the Unix domain socket mechanism. Unix domain sockets are a type of socket used for inter-process communication on the same host, and their communication efficiency is higher than that of network protocol-based sockets because they do not require processing by the network protocol stack.

[0027] Specifically, after starting, the test management process locates the socket file generated by the test execution process based on preset configuration information and initiates a connection request to the test execution process via Unix domain sockets. Once the connection is established, the test execution process passes the file descriptor of the shared memory region to the test management process using a file descriptor passing mechanism. File descriptor passing is a special feature provided by Unix domain sockets, allowing one process to pass its opened file descriptor to another process, granting the other process access to the resource pointed to by that file descriptor. After receiving the file descriptor of the shared memory region, the test management process maps the shared memory region into its own virtual address space using the mmap system call. After mapping, both the test management process and the test execution process have direct read and write permissions to the same physical memory region, and the shared memory communication channel is formally established.

[0028] For example, after the shared memory communication channel is established, the test management process begins writing test data packets to the business circular buffer in non-blocking mode. Non-blocking mode means that when the writable space in the circular buffer is insufficient, the write operation will not block and wait, but will immediately return an error code for the application to handle. Before writing each test data packet, the test management process first reads the producer head pointer and consumer tail pointer of the business circular buffer to calculate the current writable space size. The writable space size equals the total size of the circular buffer minus the currently used space size, which is equal to the difference between the producer head pointer and the consumer tail pointer. If the calculated writable space size is greater than or equal to the size of the test data packet to be written, the test management process writes the test data packet to a free slot in the business circular buffer and updates the producer head pointer. If the writable space size is less than the size of the test data packet to be written, the test management process does not perform a write operation, directly discards the current test data packet, and increments the channel overflow counter by 1.

[0029] It's important to note that the channel overflow counter is a 32-bit unsigned integer stored in the business circular buffer control header structure. The control header structure, located at the beginning of the shared memory region, contains all the control information for the circular buffer, such as the total size of the circular buffer, the size of each slot, the producer head pointer, the consumer tail pointer, and the channel overflow counter. The channel overflow counter resides in the same shared memory page as the producer head pointer and consumer tail pointer, ensuring the atomicity of counter updates. When the test management process increments the channel overflow counter, atomic operation instructions are used to ensure that the counter value does not become erroneous in a multi-threaded environment. The channel overflow counter value is initialized to 0 at the beginning of each test round and continues to accumulate during the test until its end. After the test, the channel overflow counter value represents the total number of data packets dropped due to the business circular buffer becoming full during the test.

[0030] Specifically, after the shared memory communication channel is established, the test execution process starts an independent thread to continuously poll the consumer tail pointer and producer head pointer of the service circular buffer. When the producer head pointer is found to be greater than the consumer tail pointer, it indicates that there are new data packets available for reading in the service circular buffer. The test execution process reads the corresponding test data packet from the service circular buffer based on the value of the consumer tail pointer, then increments the value of the consumer tail pointer by the size of the data packet, and releases the slot occupied by the data packet. After reading the test data packet, the test execution process passes it to the virtual network device under test for processing. The virtual network device under test performs routing lookup, address translation, access control, and other processing on the data packet according to its configured forwarding rules, and then writes the processed data packet back to the service circular buffer. The write-back operation process is similar to the data packet writing process of the test management process, with the test execution process acting as the producer and the test management process acting as the consumer.

[0031] Furthermore, during testing, the test management process periodically sends heartbeat request packets to the test execution process via a monitoring ring buffer and detects the heartbeat response packets returned by the test execution process to determine its running status. The heartbeat detection mechanism is a common method for detecting whether a remote process is running normally; it determines the activity of the remote process by periodically sending probe packets and waiting for a response. In this embodiment, the heartbeat detection packets are transmitted through an independent monitoring ring buffer, completely isolated from the transmission channel of business data packets, ensuring that heartbeat packets can still be transmitted normally even if the business ring buffer is completely full.

[0032] For example, the test management process starts a separate monitoring thread that writes a heartbeat request packet to the request ring of the monitoring circular buffer at fixed time intervals. The heartbeat request packet is a fixed-size structure containing two fields: a sequence number and a generation timestamp. The sequence number is a 32-bit unsigned integer used to uniquely identify each heartbeat request packet, and it automatically increments each time a heartbeat request packet is sent. The generation timestamp is a 64-bit integer representing the system time at the time the heartbeat request packet was sent, in microseconds. The test execution process starts a corresponding monitoring thread that continuously polls the request ring of the monitoring circular buffer. When a heartbeat request packet is read, a heartbeat response packet is immediately constructed and written to the response ring of the monitoring circular buffer. The heartbeat response packet is also a fixed-size structure containing three fields: a request sequence number, a receive timestamp, and a send timestamp. The request sequence number is the same as the sequence number in the heartbeat request packet and is used to associate the response packet with the corresponding request packet. The receive timestamp represents the system time when the test execution process receives the heartbeat request packet, and the send timestamp represents the system time when the test execution process sends the heartbeat response packet.

[0033] It should be noted that after sending a heartbeat request packet, the monitoring thread of the test management process continuously polls the response ring of the monitoring circular buffer, waiting for the corresponding heartbeat response packet. If a heartbeat response packet corresponding to the sent sequence number is received within the preset timeout period, it indicates that the test execution process is running normally. If the corresponding heartbeat response packet is not received after the preset timeout period, it is determined that the test execution process has lost its liveness. The timeout setting needs to be adjusted according to the actual test environment, and is usually set between several hundred milliseconds and several seconds. If the timeout is set too short, it may lead to false positives; if the timeout is set too long, it will prolong the fault detection time.

[0034] Specifically, when the test management process detects that the channel overflow counter value exceeds a preset threshold, or that a heartbeat response packet has not arrived within a preset time period, it sends a reset command to the test execution process through a control channel independent of the shared memory communication channel. The control channel is an RPC communication channel based on the TCP protocol or Unix domain sockets, using a structured message format such as JSON serialization. The control channel is completely independent of the shared memory data plane channel and does not occupy each other's communication resources. Even if the shared memory data plane channel is completely congested, the control channel can still transmit control commands normally. The test execution process starts an independent RPC service thread specifically for receiving and processing control commands from the test management process. The RPC service thread is independent of the main scheduling loop of the virtual network device under test; even if the main scheduling loop deadlocks, the RPC service thread can still run normally and respond to control commands.

[0035] For example, when the test management process detects that a heartbeat response packet has timed out, it first sends a data plane soft reset command to the test execution process via the control channel. The data plane soft reset command is a lightweight reset command that only resets the state of the service ring buffer, without affecting other parts of the test execution process. Upon receiving the data plane soft reset command, the RPC service thread of the test execution process sets the consumer tail pointer of the service ring buffer to the current value of the producer head pointer. This causes all unread packets in the service ring buffer to be discarded, and all slots in the ring buffer to be released, restoring it to a fully writable state. The execution time of the data plane soft reset operation is very short, typically only a few microseconds, enabling rapid restoration of the normal operation of the service ring buffer.

[0036] It should be noted that if, after the data plane soft reset command is executed, the test management process detects a timeout failure in the heartbeat response packet during a subsequent heartbeat detection cycle, it indicates a serious failure in the test execution process that cannot be recovered through a soft reset. In this case, the test management process will send a process termination signal to the test execution process via the control channel. The process termination signal is a signal that forcibly terminates the process; the test execution process will exit immediately upon receiving this signal. After the test execution process exits, the operating system will automatically reclaim all its resources, including shared memory mappings, file descriptors, and network connections. Simultaneously, the test management process will clean up any residual socket files and shared memory segment files from the test execution process to ensure that the next round of testing can use entirely new resources. After cleanup, the test management process will restart the test execution process and re-establish the shared memory communication channel according to the previous procedure, automatically entering the next round of testing.

[0037] In addition, when the test execution process completes the processing of all test data packets, or when the test management process actively terminates the test, the test management process collects packet sending statistics and packet receiving statistics from both the test management process and the test execution process. Packet sending statistics include the total number of data packets sent by the test management process, the total number of bytes sent, and the number of packet losses due to channel overflow. Packet receiving statistics include the total number of data packets received by the test execution process, the total number of data packets forwarded, and the total number of data packets dropped internally. Based on the collected statistical data, the test management process calculates performance metrics such as throughput, packet loss rate, and forwarding latency of the virtual network device under test, and generates performance test results. Throughput refers to the number of data packets or bytes that the virtual network device under test can forward per unit of time, usually measured in packets per second or bits per second. Packet loss rate refers to the percentage of data packets lost during forwarding by the virtual network device under test out of the total number of received data packets. Forwarding latency refers to the time elapsed from when a data packet enters the virtual network device under test to when it leaves the virtual network device under test.

[0038] This application is not limited to this. After generating performance test results, the test management process also records all abnormal events that occurred during this round of testing, including channel overflow events, heartbeat timeout events, soft reset events, process restart events, etc. This abnormal event information will be included in the final test report, providing testers with a reference for analyzing the performance and stability of the virtual network device under test. Simultaneously, the test execution process will clear all its internal counters, including interface statistics counters, error statistics counters, runtime statistics counters, etc., to prepare for the next round of testing. The test management process will determine if there are any next parameter configurations to be tested, such as different packet lengths, different traffic rates, different forwarding rules, etc. If there are next test parameters, the test management process will re-execute the shared memory channel establishment and testing process until all test parameters have been traversed. If all test parameters have been tested, the test process ends.

[0039] In an optional embodiment, such as Figure 2 As shown, the test execution process allocates a shared memory region, and establishes a business ring buffer and a monitoring ring buffer independent of the business ring buffer within the shared memory region, including: S110: The test execution process creates the socket file in the file system and registers a unique identifier; S120: Create a shared memory interface instance as the master end role, and allocate the service ring buffer and the monitoring ring buffer in the shared memory area; S130: The file descriptors of the service ring buffer and the monitoring ring buffer are passed to the test management process through the socket file.

[0040] In this embodiment, the process of the test execution process allocating shared memory regions and establishing service circular buffers and monitoring circular buffers begins by creating socket files in a specified path in the file system. The socket file path can be specified by the user through a configuration file or a default path can be used. After creating the socket file, the test execution process registers a unique identifier for it. This identifier is a 32-bit unsigned integer used to distinguish different socket files within the test execution process. The test execution process can create multiple socket files simultaneously, each corresponding to an independent shared memory interface.

[0041] For example, the test execution process creates a shared memory interface instance as the master. The master role refers to the party responsible for creating the socket file, allocating the shared memory region, and initializing the ring buffer in shared memory communication. The shared memory interface instance contains all the configuration information for that interface, such as the interface identifier, associated socket identifier, hardware address, and ring buffer size. The interface identifier is a 32-bit unsigned integer used to distinguish different shared memory interfaces within the test execution process. The hardware address is a 48-bit MAC address used to identify the network address of the shared memory interface. After creating the shared memory interface instance, the test execution process allocates a contiguous shared memory region in the operating system's shared memory space and initializes the service ring buffer and monitoring ring buffer within this shared memory region.

[0042] It should be noted that after the test execution process completes the allocation of shared memory regions and the initialization of the circular buffer, it passes the file descriptors of the business circular buffer and the monitoring circular buffer to the test management process via socket files. File descriptor passing is implemented using the `sendmsg` system call on Unix domain sockets. The `sendmsg` system call allows a process to pass one or more file descriptors along with data. The test management process receives the data and file descriptors via the `recvmsg` system call. After the file descriptor passing is complete, the test management process can access the corresponding shared memory regions through these file descriptors.

[0043] In an optional embodiment, such as Figure 3 As shown, S120 further includes: S121: Divide the shared memory region into a first region and a second region; S122: Allocate a first service ring for the test management process to write and the test execution process to read in the first region, and a second service ring for the test execution process to write and the test management process to read; S123: Allocate a request ring for the test management process to write heartbeat request packets and the test execution process to read requests in the second region, and a response ring for the test execution process to write heartbeat response packets and the test management process to read responses.

[0044] Specifically, when allocating the shared memory region, the test execution process divides it into two independent sub-regions: Region 1 and Region 2. Region 1 stores the business circular buffer, and Region 2 stores the monitoring circular buffer. The sizes of the two sub-regions can be configured independently according to test requirements. Region 1 is typically set to several megabytes to tens of megabytes to accommodate a sufficient number of test data packets. Region 2 is typically set to several kilobytes to tens of kilobytes to accommodate heartbeat detection data packets.

[0045] For example, in the first area, the test execution process allocates two independent circular buffers: a first service ring and a second service ring. The first service ring is used by the test management process to send test data packets to the test execution process; that is, the test management process is the producer, and the test execution process is the consumer. The second service ring is used by the test execution process to send processed test data packets to the test management process; that is, the test execution process is the producer, and the test management process is the consumer. Each service ring contains an array of descriptors and a data buffer pool. Each descriptor in the descriptor array records information such as the storage offset of the corresponding data packet in the data buffer pool, the data length, and flag bits. The data buffer pool is a contiguous memory space divided into multiple fixed-size slots, each slot capable of holding an Ethernet data packet of maximum length.

[0046] It should be noted that in the second area, the test execution process also allocates two independent circular buffers: a request ring and a response ring. The request ring is used by the test management process to send heartbeat request packets to the test execution process, and the response ring is used by the test execution process to send heartbeat response packets to the test management process. The structure of the request ring and response ring is similar to that of the business ring, also containing a descriptor array and a data buffer pool. However, because the size of the heartbeat packet is fixed and relatively small, the size and number of slots in the data buffer pool are much smaller than those in the business ring.

[0047] In an optional embodiment, the test management process writes test data packets to the service ring buffer in non-blocking mode, and increments the channel overflow counter when the write fails, including: Before writing each test data packet, the test management process checks the current writable space of the service ring buffer. If space is insufficient, the current test data packet is discarded directly without waiting, and the channel overflow counter is incremented simultaneously. If there is sufficient space, the test data packet is written and the producer head pointer is updated.

[0048] In this embodiment, the process of the test management process writing test data packets to the service circular buffer in non-blocking mode begins by reading the producer head pointer and consumer tail pointer of the service circular buffer before writing each test data packet. The producer head pointer is a 32-bit unsigned integer pointing to the next writable descriptor position. The consumer tail pointer is also a 32-bit unsigned integer pointing to the next readable descriptor position. The currently used space size of the circular buffer is equal to the difference between the producer head pointer and the consumer tail pointer. If this difference is greater than or equal to the total size of the circular buffer, it indicates that the circular buffer is full and there is no writable space. If the difference is less than the total size of the circular buffer, it indicates that the circular buffer has writable space, and the writable space size is equal to the total size of the circular buffer minus the difference.

[0049] For example, if the writable space calculated by the test management process is smaller than the size of the test data packet to be written, it means there is not enough space to accommodate the data packet. In this case, the test management process will not perform any write operation, but will directly discard the current test data packet and increment the channel overflow counter by 1. Discarding the data packet will not generate any system calls or block the execution of the test management process, so the test management process can continue to generate and send the next data packet at the set rate. If the writable space is greater than or equal to the size of the test data packet to be written, the test management process will write the contents of the test data packet to a free slot in the data buffer pool, and then record the storage offset, data length, and flag bits of the data packet in the corresponding descriptor. Finally, the test management process will perform a memory write barrier operation to ensure that all write operations to shared memory have been completed, and then update the producer head pointer to make the newly written data packet visible to the test execution process.

[0050] It's important to note that a memory write barrier is a processor instruction used to force the processor to perform memory write operations in program order. In multiprocessor systems, the processor may reorder memory write operations to improve execution efficiency. Without a memory write barrier, the test management process might update the producer head pointer before writing the data packet content, resulting in the test execution process reading incomplete data packet content after the producer head pointer has been updated. A memory write barrier ensures that all write operations to the data packet content and descriptors are completed before the producer head pointer is updated, thus avoiding data inconsistency issues.

[0051] In an optional embodiment, the channel overflow counter is stored in the control header structure of the service ring buffer, located in the same shared memory page as the producer head pointer and consumer tail pointer.

[0052] In this embodiment, the channel overflow counter is stored in the control header structure of the service circular buffer. The control header structure, located at the beginning of the shared memory region, is a fixed-size structure containing all the control information of the circular buffer. The size of the control header structure is typically one memory page, or 4096 bytes, to ensure page alignment in memory. The channel overflow counter resides in the same shared memory page as the producer head pointer and consumer tail pointer, ensuring that access to these three variables occurs within the same memory page, thus improving access efficiency. Furthermore, since these three variables are stored in shared memory, both the test management process and the test execution process can directly access them without requiring any system calls.

[0053] For example, the channel overflow counter is a 32-bit unsigned integer with a value ranging from 0 to 4294967295. At the start of each test round, the channel overflow counter is initialized to 0. During the test, whenever the test management process drops a data packet due to insufficient space in the business circular buffer, it uses an atomic increment instruction to increment the channel overflow counter by 1. The atomic increment instruction ensures that even in a multi-threaded environment, if multiple threads attempt to increment the counter simultaneously, the counter value will not be incorrect. The test execution process does not modify the channel overflow counter value; it only reads the value at the end of the test to calculate the packet loss rate of the test channel.

[0054] In an optional embodiment, such as Figure 4 As shown, the test management process periodically sends heartbeat request packets to the test execution process through the monitoring ring buffer, and detects the heartbeat response packets returned by the test execution process to determine the activity of the test execution process, further including: S210: The monitoring thread of the test management process writes a heartbeat request packet containing the current sequence number and the generation timestamp to the request ring every first time interval; S220: The test execution process polls the request ring, and after reading the heartbeat request packet, constructs a heartbeat response packet carrying the same sequence number and receiving timestamp and writes it into the response ring; S230: The test management process polls the response ring. If no response packet corresponding to the sent sequence number is received within the second time interval, the test execution process is deemed to have lost its activity.

[0055] In this embodiment, the test management process performs heartbeat detection by monitoring the circular buffer. First, the monitoring thread of the test management process writes a heartbeat request packet to the request ring at fixed first time intervals. The length of the first time interval can be specified by the user through a configuration file, typically set between 100 milliseconds and 1 second. The setting of the first time interval needs to balance the real-time nature of fault detection with the consumption of system resources. If the first time interval is set too short, it will increase the system's CPU load; if the first time interval is set too long, it will prolong the fault detection time.

[0056] For example, a heartbeat request packet contains two fields: a sequence number and a generation timestamp. The sequence number is a 32-bit unsigned integer, starting from 0 and automatically incrementing with each heartbeat request packet sent. When the sequence number reaches its maximum value, it automatically wraps back to 0 to restart the count. The generation timestamp is a 64-bit integer representing the system time, in microseconds, when the test management process sent the heartbeat request packet. The system time can be obtained using a high-precision timer provided by the operating system, such as the `clock_gettime` function in Linux. After sending the heartbeat request packet, the test management process records the sequence number and generation timestamp of the request packet in a local pending response list.

[0057] It's important to note that the monitoring thread of the test execution process continuously polls the consumer tail pointer and producer head pointer of the request ring. When the producer head pointer is found to be greater than the consumer tail pointer, it indicates that a new heartbeat request packet is available for reading in the request ring. The test execution process reads this heartbeat request packet, records the receiving timestamp, and then constructs a heartbeat response packet. The heartbeat response packet contains three fields: request sequence number, receiving timestamp, and sending timestamp. The request sequence number is the same as the sequence number in the heartbeat request packet and is used to associate the response packet with the corresponding request packet. The receiving timestamp is the system time when the test execution process received the heartbeat request packet, and the sending timestamp is the system time when the test execution process sent the heartbeat response packet. After writing the heartbeat response packet to the response ring, the test execution process updates the producer head pointer of the response ring.

[0058] Specifically, after sending a heartbeat request packet, the monitoring thread of the test management process continuously polls the consumer tail pointer and producer head pointer of the response ring. When a new heartbeat response packet is found available for reading in the response ring, it reads the packet and searches for the corresponding heartbeat request packet in the local pending response list based on the request sequence number in the response packet. If the corresponding request packet is found, the heartbeat round-trip time is calculated, which is the response packet reception time minus the request packet sending time. Then, the request packet is removed from the pending response list. If, within a preset second time interval, a request packet in the pending response list still has not received a corresponding response packet, it is determined that the test execution process has lost liveness. The length of the second time interval is usually set to 3 to 5 times the length of the first time interval to avoid misjudgments caused by network latency or system load fluctuations.

[0059] In an optional embodiment, such as Figure 5 As shown, when the channel overflow counter indicates an overflow or the heartbeat response packet fails to arrive within a preset time period, the test management process sends a reset command to the test execution process through a control channel independent of the shared memory communication channel, further including: S310: When the heartbeat response packet does not arrive within a preset time period, the test management process sends a data plane soft reset command to the test execution process through the control channel; S320: After receiving the data plane soft reset command, the test execution process sets the consumer tail pointer of the service ring buffer to the current value of the producer head pointer.

[0060] In this embodiment, when the test management process detects that a heartbeat response packet has not arrived within a preset time period, it first sends a data plane soft reset command to the test execution process through the control channel. The data plane soft reset command is a structured JSON message containing the command type, command parameters, and a unique request identifier. The command type field is set to `data_plane_soft_reset`, indicating that this is a data plane soft reset command. The command parameter field may contain optional parameters, such as the identifier of the circular buffer to be reset. The unique request identifier is a UUID used to associate the response message with the corresponding request message.

[0061] For example, after receiving a data plane soft reset command, the RPC service thread of the test execution process first verifies the command's validity and then executes the soft reset operation. The specific steps of the soft reset operation are: read the current value of the producer head pointer in the business ring buffer, and then set the consumer tail pointer to that value. In this way, all unread packets in the business ring buffer are considered consumed, all slots in the ring buffer are released, and it is restored to a fully writable state. The soft reset operation does not modify the value of the producer head pointer, nor does it affect subsequent write operations by the test management process. After the soft reset operation is completed, the test execution process sends a response message to the test management process, notifying that the soft reset operation has been completed.

[0062] It's important to note that the data plane soft reset command is a very lightweight reset operation with a very short execution time, typically only a few microseconds. The soft reset operation does not affect other parts of the test execution process; the configuration information, routing table, access control list, etc., of the virtual network device under test remain unchanged. Therefore, after the soft reset operation is completed, the test can resume immediately without reconfiguring the virtual network device under test.

[0063] In an optional embodiment, such as Figure 6 As shown, after S320, the method further includes: S330: After the data plane soft reset command is executed, if the test management process detects that the heartbeat response packet has not arrived again in a subsequent cycle, it sends a process termination signal to the test execution process through the control channel. S340: After the test execution process exits, the test management process cleans up the socket file and the shared memory area, and restarts the test execution process to enter the next round of testing.

[0064] In this embodiment, if the test management process detects a timeout failure in the heartbeat response packet again during a subsequent heartbeat detection cycle after the data plane soft reset command is executed, it indicates that the test execution process has experienced a serious failure and cannot be recovered through a soft reset. In this case, the test management process will send a process termination signal to the test execution process through the control channel. The process termination signal can be any termination signal provided by the operating system, such as SIGTERM or SIGKILL. The SIGTERM signal is a graceful termination signal, allowing the process to perform some cleanup work before exiting. The SIGKILL signal is a forced termination signal; the process will be immediately terminated by the operating system without any opportunity for cleanup work.

[0065] For example, the test management process first sends a SIGTERM signal to the test execution process, giving it a chance to exit gracefully. Upon receiving the SIGTERM signal, the test execution process stops all ongoing operations, closes all open file descriptors, releases all allocated memory resources, and then exits normally. If the test execution process fails to exit within a preset time after receiving the SIGTERM signal, the test management process sends a SIGKILL signal to forcibly terminate the process.

[0066] It's important to note that after the test execution process exits, the operating system automatically reclaims all its resources, including shared memory mappings, file descriptors, and network connections. However, socket files and shared memory segment files may remain in the file system. Therefore, the test management process performs resource cleanup after the test execution process exits, deleting any remaining socket files and shared memory segment files. After the resource cleanup is complete, the test management process restarts the test execution process and re-establishes the shared memory communication channel according to the previous procedure, automatically proceeding to the next round of testing.

[0067] In an optional embodiment, such as Figure 7 As shown, after generating the performance test results of the virtual network device, the process also includes: S400: The test management process records the number of channel overflow packet loss, the number of forwarding packet loss by the device under test, and the heartbeat activity events in this round of testing; S500: The test execution process clears the internal counter and releases the mapping of the shared memory region; S600: Determine if there is a next test parameter. If yes, re-execute the shared memory channel establishment and test process; otherwise, end the test.

[0068] In this embodiment, after generating the performance test results of the virtual network device, the test management process records all relevant information for this round of testing, including test parameter configuration, channel overflow packet loss count, packet loss count of the device under test, heartbeat activity events, soft reset events, process restart events, etc. This information is stored in a test log file for subsequent analysis and review. The test log file can be in text, CSV, or JSON format, facilitating processing and analysis by testers using various tools.

[0069] For example, after the test execution process concludes its current test, it clears all internal counters. These counters include interface statistics counters, error statistics counters, and runtime statistics counters. The interface statistics counter records the total number of data packets received and sent by the interface, the total number of bytes, and the number of lost packets. The error statistics counter records the number of times various types of errors occurred, such as checksum errors, length errors, and protocol errors. The runtime statistics counter records the operating status information of the virtual network device under test, such as CPU utilization, memory utilization, and cache hit rate. Clearing these counters ensures that the statistical data for the next test round is not affected by the current test.

[0070] It's important to note that after clearing the counter, the test execution process releases its mapping of the shared memory region. This release is achieved through the `munmap` system call. The `munmap` system call unmaps the specified virtual address range from the process's virtual address space, preventing the process from accessing the physical memory corresponding to that address range. After the shared memory region's mapping is released, the shared memory region still exists in the operating system's shared memory space until all processes that mapped the region have released their mappings and no process has opened a file descriptor for that shared memory region. Only then will the operating system reclaim the shared memory region.

[0071] Specifically, the test management process determines if there is a next parameter configuration to be tested. Test parameter configurations can include different packet lengths, different traffic rates, different forwarding rules, different concurrent flow counts, etc. The test management process iterates through all test parameter configurations in a preset order. If a next test parameter exists, the test management process re-executes the shared memory channel establishment and testing process, including starting the test execution process, establishing the shared memory communication channel, configuring test parameters, executing the test, collecting statistical data, and generating test results. If all test parameters have been tested, the test process ends, and the test management process generates a final comprehensive test report.

[0072] A performance testing method for virtual network devices based on inter-process shared memory, as described in the above embodiments, is as follows: Figure 8 As shown, this application also provides a virtual network device performance testing system based on inter-process shared memory, including a single physical server, wherein the single physical server is deployed with: The test execution process module is used to allocate a shared memory area containing a business ring buffer and a monitoring ring buffer independent of the business ring buffer, create socket files, and listen for connections; The test management process module is used to establish a shared memory mapping with the test execution process module through the socket file to form a shared memory communication channel; The test management process module is also used to write test data packets to the service ring buffer in non-blocking mode, and increment the channel overflow counter when writing fails; and to periodically send heartbeat request packets and detect heartbeat response packets through the monitoring ring buffer to determine the activity of the test execution process module; The test management process module is also used to send a reset command to the test execution process module through a control channel independent of the shared memory communication channel when the channel overflow counter indicates an overflow or the heartbeat response packet times out and fails to arrive, and to generate performance test results based on the collected send and receive statistics.

[0073] The virtual network device performance testing system based on inter-process shared memory provided in this embodiment includes a single physical server. Two independent modules are deployed on this single physical server: a test execution process module and a test management process module. Both the test execution process module and the test management process module are independent processes running in user space, and are mutually independent through the operating system's process isolation mechanism.

[0074] For example, the test execution process module allocates a shared memory area containing a service ring buffer and a monitoring ring buffer independent of the service ring buffer, creates socket files, and listens for connection requests from the test management process module. The test execution process module also runs the virtual network device under test instance, receives and processes test packets, forwards the processed packets back to the test management process module, and responds to control commands sent by the test management process module. The test execution process module includes an RPC service submodule specifically designed to receive and process control commands from the test management process module, such as start commands, configuration commands, reset commands, and termination commands.

[0075] It should be noted that the test management process module establishes a shared memory mapping with the test execution process module via a socket file, forming a shared memory communication channel. The test management process module also generates test data packets, writes them to the service circular buffer in non-blocking mode, and increments the channel overflow counter when a write operation fails. Furthermore, the test management process module periodically sends heartbeat request packets by monitoring the circular buffer and detects heartbeat response packets to determine the activity of the test execution process module. Finally, when the channel overflow counter indicates an overflow or a heartbeat response packet times out, the test management process module sends a reset command to the test execution process module via a control channel independent of the shared memory communication channel, and generates performance test results based on the collected transmit and receive statistics.

[0076] In a specific implementation scenario, the hardware configuration of a single physical server is as follows: a processor with 16 physical cores, 64GB of memory, and a 1TB solid-state drive. The operating system is a 64-bit Linux distribution with kernel version 5.4 or higher. The test execution process module and the test management process module are bound to different CPU cores to avoid CPU resource contention between processes. The test execution process module is bound to CPU cores 0 to 7, and the test management process module is bound to CPU cores 8 to 15. The shared memory area size is set to 128MB, with a 120MB service ring buffer and an 8MB monitoring ring buffer. Each slot in the service ring buffer is 1518 bytes, which is the size of the standard Ethernet maximum transmission unit, thus the service ring buffer can hold approximately 80,000 data packets. Each slot in the monitoring ring buffer is 64 bytes, which can hold approximately 130,000 heartbeat packets.

[0077] Specifically, before the test begins, testers specify test parameters through a configuration file, including test duration, packet length list, traffic rate, and forwarding rules. For example, the test duration might be set to 60 seconds, the packet length list to 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes, and 1500 bytes, and the traffic rate to 10%, 20%, 50%, and 100% of line speed. After the test management process module reads the configuration file, it starts the test execution process module. Once started, the test execution process module creates a socket file, allocates a shared memory area, initializes the business ring buffer and the monitoring ring buffer, and then listens for connection requests on the socket file.

[0078] For example, the test management process module connects to the socket file created by the test execution process module to establish a shared memory communication channel. After the channel is established, the test management process module sends configuration commands to the test execution process module through the control channel to configure the forwarding rules of the virtual network device under test. For example, it configures a static routing table to forward packets destined for [192.168.2.0 / 24] to the specified next-hop address. After configuration, the test management process module starts generating test packets and writes them to the service ring buffer in non-blocking mode. The source IP address of the test packets is [192.168.1.1], the destination IP address is [192.168.2.1], the protocol is UDP, the source port is 1024, and the destination port is 80.

[0079] It should be noted that after the test execution process module reads the test data packets from the service ring buffer, it passes them to the virtual network device under test for processing. The virtual network device under test forwards the data packets to the next-hop address according to its configured static routing table. Since there is only one shared memory interface in this embodiment, the virtual network device under test writes the processed data packets back to the same service ring buffer. The test management process module reads the forwarded data packets from the service ring buffer and counts the number of sent and received data packets and the number of bytes.

[0080] Specifically, during testing, the monitoring thread of the test management process module writes a heartbeat request packet to the request ring of the monitoring circular buffer every 100 milliseconds. After reading the heartbeat request packet, the monitoring thread of the test execution process module immediately constructs a heartbeat response packet and writes it to the response ring. The monitoring thread of the test management process module reads the heartbeat response packet and calculates the heartbeat round-trip time. If no heartbeat response packet is received for three consecutive heartbeat cycles, it is determined that the test execution process module has lost liveness. At this time, the test management process module sends a data plane soft reset command to the test execution process module through the control channel. After receiving the soft reset command, the RPC service thread of the test execution process module sets the consumer tail pointer of the business circular buffer to the current value of the producer head pointer and clears the backlog data in the circular buffer. If no heartbeat response packet is received after the soft reset, the test management process module terminates the test execution process module, cleans up residual resources, and then restarts the test execution process module to continue testing.

[0081] For example, after the test time for a certain combination of test parameters ends, the test management process module stops sending test data packets and waits for the test execution process module to process all remaining data packets. Then, the test management process module collects statistical data from both the test management process module and the test execution process module. The statistical data from the test management process module includes the total number of data packets sent, the total number of bytes sent, the number of packet losses due to channel overflow, the total number of data packets received, and the total number of bytes received. The statistical data from the test execution process module includes the total number of data packets received, the total number of bytes received, the total number of data packets forwarded, the total number of bytes forwarded, and the number of internal packet losses. Based on these statistical data, the test management process module calculates performance metrics such as throughput, forwarding packet loss rate, and channel overflow packet loss rate of the virtual network device under test, and generates the test results for that combination of test parameters.

[0082] It should be noted that after generating test results for a given combination of test parameters, the test management process module records all abnormal events in this round of testing, then clears the internal counters of the test execution process module and releases the shared memory mapping. Next, the test management process module determines if a next combination of test parameters exists. If it does, it re-establishes the shared memory communication channel, configures the new test parameters, and continues testing. If all combinations of test parameters have been tested, the test management process module generates a final comprehensive test report. This report includes performance metrics, abnormal event statistics, performance trend graphs, and other information for all test parameter combinations, providing testers with a comprehensive reference for evaluating the performance and stability of the virtual network device under test.

[0083] Those skilled in the art will understand that the technical solution provided in this application, by using a shared memory interface as the data plane channel in a single-machine dual-process architecture, eliminates the dependence on physical network cards and physical cables, thus reducing the hardware cost of the testing system. Through an independent monitoring ring buffer, non-blocking write combined with a channel overflow counter, and a tiered out-of-band reset mechanism, the gray fault problem in the single-machine dual-process shared memory testing architecture is solved, achieving accurate differentiation of packet loss causes, real-time detection of process activity, and automatic recovery of fault states. The technical solution of this application enables the single-machine dual-process shared memory testing architecture to run continuously at a fully automated and highly reliable level, and the obtained test data has a clear physical meaning, accurately reflecting the pure software forwarding performance of the virtual network device under test.

[0084] This application is not limited to this. Although the embodiments of this application are illustrated using the performance testing of a virtual network device as an example, the technical solutions of this application can also be applied to the performance testing of other types of software network devices, such as virtual firewalls, virtual load balancers, and virtual intrusion detection systems. Any network device that runs on a general-purpose server and implements packet processing and forwarding functions through software can use the technical solutions of this application for performance testing. Furthermore, the technical solutions of this application can also be applied to other scenarios requiring high-speed data transmission between processes and demanding reliability assurance, such as inter-process communication in distributed systems and data transmission in real-time data processing systems.

[0085] Further details are omitted here. The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A performance testing method for virtual network devices based on inter-process shared memory, running on a single physical server, wherein a test management process and a test execution process run on the single physical server, characterized in that, The method includes: The test execution process allocates a shared memory region, establishes a service ring buffer and a monitoring ring buffer independent of the service ring buffer within the shared memory region, generates a socket file, and listens for connection requests from the test management process. The test management process connects to the test execution process through the socket file, maps the shared memory region to its own address space, and establishes a shared memory communication channel. The service ring buffer is used to transmit test data packets, and the monitoring ring buffer is used to transmit activity detection heartbeat packets. The test management process writes test data packets to the service ring buffer in non-blocking mode and increments the channel overflow counter when writing fails; the test execution process reads the test data packets from the service ring buffer, processes them, and writes the processed data packets back to the service ring buffer; simultaneously, the test management process periodically sends heartbeat request packets to the test execution process through the monitoring ring buffer and detects the heartbeat response packets returned by the test execution process to determine the activity of the test execution process; When the channel overflow counter indicates an overflow or the heartbeat response packet fails to arrive within a preset time period, the test management process sends a reset command to the test execution process through a control channel independent of the shared memory communication channel, and generates the performance test results of the virtual network device based on the collected packet sending and receiving statistics.

2. The method according to claim 1, characterized in that, The test execution process allocates a shared memory region, and establishes a service ring buffer and a monitoring ring buffer independent of the service ring buffer within the shared memory region, including: The test execution process creates the socket file in the file system and registers a unique identifier; Create a shared memory interface instance with the master role, and allocate the service ring buffer and the monitoring ring buffer in the shared memory area; The file descriptors of the business ring buffer and the monitoring ring buffer are passed to the test management process through the socket file.

3. The method according to claim 2, characterized in that, The allocation of the service ring buffer and the monitoring ring buffer in the shared memory region includes: Divide the shared memory region into a first region and a second region; In the first region, a first service ring is allocated for the test management process to write and the test execution process to read, and a second service ring is allocated for the test execution process to write and the test management process to read. The second region is allocated a request ring for the test management process to write heartbeat request packets and the test execution process to read request rings, and a response ring for the test execution process to write heartbeat response packets and the test management process to read response rings.

4. The method according to claim 1, characterized in that, The test management process writes test data packets to the service ring buffer in non-blocking mode, and increments the channel overflow counter when the write fails, including: Before writing each test data packet, the test management process checks the current writable space of the service ring buffer. If space is insufficient, the current test data packet is discarded directly without waiting, and the channel overflow counter is incremented simultaneously. If there is sufficient space, the test data packet is written and the producer head pointer is updated.

5. The method according to claim 4, characterized in that, The channel overflow counter is stored in the control header structure of the service ring buffer, and is located in the same shared memory page as the producer head pointer and consumer tail pointer.

6. The method according to claim 1, characterized in that, The test management process periodically sends heartbeat request packets to the test execution process through the monitoring ring buffer, and detects the heartbeat response packets returned by the test execution process to determine the activity of the test execution process, including: The monitoring thread of the test management process writes a heartbeat request packet containing the current sequence number and the generation timestamp to the request ring every first time interval; The test execution process polls the request ring, and after reading the heartbeat request packet, it constructs a heartbeat response packet carrying the same sequence number and receiving timestamp and writes it into the response ring. The test management process polls the response ring. If no response packet corresponding to the sent sequence number is received within a second time interval, the test execution process is deemed to have lost its activity.

7. The method according to claim 1, characterized in that, When the channel overflow counter indicates an overflow or the heartbeat response packet fails to arrive within a preset time period, the test management process sends a reset command to the test execution process through a control channel independent of the shared memory communication channel, including: When the heartbeat response packet does not arrive within a preset time period, the test management process sends a data plane soft reset command to the test execution process through the control channel; Upon receiving the data plane soft reset command, the test execution process sets the consumer tail pointer of the service ring buffer to the current value of the producer head pointer.

8. The method according to claim 7, characterized in that, Also includes: After the data plane soft reset command is executed, if the test management process detects that the heartbeat response packet has not arrived again in a subsequent cycle, it sends a process termination signal to the test execution process through the control channel. After the test execution process exits, the test management process cleans up the socket file and the shared memory area, and restarts the test execution process to enter the next round of testing.

9. The method according to claim 1, characterized in that, After generating the performance test results of the virtual network device, the following is also included: The test management process records the number of channel overflow packet loss, the number of forwarding packet loss by the device under test, and the heartbeat activity events in this round of testing; The test execution process clears the internal counter and releases the mapping of the shared memory region; Determine if there is a next test parameter. If so, re-execute the shared memory channel establishment and test process; otherwise, end the test.

10. A performance testing system for virtual network devices based on inter-process shared memory, characterized in that, This includes a single physical server, on which the following are deployed: The test execution process module is used to allocate a shared memory area containing a business ring buffer and a monitoring ring buffer independent of the business ring buffer, create socket files, and listen for connections; The test management process module is used to establish a shared memory mapping with the test execution process module through the socket file to form a shared memory communication channel; The test management process module is also used to write test data packets to the service ring buffer in non-blocking mode, and increment the channel overflow counter when writing fails; and to periodically send heartbeat request packets and detect heartbeat response packets through the monitoring ring buffer to determine the activity of the test execution process module; The test management process module is also used to send a reset command to the test execution process module through a control channel independent of the shared memory communication channel when the channel overflow counter indicates an overflow or the heartbeat response packet times out and fails to arrive, and to generate performance test results based on the collected send and receive statistics.

Images