Consistency verification method and system for kernel mode memory access reconnection test

Abstract

The application provides a consistency verification method and system for kernel state memory access reconnection test. The method comprises the following steps: collecting the local reconnection state containing the recovery stage, the queue pair state and the like in the kernel state RDMA reconnection test; encoding the local reconnection state into a state identifier; after synchronization through the kernel cache, synchronizing the state identifier to the state mirror memory area of the opposite end which is physically continuous and kernel-locked through the RDMA unilateral writing operation; reading the state identifier by the opposite end and comparing the state identifier with the local reconnection state to complete the consistency determination and output the result. The system corresponds to the state collection, encoding, unilateral writing synchronization and consistency determination unit. The application realizes the non-blocking state synchronization and verification, avoids blocking the original reconnection state machine, guarantees the consistency of the states of the two ends and maintains the reconnection timing.

Description

Technical Field

[0001] This invention relates to the field of Remote Direct Memory Access (RDMA) testing technology, and in particular to a consistency verification method for kernel-mode memory access reconnection testing. Background Technology

[0002] Existing kernel-mode remote direct memory access (RDM) reconnection testing methods only focus on external behaviors such as connection establishment and data transmission, as well as the final test results. They do not synchronize and verify the internal states of both ends during the reconnection process. Some methods use message interaction to achieve state transmission, which requires waiting for feedback from the other end and will block the execution sequence of the native reconnection state machine. At the same time, the difference between the mechanism of multi-core CPU cache and the mechanism of remote direct memory access hardware directly accessing physical memory can lead to deviations in the state data read by both ends, thus causing consistency judgment errors. Existing methods cannot achieve accurate synchronization and verification of the state of both ends without interfering with the reconnection process. Summary of the Invention

[0003] This application provides a consistency verification method for kernel-mode memory access reconnection testing. During kernel-mode remote direct memory access reconnection testing, it achieves real-time synchronization and consistency verification of the reconnection status of both ends, and avoids blocking the execution sequence of the native reconnection state machine by state synchronization and judgment operations.

[0004] This application discloses a consistency verification method for kernel-mode memory access reconnection testing, including: During the kernel-mode remote direct memory access reconnection test, the local reconnection status is collected. The local reconnection status includes the recovery phase, queue pair status, resource status, and recovery generation during the remote direct memory access reconnection process. The local reconnection status is encoded as a status identifier and synchronized to the peer's preset status mirror memory area through a one-sided write operation via remote direct memory access. The status mirror memory area is a physically contiguous and kernel-locked memory area, and the peer only has local read permissions for this area. The peer performs a consistency check between the state identifier in the state mirror memory area and the local reconnection state and outputs the check result. The consistency check is a comparison of the matching degree of the reconnection states of both ends.

[0005] Optionally, collect the local reconnection status, including: The jump node of the reconnected state machine based on remote direct memory access triggers the state acquisition operation; Read the state data of the remote direct memory access session and resource management structure in kernel mode; The read status data is integrated to form the local reconnection status.

[0006] Optionally, the local reconnection status is encoded as a status identifier, including: Extract the identity field, generation field, stage field, and resource field from the local reconnection status; The extracted fields are concatenated according to a preset format to form a status identifier with a fixed structure; Add a validation field to the status identifier to complete the encoding process.

[0007] Optionally, one-sided write operations via remote direct memory access can be synchronized to a pre-defined state mirror memory region on the other end, including: After completing the status flag encoding, perform a kernel cache synchronization operation to flush the cached data into physical memory; Initiate a one-sided write operation for remote direct memory access using a dedicated test queue; Write the state flag to the state mirror memory area of ​​the peer and update the state ready flag.

[0008] Optionally, perform kernel cache synchronization operations to flush cached data to physical memory, including: The kernel direct memory access synchronization interface is invoked to synchronize the status flag data in the CPU cache to physical memory. Hardware-level data verification is performed through a memory consistency engine that uses remote direct memory access to the hardware. Once synchronization is complete, the physical memory data is marked as valid and accessible.

[0009] Optionally, the peer performs a consistency determination based on the state identifier within the state mirror memory region and the local reconnection state, including: The peer reads the state ready flag within the state mirror memory area; when the state ready flag is valid, it synchronizes the kernel cache and reads the state flag. The corresponding fields of the status identifier and the local reconnection status are compared to complete the consistency determination.

[0010] Optionally, after the peer performs a consistency check between the state identifier in the state mirror memory region and the local reconnection state and outputs the check result, it also includes: When the determination result is a mismatch, an interrupt signal is triggered through the remote direct memory access hardware asynchronous event queue; The circuit breaker process performs a reconnection test based on the interrupt signal; the state data of both ends at the moment of circuit breaker failure is recorded to the kernel event log.

[0011] Optionally, before synchronizing a one-sided write operation via remote direct memory access to a pre-defined state mirror memory region on the other end, the following steps are also included: Create a dedicated protection domain to isolate test resources from business resources; Allocate physically contiguous and kernel-locked memory within a dedicated protection domain as a state mirror memory region; Configure remote direct memory access one-sided write permissions for the state mirror memory region.

[0012] Optionally, the state acquisition operation triggered by the jump node of the reconnected state machine based on remote direct memory access includes: Monitor the jump instructions of the remote direct memory access reconnection state machine; A status acquisition operation is triggered when the jump instruction is completed; Data acquisition identifiers are assigned based on dynamic counting rules to distinguish the status data of different acquisition nodes.

[0013] This application also discloses a consistency verification system for kernel-mode memory access reconnection testing, including: a status acquisition unit, a status encoding unit, a one-sided write synchronization unit, and a consistency determination unit; The status acquisition unit is used to acquire the local reconnection status during the kernel-mode remote direct memory access reconnection test; The status coding unit is used to encode the local reconnection status into a status identifier; The single-sided write synchronization unit is used to synchronize the status flag to the preset status mirror memory area of ​​the other end through a single-sided write operation via remote direct memory access. The consistency determination unit is used to perform consistency determination based on the status identifier in the state mirror memory area and the local reconnection status, and output the determination result.

[0014] As can be seen from the above technical solution, after the status flag is generated, this application calls the kernel DMA synchronization interface to force the flag data in the CPU cache to be flushed into physical memory, and completes the verification through the RDMA hardware memory consistency engine to eliminate the data view difference between the multi-core cache and physical memory, providing a prerequisite for the one-sided write operation to move the correct data. After that, the RDMA one-sided write is initiated to write the status flag into the pre-allocated physical contiguous and kernel-locked memory area of ​​the other end. To ensure the RDMA network card can directly and stably address the region without going through the peer's CPU, the region is configured for local reading only by the peer to prevent accidental write pollution. After a one-sided write is completed, the atomic state ready flag is updated. The peer only reads when the flag is valid, ensuring that incomplete state data is not consumed and eliminating read / write contention windows. Before judgment, the peer also synchronizes its own kernel cache to ensure that the mirrored region data read by its CPU is consistent with physical memory. Dedicated test queues are isolated from service queues, ensuring that even if the service link fails, the state synchronization path remains available, preventing loss of verification capabilities due to reconnection failures. These measures together form a complete non-blocking synchronization and verification link: state data is collected from the local end, forced write-through into physical memory, reliably moved to the peer's locked memory area through one-sided writes, protected by the ready flag for reading, and finally compared with the peer's local state. This series of operations does not require the reconnection state machine to pause and wait for the peer's response, nor does it introduce judgment errors due to cache consistency issues, overcoming timing interference and data deviation in kernel-mode RDMA reconnection testing. 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 illustrating a consistency verification method for kernel-mode memory access reconnection testing in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of a consistency verification system for kernel-mode memory access reconnection testing in an embodiment 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 to be construed as 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] In this embodiment, existing kernel-mode remote direct memory access reconnection tests typically rely on message interaction to complete state transfer. During the remote direct memory access reconnection process, the test device transmits its local state by sending dedicated control messages. After receiving the messages, the peer parses the state data and performs a consistency determination. During this process, the test device needs to wait for the peer's message reception feedback, and the reconnection state machine needs to pause execution until state synchronization is completed. At the same time, in a multi-core CPU environment, the CPU cache temporarily stores state data. When the remote direct memory access hardware directly reads physical memory, it will obtain outdated data. Discrepancies between the two ends' state data will directly lead to distortion of the consistency determination result. Such existing technologies will change the execution sequence of the reconnection process in actual testing and cannot guarantee the accuracy of the state data, making it difficult to meet the stability verification requirements of kernel-mode remote direct memory access reconnection tests.

[0019] It should be noted that the state verification of remote direct memory access reconnection tests in existing technologies does not combine the remote direct memory access one-sided write primitive with the kernel cache synchronization mechanism. The state synchronization and judgment operations during the test process are always coupled with the execution of the reconnection state machine, which is the main reason why existing technologies cannot overcome the timing blocking and data deviation problems.

[0020] For example, when performing a kernel-mode remote direct memory access reconnection test, the existing testing method sends control messages to the fault detection node and resource reclamation node of the reconnection state machine. After sending the message, the local end needs to wait for the response message from the other end. The waiting time varies depending on the network environment. During the waiting period, the reconnection state machine cannot perform subsequent jump operations. At the same time, when the other end reads the state data, it does not perform cache synchronization operations. The new state data in the CPU cache is not synchronized to the physical memory. The physical memory data read by the remote direct memory access hardware is old data. After the other end performs the judgment based on the old data, it will output an incorrect judgment result, which will ultimately cause the reconnection test to fail.

[0021] In other words, during kernel-mode RDMA reconnection testing, existing methods often face a dilemma: if relying on message exchange to transmit the state between the two ends, the peer's confirmation feedback will inevitably cause the local reconnection state machine to pause and wait, disrupting the original timing; if a one-sided write operation is used to avoid feedback waiting, the state data in the local CPU cache may not have been synchronized to physical memory, and the RDMA hardware will obtain outdated data when directly reading physical memory, causing inaccurate consistency judgments. Simply performing a cache flush or merely isolating the memory region cannot simultaneously resolve the coexisting problems of timing congestion and data skewness.

[0022] Specifically, this application proposes corresponding technical solutions to address the problems of the prior art mentioned above. The following is a detailed explanation of the limitations of each technical solution.

[0023] This application provides a consistency verification method for kernel-mode memory access reconnection testing, such as... Figure 1 As shown, it includes: S100: During the kernel-mode remote direct memory access reconnection test, the local reconnection status is collected. The local reconnection status includes the recovery phase, queue pair status, resource status, and recovery generation during the remote direct memory access reconnection process. S200: The local reconnection status is encoded as a status identifier and synchronized to the peer's preset status mirror memory area through a one-sided write operation via remote direct memory access. The status mirror memory area is a physically contiguous and kernel-locked memory area, and the peer only has local read permissions for this area. S300: The peer performs a consistency check between the status identifier in the state mirror memory area and the local reconnection status and outputs the check result. The consistency check is to compare the degree of matching between the reconnection status of the two ends.

[0024] It should be noted that the core concept of this application is to collect the local reconnection status, including the recovery phase, queue pair status, resource status, and recovery generation, during the kernel-mode reconnection test, encode it into a status identifier adapted for transmission, and synchronize the status identifier to the physical contiguous and kernel-locked state mirror memory area of ​​the peer through a one-sided write operation of remote direct memory access. The peer performs consistency determination based on the status identifier in this area and the local status. No peer feedback or message interaction is required throughout the process. Combined with kernel cache synchronization, data accuracy is ensured, and non-blocking state synchronization and verification are achieved.

[0025] The embodiments of this application will be described in detail below.

[0026] In this embodiment, the kernel-mode remote direct memory access reconnection test is performed by a kernel-mode test module deployed at both ends of the communication. The test module runs in the kernel space of the remote direct memory access device and does not interact with the user space. The operation of collecting the local reconnection status is performed by the status acquisition component within the test module. The collected local reconnection status covers the key status parameters of the entire remote direct memory access reconnection process. The recovery phase is used to characterize the processing node in the reconnection process, the queue pair status is used to characterize the current running status of the queue pair, the resource status is used to characterize the reuse or release status of the protection domain, memory registration area, and completion queue, and the recovery generation is used to characterize the reconnection round and nesting level. All of the above status parameters are read from the kernel-mode remote direct memory access session management structure and resource management structure without modifying the storage content of the original management structure. Encoding the local reconnection status as a status identifier integrates discrete status parameters into a continuous data structure. This data structure is compatible with the transmission format of remote direct memory access (RDM) one-sided write operations. The state mirror memory region is a pre-allocated, physically contiguous memory area between both ends. Kernel locking prevents memory from being reclaimed or swapped by the system, ensuring stable access to this region by remote DRM hardware. The setting that the peer only has local read permissions avoids data conflicts caused by simultaneous writes to the memory region from both ends. The peer performs a consistency check by comparing the local status identifier in the state mirror memory region with the reconnection status collected locally on the peer, field by field. Based on the comparison results, a match or non-match result is output. The check process is executed asynchronously by the peer's kernel work queue and does not consume the execution resources of the reconnection state machine.

[0027] Specifically, the local reconnection status is collected, including: The jump node of the reconnected state machine based on remote direct memory access triggers the state acquisition operation; Read the state data of the remote direct memory access session and resource management structure in kernel mode; The read status data is integrated to form the local reconnection status.

[0028] In this embodiment, the operation of collecting the local reconnection status is divided into three consecutive sub-steps. The first step, triggering the status collection operation based on the jump node of the remote direct memory access (RDA) reconnection state machine, involves monitoring the instruction execution flow of the reconnection state machine. When the state machine jumps from one processing node to another, a collection instruction is triggered. This triggering method ensures that the collected status data is the stable state after the jump is completed, and temporary states during the jump process are not collected. The second step, reading the status data within the RDA session and resource management structure in kernel mode, involves directly reading the reconnection session parameters stored in the session management structure and the status parameters of queue pairs, protection fields, memory registration areas, and completion queues stored in the resource management structure through the kernel-mode memory access interface. The reading process is read-only and does not modify the original data within the management structure. The third step, integrating the read status data to form the local reconnection status, involves organizing the read discrete status parameters according to a preset parameter order to form a unified format set of status data, facilitating subsequent encoding and transmission operations.

[0029] For example, when the remote direct memory access reconnection state machine jumps from the fault detection node to the resource reclamation node, the state acquisition operation is automatically triggered. The test module reads the recovery phase parameters in the session management structure, the queue pair status and resource status in the resource management structure, and the recovery generation parameters corresponding to the reconnection round. After integrating the above parameters, a complete local reconnection state is formed.

[0030] Furthermore, those skilled in the art will understand that the triggering node for the state acquisition operation can be adjusted according to the needs of the test scenario. The adjustment process only requires modifying the monitoring range of the state machine transition node, without changing the execution flow of the acquisition operation, thus adapting to different reconnection test scenarios.

[0031] Specifically, for multi-round reconnection test scenarios, trigger conditions can be set at the state machine transition nodes of each round of reconnection to ensure that the state data of each round of reconnection can be completely collected. For single-round reconnection test scenarios, trigger conditions can be set only at key transition nodes to reduce the collection overhead of kernel mode.

[0032] It should be noted that the execution process of the state acquisition operation is a read-only operation. It will not modify the kernel-mode remote direct memory access session management structure and resource management structure, will not affect the normal execution of the original reconnection process, and will not change the running logic of the reconnection state machine.

[0033] For example, the status acquisition component accesses the session management structure and resource management structure through the kernel-mode memory read interface. The access permission is read-only, and the parameters within the structure cannot be modified. After the acquisition operation is completed, the access permission to the memory address is immediately released, and the kernel-mode memory resources are not occupied.

[0034] Furthermore, those skilled in the art will understand that the execution duration of the state acquisition operation can be adjusted through kernel-mode scheduling parameters to ensure that the acquisition operation does not occupy the execution time slice of the reconnection state machine and does not affect the execution sequence of the reconnection process.

[0035] Specifically, the state acquisition operation can be bound to a low-priority work queue in kernel mode and executed only during the execution intervals of the reconnection state machine. This will not preempt the central processing unit resources of the reconnection state machine, ensuring that the execution sequence of the reconnection process remains consistent with the original process.

[0036] In this embodiment, the triggering method of the state acquisition operation can be adapted according to different kernel versions. For kernel versions that support static trace points, the jump instructions of the state machine can be monitored through static trace points. For kernel versions that do not support static trace points, the execution of jump instructions can be monitored through kernel probes. Neither adaptation method will modify the execution flow of jump instructions, nor will it interfere with the operation of the reconnected state machine.

[0037] Specifically, for kernel versions that support static tracepoints, the state acquisition component can directly bind to preset static tracepoints in the kernel's remote direct memory access subsystem. When a state machine transition instruction is executed, the static tracepoint will automatically trigger the acquisition operation, requiring no additional monitoring code and having negligible impact on kernel operation. For kernel versions that do not support static tracepoints, the state acquisition component can monitor the execution of state machine transition functions through kernel dynamic probes. After the transition function completes execution, the acquisition operation is triggered. The loading and unloading of probes can be automatically completed at the start and end of the test process, without requiring a kernel or system restart.

[0038] It should be noted that, regardless of the triggering method used, the status acquisition operation is only triggered after the jump instruction is executed, and will not be executed during the jump process. This ensures that the acquired status data is stable data after the jump is completed, and there will be no status distortion caused by temporary data.

[0039] For example, the execution of state machine transition instructions is divided into three stages: instruction loading, instruction execution, and result writing. The state acquisition operation is only triggered after the result writing is completed and the state machine enters a new stable node. The acquired state data is the complete stable data of the new node and does not include intermediate temporary data during the transition process.

[0040] In some embodiments, the local reconnection status is encoded as a status identifier, including: Extract the identity field, generation field, stage field, and resource field from the local reconnection status; The extracted fields are concatenated according to a preset format to form a status identifier with a fixed structure; Add a validation field to the status identifier to complete the encoding process.

[0041] In this embodiment, encoding the local reconnection status into a status identifier requires structuring the status data and extracting the identity, generation, stage, and resource fields. The identity field includes a test task identifier and a session identifier to distinguish between different test tasks and reconnection sessions. The generation field includes the reconnection round and nesting level to distinguish reconnection states in different rounds. The stage field includes the local recovery stage and the expected peer recovery stage to characterize the processing node in the reconnection process. The resource field includes a resource status bitmap and the resource lifecycle generation to characterize the usage status of shared resources. Concatenating the extracted fields into a fixed-structure status identifier according to a preset format means concatenating data in the order of identity, generation, stage, and resource fields. The length of the concatenated data is fixed, facilitating transmission and parsing by remote direct memory access hardware. A verification field is added to the status identifier to complete the encoding process. This verification field verifies the data integrity of the status identifier during transmission. The verification data is automatically generated by the hardware, requiring no software calculation and avoiding increased kernel overhead from verification operations.

[0042] Furthermore, those skilled in the art will understand that the encoding format of the status identifier can be adjusted according to testing requirements. The adjustment process only requires modifying the field concatenation order and does not require changing the execution flow of the encoding operation.

[0043] Specifically, for multi-session concurrent testing scenarios, a batch identifier for concurrent sessions can be added to the identity field to distinguish concurrent sessions from different batches. For nested fault reconnection scenarios, a detailed identifier for the nesting level can be added to the generation field to distinguish nested reconnection statuses from different levels.

[0044] It should be noted that the fixed length of the status identifier can be set according to the number of status fields collected. Once set, it remains unchanged throughout the entire testing process, which facilitates the transmission of data to remote direct memory access hardware and the parsing processing at the other end, without the need to dynamically adjust the data parsing rules.

[0045] For example, the length of the status identifier is set to a fixed value, which can cover the storage requirements of all preset status fields. The remote direct memory access hardware can complete the transmission of the status identifier in one go without the need for packet sub-packetization and packet reassembly, thus reducing the complexity of hardware transmission.

[0046] Furthermore, those skilled in the art will understand that the method of generating the verification field can be adjusted according to the capabilities of the remote direct memory access hardware. If the hardware supports the verification function, the verification field is automatically generated by the hardware. If the hardware does not support it, it can be generated by the kernel-mode verification component. The generation process will not increase the kernel overhead too much.

[0047] Specifically, the process of generating the verification field only performs verification calculations on the complete data of the status identifier, without modifying the original field data within the status identifier, thus ensuring the integrity and accuracy of the status data.

[0048] It should be noted that the encoded status identifier is stored in contiguous memory in kernel mode. This memory region uses the same memory configuration as the status mirror memory region, ensuring that remote direct memory access hardware can stably access this memory region and successfully perform one-sided write operations.

[0049] For example, the memory region identified by the storage status is physically contiguous and kernel-locked memory. Remote direct memory access hardware can directly access this memory region without going through the central processing unit cache, ensuring the execution efficiency of one-sided write operations.

[0050] In this embodiment, the field concatenation order of the status identifier can be flexibly adjusted according to the needs of the test scenario. Core fields can be placed at the beginning of the status identifier, and non-core fields can be placed at the end, which facilitates the other end to quickly parse the core fields and improves the efficiency of consistency determination.

[0051] Specifically, for rapid reconnection testing scenarios, the generation and stage fields can be placed at the beginning of the status identifier. After the peer reads the status identifier, it can first parse the core fields to complete a rapid judgment, and then parse other fields to complete a full verification, improving the execution speed of the judgment process. For full-function testing scenarios, the identity field, generation field, stage field, and resource field can be concatenated in that order to ensure the orderly parsing of all fields and achieve consistent judgment across all dimensions.

[0052] It should be noted that once the field concatenation order of the status identifier is determined during test initialization, it will not change throughout the entire test process. Both ends use the exact same concatenation order and parsing rules to avoid parsing errors.

[0053] For example, during the test initialization phase, both ends will confirm the field concatenation order and parsing rules of the status identifier through a preset negotiation process. After the negotiation is completed, both ends will use the same rules for encoding and parsing throughout the entire test process, so there will be no problems with field misalignment or parsing errors.

[0054] Furthermore, those skilled in the art will understand that additional fields can be added to the status identifier according to testing requirements. The added fields only need to have their splicing length adjusted, without changing the core coding process, thus possessing good scalability.

[0055] Specifically, for scenarios that require statistical testing latency, a timestamp field can be added to the status identifier to record the time points of status acquisition, encoding, and synchronization, which facilitates subsequent latency statistics and analysis. For scenarios that require tracing event chains, an event sequence number field can be added to the status identifier to associate with the corresponding record in the kernel event log, which facilitates subsequent problem backtracking.

[0056] In some embodiments, synchronizing a one-sided write operation via remote direct memory access to a preset state mirror memory region on the other end includes: After completing the status flag encoding, perform a kernel cache synchronization operation to flush the cached data into physical memory; Initiate a one-sided write operation for remote direct memory access using a dedicated test queue; Write the state flag to the state mirror memory area of ​​the peer and update the state ready flag.

[0057] In this embodiment, the operation of synchronizing a remote direct memory access (RDA) one-sided write operation to a preset state mirror memory region on the other end, and then performing a kernel cache synchronization operation to flush cached data into physical memory after completing the state identifier encoding, is to eliminate data differences between the CPU cache and physical memory, ensuring that the physical memory data read by the RDA hardware is the latest state identifier data. The RDA one-sided write operation is initiated through a dedicated test queue, which is isolated from the service queue. Even when the service queue enters an error state, the dedicated test queue can still perform the one-sided write operation normally, ensuring the stability of the state synchronization channel. The state identifier is written to the state mirror memory region on the other end, and the state ready flag is updated. The state ready flag indicates that the state identifier has been completely written to the memory region. The other end only reads data when the state ready flag is valid, avoiding the reading of incomplete state data.

[0058] Specifically, the kernel cache synchronization operation is executed after the status identifier encoding is completed and before the one-sided write operation is initiated. This execution order can ensure that all status data is synchronized to physical memory and there will be no data omission.

[0059] It should be noted that the creation and initialization of the dedicated test queue pair are completed when the test process starts. There is no need to rebuild the dedicated test queue pair during the entire test process, which reduces the resource allocation overhead in the kernel mode. The running state of the dedicated test queue pair is independent of the business queue pair, and changes in the state of the business queue pair will not affect the normal operation of the dedicated test queue pair.

[0060] For example, when a service queue enters an error state due to a link failure, the dedicated test queue remains in a sendable state and can perform remote direct memory access one-sided write operations normally, ensuring that the state synchronization operation is not interrupted due to the service link failure.

[0061] Furthermore, those skilled in the art will understand that the number of dedicated test queue pairs can be adjusted according to the needs of the test scenario. A single dedicated test queue pair can be set for a single-session test scenario, while multiple dedicated test queue pairs can be set for a multi-session concurrent test scenario, each corresponding to a different concurrent session, to ensure the orderly execution of state synchronization operations.

[0062] Specifically, in multi-session concurrent testing scenarios, each concurrent session corresponds to an independent dedicated test queue pair. The state synchronization operations of different sessions are executed through different dedicated test queue pairs, so there will be no data confusion or transmission conflict.

[0063] It should be noted that the state ready flag is an atomic variable, stored in a fixed location in the state mirror memory area. The state ready flag will only be updated after the state identifier is completely written into the memory area, ensuring that the other end can only read the complete state identifier data.

[0064] For example, the initial state of the state ready flag is invalid. The state ready flag will only be updated to be valid after all fields of the state identifier have been completely written to the state image memory area. The peer will only perform the state identifier reading operation when the state ready flag is valid, so as to avoid reading incomplete state data.

[0065] Furthermore, those skilled in the art will understand that the update operation of the ready state flag is completed by the atomic interface, and in a multi-core CPU environment, multiple threads will not modify the flag simultaneously, thus ensuring the accuracy of the flag state.

[0066] Specifically, the operations of the atomic interface are provided by the kernel mode, and the operation time is in the nanosecond range. It will not increase the total time of state synchronization operations, nor will it affect the execution sequence of the reconnection process.

[0067] In this embodiment, the configuration parameters of the dedicated test queue can be adjusted according to the needs of the test scenario. Parameters such as queue depth and completion queue size can be adapted to different test pressures to ensure the stable execution of unilateral write operations.

[0068] Specifically, for high-frequency reconnection testing scenarios, the queue depth of the dedicated test queue pair can be increased to ensure that high-frequency one-sided write operations do not cause queue overflow. For low-frequency reconnection testing scenarios, the queue depth can be reduced to decrease kernel memory usage. For multi-session concurrent testing scenarios, an independent completion queue can be assigned to each dedicated test queue pair to avoid confusion of completion events from different sessions and improve event processing efficiency.

[0069] It should be noted that the transmission service type of the dedicated test queue pair is consistent with that of the business queue pair, which can adapt to different network environments and transmission requirements, and ensure the transmission stability of one-sided write operations.

[0070] For example, when the service queue pair uses the reliable connection service type, the dedicated test queue pair also uses the same reliable connection service type to ensure the reliability of the status identifier transmission and prevent data loss. When the service queue pair uses the unreliable datagram service type, the dedicated test queue pair can choose the reliable connection or unreliable datagram service type according to the requirements to adapt to different test scenarios.

[0071] Furthermore, those skilled in the art will understand that the port number of the dedicated test queue pair can be set independently of the service queue pair to avoid conflicts with the service port, while facilitating the configuration of network policies and ensuring the priority forwarding of state synchronization messages.

[0072] Specifically, the dedicated test queue uses an independent port number. Network devices can identify state synchronization messages based on the port number and configure independent forwarding priorities for them, avoiding delays in state synchronization message transmission caused by service message congestion and ensuring the real-time nature of state synchronization.

[0073] Furthermore, in some embodiments, performing a kernel cache synchronization operation to flush cached data into physical memory includes: The kernel direct memory access synchronization interface is invoked to synchronize the status flag data in the CPU cache to physical memory. Hardware-level data verification is performed through a memory consistency engine that uses remote direct memory access to the hardware. Once synchronization is complete, the physical memory data is marked as valid and accessible.

[0074] In this embodiment, the kernel cache synchronization operation to flush cached data into physical memory is divided into two synchronization steps: kernel-level and hardware-level. The kernel direct memory access (DMI) synchronization interface is called to synchronize the status flag data in the CPU cache to physical memory. The DMI synchronization interface is a standard kernel interface that can force dirty data in the CPU cache to be flushed into physical memory, ensuring consistency between physical memory data and CPU cache data. Hardware-level data verification is performed through the memory consistency engine of the remote DMI hardware. The memory consistency engine is a built-in component of the remote DMI hardware that verifies the integrity of data in physical memory. Only after successful verification is the peer allowed to read the data. This dual synchronization operation completely eliminates data discrepancies between the CPU cache and the remote DMI hardware. Marking the synchronized physical memory data as valid and accessible ensures that the remote DMI hardware can only access the complete synchronized data and will not read unsynchronized or incomplete data.

[0075] For example, after the status identification data stored in the central processing unit cache is synchronized to physical memory via the kernel direct memory access synchronization interface, the hardware memory consistency engine will verify the data length and verification field in physical memory. After the verification is successful, the data is marked as valid and the other end can read the data normally.

[0076] It should be noted that the call parameters of the kernel direct memory access synchronization interface are set according to the storage address and length of the status flag, ensuring that the synchronization operation only covers the memory area corresponding to the status flag, without affecting the data in other memory areas or other kernel-mode operation processes.

[0077] Specifically, the input parameters of the synchronization interface include the physical starting address of the status identifier storage memory, the memory length, and the data transmission direction. When the interface is executed, it only performs cache synchronization operations on the specified memory area and will not access other memory addresses, thus ensuring the stability of kernel operation.

[0078] Furthermore, those skilled in the art will understand that the type of kernel direct memory access synchronization interface can be adjusted according to the kernel version. Different kernel versions provide different synchronization interfaces. Only the calling method of the interface needs to be adjusted, without changing the execution logic of cache synchronization.

[0079] It should be noted that the hardware-level data verification performed by the memory consistency engine of the remote direct memory access hardware only verifies the integrity and continuity of the data, and does not modify the original data in physical memory, thus ensuring the accuracy of the status identifier data.

[0080] For example, the memory consistency engine checks whether the length of the status identifier data in physical memory is consistent with the preset length and whether the verification field matches the data content. Only after both verifications pass will the data be marked as valid and accessible; otherwise, it will be marked as invalid and the peer will be prohibited from reading it.

[0081] Furthermore, those skilled in the art will understand that the rules for hardware layer data verification can be adjusted according to testing requirements, and verification dimensions can be increased or the verification rules can be simplified to adapt to different remote direct memory access hardware capabilities.

[0082] Specifically, for remote direct memory access devices with strong hardware capabilities, the verification dimensions of data content can be increased to ensure data accuracy. For devices with limited hardware capabilities, only the data length can be verified to reduce hardware computational overhead.

[0083] It should be noted that the operation of updating the physical memory data to a valid and accessible state after the synchronization is completed is performed synchronously with the update operation of the state ready flag, ensuring that the data validity flag and the state ready flag are consistent. The other end can determine whether the data is readable by either flag.

[0084] For example, when physical memory data is marked as valid and accessible, the state ready flag is updated to valid. When the peer reads the state ready flag as valid, it can be determined that the data in the physical memory is complete data after synchronization is completed.

[0085] In this embodiment, the execution scope of the kernel cache synchronization operation can be precisely controlled according to the storage location of the status identifier. Only the cache line corresponding to the status identifier is synchronized, and the entire memory page is not synchronized, thereby reducing the kernel overhead caused by the cache synchronization operation.

[0086] Specifically, the kernel direct memory access synchronization interface can calculate the corresponding cache line range based on the starting address and length of the status identifier, and perform synchronization operations only on cache lines within this range, without affecting the data in other cache lines, thus significantly reducing the execution time of synchronization operations and kernel overhead.

[0087] It should be noted that the timing of cache synchronization operations can be adjusted according to the architecture of the central processing unit (CPU). For CPUs with non-uniform memory access architectures, cross-node cache synchronization operations can be added to ensure that the physical memory data accessed by different CPU nodes is consistent.

[0088] For example, for a server with a non-consistent memory access architecture, the status identifier is stored in the memory of the first central processing unit node, and the remote direct memory access hardware is mounted on the second central processing unit node. The cache synchronization operation will complete the cache consistency synchronization across nodes, ensuring that the remote direct memory access hardware of the second central processing unit node can read the latest status identifier data, and there will be no cross-node data inconsistency.

[0089] Furthermore, those skilled in the art will understand that for CPU architectures that support hardware cache coherency, the kernel cache synchronization operation process can be simplified by executing memory barrier instructions to ensure the data write order, without the need to force flush cache data, thereby further reducing the overhead of synchronization operations.

[0090] Specifically, for CPU architectures that support hardware cache consistency, the CPU and remote direct memory access hardware can ensure data consistency between the cache and physical memory through hardware mechanisms. In this case, only the memory barrier instruction needs to be executed after the status flag is written to ensure the order of data writing. There is no need to perform a complete cache flush operation, which further reduces the time consumption of synchronization operations.

[0091] The peer performs a consistency check between the state identifier within the state mirror memory region and the local reconnection state, including: The peer reads the state ready flag within the state mirror memory area; when the state ready flag is valid, it synchronizes the kernel cache and reads the state flag. The consistency determination is completed by comparing the corresponding fields of the status identifier with the local reconnection status. In this embodiment, the peer performs the consistency determination operation based on the status identifier in the status mirror memory area and the local reconnection status. The entire process is asynchronous. The peer reads the status ready flag in the status mirror memory area. The status ready flag is an atomic variable. The peer obtains the flag status through atomic read operations, and no read conflicts will occur. When the status ready flag is valid, the kernel cache is synchronized and the status identifier is read. The peer's kernel cache synchronization operation is consistent with that of the local end, which can ensure that the data in the peer's central processing unit cache is consistent with the data in physical memory. The operation of reading the status identifier is a read-only operation and will not modify the original data in the memory area. The corresponding fields of the status identifier are compared with the local reconnection status to complete the consistency determination. The comparison order is consistent with the field order of the status identifier. The identity field, generation field, stage field, and resource field are compared in turn. If all fields match, the determination result is a match; if any field does not match, the determination result is a mismatch.

[0092] It should be noted that the comparison rules for consistency determination can be adjusted according to the test scenario. In some scenarios, only the generation field and the stage field can be compared to simplify the determination process.

[0093] Specifically, for rapid reconnection test scenarios, only the generation field and stage field can be compared to speed up the execution of the judgment process. For complete reconnection test scenarios, all fields can be compared to ensure the accuracy of the judgment results.

[0094] Furthermore, those skilled in the art will understand that the consistency determination operation is executed by the low-priority work queue in the kernel mode of the peer, which will not occupy the execution time slice of the reconnection state machine and will not affect the execution timing of the reconnection process.

[0095] For example, the consistency determination operation is bound to the system work queue in the peer kernel mode and is executed only when the central processing unit is idle. It will not preempt the central processing unit resources of the reconnection state machine, ensuring that the execution sequence of the reconnection process is consistent with the original process.

[0096] It should be noted that the operation of synchronizing the kernel cache on the other end is only performed when the state is marked as valid, and the synchronization operation is not performed frequently, thus reducing the computational overhead of the kernel mode.

[0097] For example, the kernel work queue on the other end polls the state ready flags at fixed intervals. Only when the state ready flag is detected as valid will the kernel cache synchronization operation and the state flag reading operation be performed. When the flag is invalid, only the polling operation is performed, and no other additional operations are performed, thus reducing kernel overhead.

[0098] Furthermore, those skilled in the art will understand that the polling cycle can be adjusted according to the needs of the test scenario. For test scenarios with high real-time requirements, the polling cycle can be shortened, while for test scenarios with high kernel overhead requirements, the polling cycle can be extended.

[0099] Specifically, for high-frequency reconnection test scenarios, the polling period can be set to the microsecond level to ensure the real-time reading and judgment of status identifiers. For low-frequency reconnection test scenarios, the polling period can be set to the millisecond level to reduce the polling overhead in kernel mode.

[0100] It should be noted that the comparison operation between the status identifier and the local reconnection status only compares whether the values ​​of the fields are consistent. It does not modify the content of the fields, nor does it have any impact on the original data of the local reconnection status.

[0101] For example, when comparing identity fields, only the test task identifier and session identifier in the status identifier are compared to see if they match the test task identifier and session identifier in the local reconnection status. If they match, the field matches; if they do not match, the field does not match. The entire comparison process does not modify the original values ​​of any field.

[0102] In this embodiment of the application, the consistency determination comparison process can be set with hierarchical rules. First, the core fields are compared. If the core fields do not match, the mismatch determination result is directly output without comparing non-core fields, which further improves the determination efficiency.

[0103] Specifically, in the hierarchical comparison rules, core fields include the identity field, generation field, and stage field, while non-core fields include non-critical parameters in the resource field. After the peer reads the status identifier, it first compares the identity field. If the identity field does not match, it is directly determined as a mismatch, without needing to compare subsequent fields. If the identity field matches, it then compares the generation field. If the generation field does not match, it is directly determined as a mismatch. If the generation field matches, it then compares the stage field. If the stage field does not match, it is directly determined as a mismatch. If the stage field matches, it finally compares the resource field. Only when all fields match is the matching result output.

[0104] It should be noted that the hierarchical comparison rules can be adjusted according to the needs of the test scenario, and the division between core fields and non-core fields can be flexibly set to adapt to different test requirements.

[0105] For example, in test scenarios that are sensitive to resource status, the resource field can be set as a core field to increase the priority of resource status comparison. In test scenarios that are sensitive to reconnection rounds, the generation field can be set as the highest priority to prioritize comparison of the generation field.

[0106] Furthermore, those skilled in the art will understand that the consistency determination result can be synchronized to the local end in real time. The synchronization process can be completed through a one-sided write operation via remote direct memory access without additional message interaction, ensuring that the local end can obtain the determination result in real time.

[0107] Specifically, after the peer completes the consistency determination, the determination result can be encoded into a result identifier in a fixed format. A one-sided write operation is performed on the peer through a dedicated test queue to synchronize the result identifier to the preset result memory area on the local end. The local end can read the determination result through asynchronous polling. The whole process does not require message interaction or waiting for feedback and will not block the execution of the local reconnection state machine.

[0108] After the peer performs a consistency check between the state identifier in the state mirror memory region and the local reconnection state and outputs the check result, it also includes: When the determination result is a mismatch, an interrupt signal is triggered through the remote direct memory access hardware asynchronous event queue; Circuit breaking for reconnection testing is performed based on interrupt signals; the state data of both ends at the moment of circuit breaking is recorded to the kernel event log. In this embodiment, after the peer outputs the judgment result, if the judgment result is a mismatch, a corresponding processing flow needs to be executed to avoid the abnormal state affecting the subsequent test process. When the judgment result is a mismatch, an interrupt signal is triggered through the remote direct memory access hardware asynchronous event queue. The asynchronous event queue is independent of the business completion queue, and the interrupt signal is directly generated by the hardware without software intervention, ensuring the real-time performance of the interrupt signal. Circuit breaking for reconnection testing is performed based on interrupt signals. The circuit breaking process suspends the execution of the reconnection state machine, retains the current state data, and facilitates subsequent troubleshooting. The circuit breaking operation is directly executed by the kernel-mode test module without user-mode intervention. The state data of both ends at the moment of circuit breaking is recorded to the kernel event log. The kernel event log is a fixed-size circular storage area in the kernel mode, which can store the state data and event information of the entire test process, facilitating subsequent problem backtracking and troubleshooting.

[0109] Furthermore, those skilled in the art will understand that the execution conditions for circuit breaking can be adjusted according to testing requirements, triggering circuit breaking only when critical status fields do not match, and only logging when non-critical fields do not match.

[0110] Specifically, for cases where the identity field and generation field do not match, the circuit breaker will be triggered directly. For cases where non-critical parameters in the resource field do not match, only the event log will be recorded and the circuit breaker will not be triggered, thus ensuring the continuity of the testing process.

[0111] It should be noted that the priority of the remote direct memory access hardware asynchronous event queue is lower than that of the business event queue, and it will not affect the processing flow of business events. The triggering of interrupt signals will not interfere with the execution of the business reconnection process.

[0112] For example, the asynchronous event queue only processes interrupt signals related to state consistency determination, while the business event queue processes events related to the business reconnection process. The two queues are independent of each other, and the triggering of interrupt signals will not occupy the processing resources of the business event queue, nor will it affect the execution of the business reconnection process.

[0113] Furthermore, those skilled in the art will understand that the type of interrupt signal can be set according to the degree of mismatch in the judgment results. A high-priority interrupt is triggered in the case of severe mismatch, and a low-priority interrupt is triggered in the case of slight mismatch, thus adapting to different abnormal scenarios.

[0114] Specifically, if the generation field or stage field does not match, a high-priority interrupt is triggered, and circuit breaker processing is executed immediately. If non-critical parameters in the resource field do not match, a low-priority interrupt is triggered, and only the log is recorded without executing circuit breaker processing.

[0115] It should be noted that the execution of the circuit breaker only pauses the execution of the reconnect state machine, retains all state data and event logs, and does not release remote direct memory access resources. Testers can restore the test scenario based on the retained data and locate the cause of the state mismatch. The circuit breaker can be released through the kernel debugging interface. After being triggered, the reconnect state machine resumes execution without restarting the test process.

[0116] For example, after the circuit breaker is triggered, the reconnection state machine pauses at the current node, and all state data and event logs are retained in kernel-mode memory. After the tester reads the data and locates the problem through the debugging interface, the circuit breaker release instruction is triggered, and the reconnection state machine continues to execute the subsequent process.

[0117] Furthermore, those skilled in the art will understand that the storage area size of the kernel event log can be adjusted according to the needs of the test scenario. A larger storage area can be set for long-cycle test scenarios, while a smaller storage area can be set for short-cycle test scenarios, in order to avoid occupying too much kernel memory resources.

[0118] Specifically, the kernel event log uses a ring storage structure. When the storage area is full, it automatically overwrites the oldest log content, ensuring that the log always stores the latest test events and status data, and preventing storage overflow.

[0119] In this embodiment, the interrupt signal triggering and processing flow can be adapted according to the kernel version. For kernel versions that support fast hardware interrupt processing, the circuit breaker logic can be bound to the top half of the interrupt processing to ensure the real-time performance of the circuit breaker. For kernel versions that do not support fast interrupt processing, the circuit breaker logic can be placed in the bottom half of the interrupt processing to avoid interrupt processing consuming too much CPU time.

[0120] Specifically, for kernel versions that support fast hardware interrupt handling, after an interrupt signal is triggered, the top-half interrupt handler immediately performs circuit breaking, pausing the reconnection state machine. The entire process is completed in microseconds, ensuring that the abnormal state does not propagate. For kernel versions that do not support fast interrupt handling, after an interrupt signal is triggered, the top-half only records the interrupt event, while the bottom-half work queue performs circuit breaking during subsequent scheduling intervals, preventing interrupts from being disabled for an extended period and ensuring the normal operation of the kernel.

[0121] It should be noted that regardless of the interrupt handling method used, the circuit breaker will not modify the already executed result of the reconnection state machine, but only suspend the subsequent execution process to ensure the integrity of the state data and facilitate subsequent troubleshooting.

[0122] For example, after the circuit breaker is triggered, the reconnection state machine pauses at the current execution node. All completed state transitions, resource operations, parameter configurations, etc., will be completely preserved and will not be rolled back or modified. Testers can fully view all execution processes and state data before the exception occurred and accurately locate the cause of the exception.

[0123] Furthermore, those skilled in the art will understand that after the circuit breaker is triggered, the kernel-mode debugging information at the current moment can be automatically collected, including the kernel call stack, hardware register status, network device status, etc., and recorded in the kernel event log to provide more comprehensive information for subsequent troubleshooting.

[0124] Specifically, when the circuit breaker is executed, the kernel-mode debug information collection component is triggered simultaneously to collect debug information such as the kernel call stack, CPU register status, remote direct memory access hardware register status, and network link status at the current moment. This information, along with the dual-end status data and the judgment result, is written into the kernel event log to facilitate subsequent problem backtracking and root cause localization.

[0125] Furthermore, in some embodiments, before synchronizing a one-sided write operation via remote direct memory access to a preset state mirror memory region on the other end, the method further includes: Create a dedicated protection domain to isolate test resources from business resources; Allocate physically contiguous and kernel-locked memory within a dedicated protection domain as a state mirror memory region; Configure remote direct memory access one-sided write permissions for the state mirror memory region.

[0126] In this embodiment, before initiating a one-sided write operation for remote direct memory access, resource configuration of the state mirror memory region needs to be completed. A dedicated protection domain is created to isolate test resources from business resources. The dedicated protection domain is the resource isolation unit of the remote direct memory access hardware. Test resources and business resources belong to different protection domains, which can prevent abnormal business resources from affecting the operation of test resources. Physically contiguous and kernel-locked memory is allocated within the dedicated protection domain as the state mirror memory region. Physically contiguous memory can meet the access requirements of the remote direct memory access hardware, and kernel-locked memory can prevent memory from being swapped by the system, ensuring the stability of memory access. One-sided write permissions for remote direct memory access are configured for the state mirror memory region, allowing only the local end to perform one-sided write operations to this region, while the remote end only has read permissions. The permission configuration is completed by the memory registration interface of the remote direct memory access hardware. After configuration, it cannot be modified, which can ensure the security of memory access.

[0127] Specifically, the size of the state image memory region is set according to the length of the state identifier, which is a fixed value. There is no need to dynamically allocate memory, thus reducing the complexity of kernel-mode memory management.

[0128] It should be noted that the creation of the dedicated protection domain is completed when the test process starts, and it is only created once during the entire test process. It is destroyed after the test process ends, thus avoiding the kernel overhead caused by frequently creating and destroying protection domains.

[0129] For example, when the test process starts, the protection domain creation interface of the remote direct memory access hardware is called to generate a dedicated protection domain. All test-related queue pairs and memory registration areas belong to this dedicated protection domain, which is completely isolated from the protection domain to which the business resources belong. Exceptions in the business resources will not be transmitted to the test resources.

[0130] Furthermore, those skilled in the art will understand that the number of dedicated protection domains can be adjusted according to the needs of the test scenario. In multi-session concurrent test scenarios, multiple dedicated protection domains can be created, each corresponding to a different test session, to further improve the effect of resource isolation.

[0131] Specifically, in multi-session concurrent testing scenarios, each test session corresponds to an independent dedicated protection domain. The test resources of different sessions are isolated from each other, and resource anomalies in a single session will not affect the test process of other sessions, thus improving the stability of concurrent testing.

[0132] It should be noted that the allocation of the state mirror memory region adopts the kernel-mode physical memory allocation interface to ensure that the allocated memory is physically contiguous. At the same time, the memory is locked through the kernel locking interface to prevent the system from swapping the memory region to the disk, ensuring that the remote direct memory access hardware can stably access the memory region at any time.

[0133] For example, when allocating memory, the kernel-mode contiguous physical memory allocation interface is called. After the allocation is completed, the memory locking interface is called to lock the memory region in physical memory. It will not be reclaimed or swapped by the system until the test process is completed, at which point the memory lock and memory space will be released.

[0134] Furthermore, those skilled in the art will understand that the number of state mirror memory regions can be adjusted according to the needs of the test scenario. Multiple state mirror memory regions can be allocated for multi-session concurrent test scenarios, each corresponding to a different test session, to avoid confusion of state data between different sessions.

[0135] Specifically, in multi-session concurrent testing scenarios, each test session corresponds to an independent state image memory area. The state identifiers of different sessions are written to the corresponding memory areas, which will not cause data overwriting or confusion, thus ensuring the accuracy of the state data.

[0136] It should be noted that the permission configuration of the state mirror memory region is completed by the memory registration interface of the remote direct memory access hardware. After the configuration is completed, the hardware will forcibly restrict the memory access permissions, allowing only the local end to perform one-way write operations, and the remote end to perform local read operations. Any access that exceeds the permissions will be blocked by the hardware to ensure the security of memory access.

[0137] For example, if the access permissions configured during memory registration are writable on the local end and readable on the remote end, when the remote end attempts to perform a write operation to this memory area, it will be directly intercepted by the remote direct memory access hardware and an access error will be returned, without modifying any data in the memory area.

[0138] In this embodiment of the application, the access permissions of the dedicated protection domain can be configured in a fine-grained manner according to the testing requirements. Only the permissions necessary for the testing process are opened, while unnecessary permissions are closed, thereby reducing security risks and preventing test resources from being illegally accessed or abused.

[0139] Specifically, in the permission configuration of the dedicated protection domain, only the necessary permissions for memory registration, queue pair creation, and one-sided write operation are enabled, while non-essential permissions such as remote memory read, queue pair modification, and resource destruction are disabled. This ensures that test resources can only be used for state synchronization-related operations and will not be used for other purposes, thereby reducing security risks.

[0140] It should be noted that the memory registration lifecycle of the state image memory region is consistent with the lifecycle of the test process. Memory registration is completed when the test process starts and unregistered after the test process ends, releasing the corresponding memory resources to avoid kernel memory leaks.

[0141] For example, when the test process starts, the allocation, locking and registration of the state image memory region are completed. Throughout the test process, the memory registration information remains valid, and the remote direct memory access hardware can access the memory region at any time. After the test process is completely finished, the memory registration is deregistered first, then the memory lock is released, and finally the memory space is released. The complete resource release process can avoid kernel memory leaks.

[0142] Furthermore, those skilled in the art will understand that the state mirror memory region can be configured with corresponding memory access keys according to testing requirements. Only remote direct memory access devices holding the corresponding keys can perform one-sided write operations, further enhancing the security of memory access and preventing unauthorized devices from writing erroneous data.

[0143] Specifically, a corresponding access key can be configured during memory registration. When the local device initiates a one-way write operation, it needs to carry the correct access key. The remote direct memory access hardware will verify the validity of the key. Only if the key is correct will the write operation be allowed. If the key is incorrect, the access request will be directly intercepted, ensuring that only legitimate test devices can write the status identifier and avoiding data pollution caused by unauthorized access.

[0144] In some embodiments, the state acquisition operation triggered by the jump node of the reconnection state machine based on remote direct memory access includes: Monitor the jump instructions of the remote direct memory access reconnection state machine; A status acquisition operation is triggered when the jump instruction is completed; Data acquisition identifiers are assigned based on dynamic counting rules to distinguish the status data of different acquisition nodes.

[0145] In this embodiment, the state acquisition operation triggered by the jump node of the remote direct memory access reconnection state machine can be further refined into three sub-steps: monitoring the jump instruction of the remote direct memory access reconnection state machine, where the jump instruction is the core instruction for state machine node switching; the monitoring process is executed by the kernel-mode instruction monitoring component without modifying the instruction execution flow; triggering the state acquisition operation when the jump instruction is completed; and ensuring that the state machine enters a stable node after the jump instruction is completed, at which point the acquired state data is valid data and temporary states are not acquired. Acquisition identifiers are assigned based on a dynamic counting rule to distinguish the state data of different acquisition nodes. The dynamic counting rule is a monotonically increasing count, and each acquisition node corresponds to a unique acquisition identifier, facilitating subsequent state data traceability and comparison.

[0146] For example, the reconnection state machine sequentially executes four jump nodes: fault detection, resource reclamation, queue pair reconstruction, and parameter exchange. After each jump node is completed, a data acquisition operation is triggered. The dynamic counter is assigned data acquisition identifiers of 1, 2, 3, and 4 in sequence, with different identifiers corresponding to the state data of different nodes.

[0147] It should be noted that the monitoring process for jump instructions is passive; it does not modify the content of the jump instructions, nor does it change the execution order or timing of the jump instructions, and it will not have any impact on the operation of the reconnected state machine.

[0148] For example, the instruction monitoring component monitors the execution of jump instructions through static trace points in kernel mode. Static trace points are preset monitoring points in kernel mode that do not modify the instruction execution flow. They only trigger monitoring events when the instruction execution is completed, ensuring that the operation logic of the reconnection state machine is not changed.

[0149] Furthermore, those skilled in the art will understand that the monitoring scope of jump instructions can be adjusted according to the needs of the test scenario. It can monitor all state machine jump instructions or only the jump instructions of specified nodes, adapting to different test requirements.

[0150] Specifically, for complete reconnection process testing scenarios, all jump instructions of the state machine can be monitored to ensure that the state data of the entire process can be collected. For specific node testing scenarios, only the jump instructions of the specified node can be monitored and only the state data of the specific node can be collected, reducing the collection overhead of the kernel mode.

[0151] It should be noted that the status acquisition operation is only triggered after the jump instruction is executed, and will not be triggered during the execution of the jump instruction. This ensures that the acquired status data is stable data after the jump is completed, and will not acquire temporary data during the jump process, thus avoiding status data distortion.

[0152] For example, when a jump instruction begins execution, the instruction monitoring component only records the event of the instruction starting execution and does not trigger the data collection operation. Only after the jump instruction is completed and the state machine enters a new stable node will the state data collection operation be triggered to collect the stable state data of the current node.

[0153] Furthermore, those skilled in the art will understand that the counting range of the dynamic counting rule can be set according to the needs of the test scenario, and the maximum count can cover all the acquisition nodes in the test process to avoid counting overflow.

[0154] Specifically, the dynamic count uses a 16-bit unsigned integer with a maximum value of 65535. The number of acquisition nodes in a regular reconnection test is much lower than this value, so there will be no count overflow. The reading and modification of the count variable are atomic operations, so there will be no count conflict in a multi-core CPU environment.

[0155] It should be noted that the collection identifier will be integrated into the local reconnection status along with the status data. It will then be encoded into a status identifier and synchronized to the peer. The peer can use the collection identifier to distinguish the status data of different collection nodes, ensuring the accuracy of consistency determination.

[0156] For example, the status data with the collection identifier 3 corresponds to the status of the reconnection state machine queue for the reconstructed node. After the peer receives the status identifier, it can determine the collection node corresponding to the status data through the collection identifier and compare it with the status data of the same collection node locally to ensure that the compared nodes are consistent and avoid cross-node comparison errors.

[0157] In this embodiment, the dynamic counting rule can be adjusted according to the needs of the test scenario. In addition to the monotonically increasing counting method, a timestamp combined with a node number can be used to generate a collection identifier, further improving the uniqueness of the collection identifier and avoiding duplicate identifiers.

[0158] Specifically, for long-cycle, multi-round reconnection test scenarios, the high 32 bits can be used as the hardware monotonic timestamp and the low 32 bits as the node number to generate the acquisition identifier. The hardware monotonic timestamp will not roll back, and the node number distinguishes different acquisition nodes within the same time period, ensuring that each acquisition identifier is globally unique throughout the entire test process and will not be duplicated.

[0159] It should be noted that the generation of the acquisition identifier is an atomic operation. In a multi-core CPU environment, when multiple acquisition threads generate acquisition identifiers at the same time, there will be no identifier conflict, ensuring that the identifier of each acquisition node is unique.

[0160] For example, the generation process of the collection identifier is completed through the kernel-mode atomic operation interface. When multiple threads request the generation of the collection identifier at the same time, the atomic interface will ensure that the identifier obtained by each thread is unique and there will be no duplication or conflict.

[0161] Furthermore, those skilled in the art will understand that the collection identifier can be used for associated retrieval of kernel event logs. All events recorded during the test will be bound to the corresponding collection identifier, and all event logs and status data of the corresponding collection node can be quickly retrieved through the collection identifier, thereby improving the efficiency of problem backtracking.

[0162] Specifically, each record in the kernel event log carries the collection identifier of the corresponding collection node. When a mismatch occurs in the consistency determination, all event records, status data, and debugging information of the collection node can be quickly retrieved in the kernel event log through the collection identifier in the status identifier, without having to traverse the entire log file, which greatly improves the efficiency of problem localization.

[0163] This application also provides a consistency verification system for kernel-mode memory access reconnection testing, such as... Figure 2 As shown, it includes: 01 status acquisition unit, 02 status encoding unit, 03 single-sided write synchronization unit and 04 consistency determination unit; The status acquisition unit is used to acquire the local reconnection status during the kernel-mode remote direct memory access reconnection test; The status coding unit is used to encode the local reconnection status into a status identifier; The single-sided write synchronization unit is used to synchronize the status flag to the preset status mirror memory area of ​​the other end through a single-sided write operation via remote direct memory access. The consistency determination unit is used to perform consistency determination based on the status identifier in the state mirror memory area and the local reconnection status, and output the determination result. In this embodiment, the consistency verification system for kernel-mode memory access reconnection testing includes four functional units. These units exchange data through kernel-mode memory interaction. The status acquisition unit is a kernel-mode hardware abstraction component used to acquire the local reconnection status during kernel-mode remote direct memory access reconnection testing. The acquisition interface is a read-only interface and does not modify the original system data. The status encoding unit is a kernel-mode data processing component used to encode the local reconnection status into status identifiers. The encoding rule is a fixed format adapted to the transmission requirements of remote direct memory access one-sided writes. The one-sided write synchronization unit is a kernel-mode hardware communication component used to synchronize the status identifiers to the preset state mirror memory area of ​​the peer through remote direct memory access one-sided write operations. The communication channel is independent of the business communication channel. The consistency determination unit is a kernel-mode logic processing component used to perform consistency determination based on the status identifier in the state mirror memory area and the local reconnection status, and output the determination result. The determination process is executed asynchronously and does not occupy the execution resources of the reconnection process.

[0164] In this embodiment, the execution flow of the above technical solution is described in detail, taking into account a specific kernel-mode remote direct memory access reconnection test scenario. The two communication ends are the client and the server, respectively. Both ends load the kernel-mode remote direct memory access test module. During the initialization of the test module, a dedicated protection domain is created, and a physically contiguous and kernel-locked state mirror memory region is allocated within the dedicated protection domain. One-sided write permissions are configured for the memory region, and a dedicated test queue pair is created and switched to a sendable state. After the client detects a brief interruption in the remote direct memory access link, the reconnection state machine jumps from the initial node to the fault detection node. After the jump instruction is executed, a state acquisition operation is triggered. The test module reads the state data in the kernel-mode session management structure and resource management structure, and integrates them to form the local reconnection state, which includes the recovery stage, queue pair state, resource state, and recovery generation. The test module extracts the identity field, generation field, stage field, and resource field of the local reconnection state, concatenates them according to a preset format, and adds a verification field to form a state identifier. After the status identifier encoding is completed, the client calls the kernel direct memory access synchronization interface to synchronize the status identifier data in the CPU cache to physical memory. After the hardware memory consistency engine completes data verification, it initiates a remote direct memory access one-sided write operation through a dedicated test queue, writing the status identifier to the server's status mirror memory area and updating the status ready flag. The server's kernel work queue asynchronously reads the status ready flag. When the flag is valid, it calls the kernel direct memory access synchronization interface to synchronize the kernel cache. After reading the status identifier, it compares it field by field with the local reconnection status. If all status fields on both ends match, the matching result is output. Only the kernel event log is recorded, and no circuit breaker is executed. Throughout the entire process, the client's reconnection state machine immediately jumps to the resource reclamation node after initiating the one-sided write operation, without waiting for feedback from the server. The execution sequence of the reconnection process is consistent with the native process. The status data read by the server is completely consistent with the data written by the client, with no data deviation, and the consistency judgment result is accurate.

[0165] It should be noted that if there is a mismatch between the state fields of the two ends in the above scenario, the server will trigger an interrupt signal through remote direct memory access to the hardware asynchronous event queue. After receiving the interrupt signal, the client will pause the execution of the reconnection state machine, complete the test circuit breaker process, and retain the current state data for troubleshooting.

[0166] For example, when the client's recovery generation is 2 and the server's recovery generation is 1, the consistency determination result is a mismatch. The server triggers an interrupt signal, the client performs circuit breaker processing, the reconnection state machine is suspended at the resource reclamation node, and the test module records the field information of the state mismatch.

[0167] Furthermore, those skilled in the art will understand that the above technical solution can be adapted to multi-session concurrent reconnection test scenarios. Multiple reconnection sessions correspond to slots in multiple state mirror memory regions. The dynamic counting rules allocate different collection identifiers and slot identifiers. The state synchronization and judgment operations of each session are independent of each other, and no data conflicts will occur.

[0168] Specifically, during multi-session concurrent testing, each session corresponds to an independent slot in the state mirror memory area. The state acquisition, encoding, one-sided write synchronization, and consistency determination operations of each session are executed in parallel. The dynamic counting rule assigns a unique identifier to each session to distinguish the state data of different sessions and ensure the stability of concurrent testing.

[0169] In this embodiment, all operations of the above technical solutions are executed in kernel mode, without relying on user-mode interactive operations. The physical contiguity of the state mirror memory region and the kernel locking settings ensure stable access to remote direct memory access hardware. One-sided write operations of remote direct memory access do not require feedback from the other end, avoiding blocking the execution of the reconnection state machine by state synchronization operations. Kernel cache synchronization operations eliminate data differences between the central processing unit cache and physical memory, ensuring the accuracy of state data. Asynchronous consistency determination operations do not occupy the execution resources of the reconnection process. The coordinated execution of these technical features enables non-blocking state synchronization and consistency verification for kernel-mode remote direct memory access reconnection testing.

[0170] It should be noted that the technical solution of this application does not modify the native reconnection protocol of remote direct memory access. It only adds status acquisition, encoding, synchronization and judgment operations to the test process, which has no impact on the original business process and can be directly deployed in the existing kernel-mode remote direct memory access test system.

[0171] For example, the technical solution of this application is deployed in the kernel-mode remote direct memory access test module of the server operating system. The test module completes resource configuration during initialization, automatically performs status acquisition and synchronization operations during reconnection test, outputs consistency judgment results in real time, the execution sequence of the test process is consistent with the original process, and the accuracy of status data reading is maintained at a stable level, which can meet the verification requirements of kernel-mode remote direct memory access reconnection test.

[0172] Furthermore, those skilled in the art will understand that the technical solution of this application can be adapted to different models of remote direct memory access hardware. Only the calling method of the hardware interface needs to be adjusted, without changing the core status acquisition, encoding, synchronization, and judgment process, thus possessing good compatibility.

[0173] Specifically, for remote direct memory access hardware from different manufacturers, only the calling parameters of the memory registration interface, one-sided write operation interface, and cache synchronization interface need to be modified, while the core state processing flow and judgment rules remain unchanged, to complete the adaptation of the technical solution.

[0174] In this embodiment, the verification field of the status identifier can use verification data automatically generated by hardware, eliminating the need for software calculation and reducing the computational overhead of the kernel mode. The permission configuration of the status image memory area is completed by hardware, and the software is only responsible for sending configuration instructions, thus avoiding security issues caused by software permission configuration.

[0175] For example, the generation of the verification field is completed by the verification engine of the remote direct memory access hardware. The generation process takes only nanoseconds and does not increase the duration of status coding. After the permission configuration command for the status mirror memory region is sent, the hardware immediately executes the configuration and returns the configuration result. The software does not need to wait for the configuration to complete before it can perform subsequent operations.

[0176] In this embodiment, the dynamic counting rule adopts a monotonically increasing counting method. The counting variable is stored in the static memory of the kernel mode. The count is cleared to zero after restart. The counting range can cover the round requirements of normal reconnection test, and there is no need to worry about the problem of count overflow.

[0177] Specifically, the maximum value of the dynamic count is set to 65535. The number of rounds in a regular reconnection test is much lower than this value. The counting process is stable and there is no overflow. The reading and modification of the count variable are atomic operations, and there will be no counting conflicts in a multi-core CPU environment.

[0178] In this embodiment, the initialization process of the dedicated test queue pair is independent of the service queue pair. After initialization, it remains in a sendable state for a long time without needing to be rebuilt during the reconnection process, thus reducing the resource allocation overhead in the kernel mode. The completion queue of the dedicated test queue pair only processes the completion event of a one-sided write operation and does not process the transmission event of service data, ensuring the exclusivity of the state synchronization channel.

[0179] For example, after the dedicated test queue is initialized, it remains in a sendable state regardless of whether the business queue is in a normal or error state. The completion event of a one-sided write operation is handled by an independent completion queue, which will not be confused with the business event, thus facilitating event monitoring and processing in the kernel mode.

[0180] In this embodiment, the ready state flag is an atomic variable. Both reading and modification operations are atomic operations. In a multi-core CPU environment, multiple threads will not modify the flag at the same time, ensuring the accuracy of the flag state. The initial state of the ready state flag is invalid. After the state flag is completely written, it is updated to be valid. The peer only reads data in the valid state, which can completely avoid reading incomplete data.

[0181] Specifically, the operation of atomic variables is completed by the atomic interface in kernel mode. The operation time is in the nanosecond range and will not increase the state synchronization time. Atomic variables are stored at the end of the state mirror memory area and are physically isolated from the state identifier data, so there will be no data overwriting.

[0182] In this embodiment of the application, the consistency determination result only outputs whether it matches or does not match. The determination process only performs field comparison operations, without complex calculation logic. The kernel-mode computational overhead is extremely low. The determination result is stored in the kernel-mode event log and can be read through the kernel debugging interface, which is convenient for testers to view and troubleshoot problems.

[0183] Furthermore, those skilled in the art will understand that the storage format of the judgment result is a fixed format, including the judgment time, comparison field, and comparison result. The storage process is an append write, which will not overwrite the historical log, and can completely record the judgment result of the entire reconnection test process.

[0184] In this embodiment, the execution of the circuit breaker only pauses the execution of the reconnect state machine, retains all state data and event logs, and does not release remote direct memory access resources. Testers can restore the test scenario based on the retained data and locate the cause of the state mismatch. The circuit breaker can be released through the kernel debugging interface. After the triggering, the reconnect state machine resumes execution without restarting the test process.

[0185] For example, after the circuit breaker is triggered, the reconnection state machine pauses at the current node, and all state data and event logs are retained in kernel-mode memory. After the tester reads the data and locates the problem through the debugging interface, the circuit breaker release instruction is triggered, and the reconnection state machine continues to execute the subsequent process.

[0186] In this embodiment, the setting of a dedicated protection domain can completely isolate test resources from business resources. Anomalies in test resources will not affect the operation of business resources, and vice versa, ensuring the independence and stability of reconnection tests. The destruction of the dedicated protection domain is performed after the test process ends. During destruction, the state image memory area and the dedicated test queue are released simultaneously to avoid kernel-mode resource leakage.

[0187] Specifically, the creation and destruction of dedicated protection domains are completed by the protection domain interface of the remote direct memory access hardware. The resource release process is automatically executed by the hardware, and the software does not need to participate, thus avoiding kernel exceptions caused by software releasing resources.

[0188] Specifically, the state acquisition, encoding, synchronization, and judgment logic of this application is integrated into the kernel-mode module of the existing testing tool. When the testing tool starts, it automatically initializes the relevant resources, automatically performs state verification operations during the reconnection test, and automatically releases resources after the test. The integration process does not require modification of the original functional modules of the testing tool.

[0189] In this embodiment, the transmission latency of the remote direct memory access one-sided write operation is in the nanosecond range, the latency of state synchronization is negligible and will not affect the overall duration of the reconnection test. The latency of the kernel cache synchronization operation is also in the nanosecond range and will not increase the total time of state synchronization. The overall technical solution can meet the requirements of high-frequency reconnection tests.

[0190] For example, the total time for a single state acquisition, encoding, synchronization, and determination is in the microsecond range, which is far less than the execution time of the reconnection process and will not affect the overall efficiency of the reconnection test.

[0191] In this embodiment, the length of the status identifier is fixed, and no packet splitting and reassembly operations are required during transmission. The remote direct memory access hardware can complete the transmission in one go, reducing the complexity of hardware transmission. The fixed length of the status identifier also facilitates the parsing operation of the other end, eliminating the need for dynamic parsing of data length and simplifying the judgment process.

[0192] Specifically, the length of the status identifier is set according to the number of status parameters collected. In normal test scenarios, the length of the status identifier is a fixed value. Hardware transmission and parsing are one-time operations with no additional processing overhead.

[0193] In the embodiments of this application, the execution flow of all technical features is a linear flow, without branch jumps or loop operations. The execution logic of the kernel mode is simple and clear, which is easy to maintain and upgrade. Upgrading the technical solution only requires modifying the collection range of state parameters or the judgment rules, without changing the overall execution flow.

[0194] Furthermore, those skilled in the art will understand that the technical solution of this application can be adapted to remote direct memory access reconnection tests in reliable connection mode, as well as reconnection tests in other connection modes. Only the range of parameters for status acquisition needs to be adjusted, thus possessing good scalability.

[0195] Specifically, for remote direct memory access reconnection tests with different connection modes, only the type of collected status parameters needs to be modified, while the status encoding, synchronization, and judgment processes remain unchanged, thus completing the adaptation for different test scenarios.

[0196] In this embodiment, the kernel event log can be read through the kernel debugging interface without restarting the test process or system. Testers can read the log content in real time during the test to view the consistency judgment results and status data, which facilitates real-time monitoring of the test process's running status.

[0197] For example, testers can read the contents of the kernel event log in real time through the kernel-mode debug file system interface to view the results of each consistency determination, the fields compared, and the status data, without pausing the test process or restarting the system.

[0198] Furthermore, those skilled in the art will understand that the contents of the kernel event log can be exported to a user-space storage device for subsequent test report generation and problem analysis, and the export process will not affect the normal execution of the test process.

[0199] Specifically, the kernel-mode log export component can transfer event logs in the circular storage area to the user-mode stored procedure through the shared memory area between kernel and user modes. The stored procedure then writes the log content to the local storage device. The entire export process will not interrupt the execution of the test process, nor will it affect the operation of the reconnected state machine.

[0200] In this embodiment, the release of the state mirror memory region is only performed after the test process is completely completed. During the test process, the state mirror memory region remains locked and will not be reclaimed by the system, ensuring that the remote direct memory access hardware can stably access the memory region throughout the entire test process.

[0201] For example, when the test process starts, a state mirror memory region is allocated and locked. During the execution of the test process, no matter how many reconnection rounds there are, this memory region always remains in the allocated and locked state. Only when the test process is completely finished and all reconnection operations are completed will the memory lock be released and the memory region be released.

[0202] Furthermore, those skilled in the art will understand that the contents of the state image memory area can be retained after the test process is completed for subsequent problem backtracking and analysis, and the memory release operation will only be performed when the tester confirms that it does not need to be retained.

[0203] Specifically, after the test process is completed, all state data in the state image memory area can be exported to the user space storage device through the kernel debugging interface. After the export is completed, the memory release operation is performed to ensure that all state data during the test can be completely preserved, which is convenient for subsequent problem analysis.

[0204] In this embodiment of the application, the error handling mechanism of the dedicated test queue is independent of the business queue. When an error occurs in the dedicated test queue, the queue will be automatically reset and rebuilt without affecting the operation of the business queue or interrupting the execution of the test process.

[0205] For example, when a dedicated test queue enters an error state due to a hardware malfunction, the test module will automatically detect the error, immediately destroy the erroneous queue pair, recreate a new dedicated test queue pair, and switch it to a sendable state. The entire reset process is completed in microseconds, without interrupting the execution of the test process or affecting the normal operation of the business queue pair.

[0206] Furthermore, those skilled in the art will understand that during the reset and reconstruction of the dedicated test queue pair, the status identifier will be temporarily stored in the kernel-mode buffer. After the queue pair is reconstructed, the unfinished one-sided write operation will be executed immediately, and there will be no loss of status data.

[0207] Specifically, when an error occurs in the dedicated test queue, the status flag to be sent will be written into a circular buffer in kernel mode. After the queue is rebuilt, the test module will read the status flags in the buffer in sequence and perform one-sided write operations in turn to ensure that all status flags can be synchronized to the other end and no data loss will occur.

[0208] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A consistency verification method for kernel-mode memory access reconnection testing, characterized in that, include: During the kernel-mode remote direct memory access reconnection test, the local reconnection status is collected. The local reconnection status includes the recovery phase, queue pair status, resource status, and recovery generation during the remote direct memory access reconnection process. The local reconnection status is encoded as a status identifier and synchronized to the peer's preset status mirror memory area through a one-sided write operation via remote direct memory access. The status mirror memory area is a physically contiguous and kernel-locked memory area, and the peer only has local read permissions for this area. The peer performs a consistency check between the state identifier in the state mirror memory area and the local reconnection state and outputs the check result. The consistency check is to compare the degree of matching between the reconnection states of the two ends. Synchronization of one-sided write operations via remote direct memory access to a pre-defined state mirror memory region on the other end includes: After completing the status flag encoding, perform a kernel cache synchronization operation to flush the cached data into physical memory; Initiate a one-sided write operation for remote direct memory access using a dedicated test queue; Write the status flag to the state mirror memory area of ​​the peer and update the state ready flag; Perform kernel cache synchronization operations to flush cached data to physical memory, including: The kernel direct memory access synchronization interface is invoked to synchronize the status flag data in the CPU cache to physical memory. Hardware-level data verification is performed through a memory consistency engine that uses remote direct memory access to the hardware. Once synchronization is complete, the physical memory data is marked as valid and accessible.

2. The method according to claim 1, characterized in that, The local reconnection status is collected, including: The jump node of the reconnected state machine based on remote direct memory access triggers the state acquisition operation; Read the state data of the remote direct memory access session and resource management structure in kernel mode; The read status data is integrated to form the local reconnection status.

3. The method according to claim 1, characterized in that, The local reconnection status is encoded into a status identifier, including: Extract the identity field, generation field, stage field, and resource field from the local reconnection status; The extracted fields are concatenated according to a preset format to form a status identifier with a fixed structure; Add a validation field to the status identifier to complete the encoding process.

4. The method according to claim 1, characterized in that, The peer performs a consistency check between the state identifier within the state mirror memory region and the local reconnection state, including: The peer reads the state ready flag within the state mirror memory area; when the state ready flag is valid, it synchronizes the kernel cache and reads the state flag. The corresponding fields of the status identifier and the local reconnection status are compared to complete the consistency determination.

5. The method according to claim 1, characterized in that, After the peer performs a consistency check between the state identifier in the state mirror memory region and the local reconnection state and outputs the check result, it also includes: When the determination result is a mismatch, an interrupt signal is triggered through the remote direct memory access hardware asynchronous event queue; The circuit breaker process performs a reconnection test based on the interrupt signal; the state data of both ends at the moment of circuit breaker failure is recorded to the kernel event log.

6. The method according to claim 1, characterized in that, Before synchronizing a one-sided write operation via remote direct memory access to the preset state mirror memory region on the other end, it also includes: Create a dedicated protection domain to isolate test resources from business resources; Allocate physically contiguous and kernel-locked memory within a dedicated protection domain as a state mirror memory region; Configure remote direct memory access one-sided write permissions for the state mirror memory region.

7. The method according to claim 2, characterized in that, The state acquisition operation triggered by the jump node of the reconnection state machine based on remote direct memory access includes: Monitor the jump instructions of the remote direct memory access reconnection state machine; A status acquisition operation is triggered when the jump instruction is completed; Data acquisition identifiers are assigned based on dynamic counting rules to distinguish the status data of different acquisition nodes.

8. A consistency verification system for kernel-mode memory access reconnection testing, characterized in that, include: The system includes a status acquisition unit, a status coding unit, a one-sided write synchronization unit, and a consistency determination unit. The status acquisition unit is used to acquire the local reconnection status during the kernel-mode remote direct memory access reconnection test; The status coding unit is used to encode the local reconnection status into a status identifier; The single-sided write synchronization unit is used to synchronize the status flag to the preset status mirror memory area of ​​the other end through a single-sided write operation via remote direct memory access. Synchronization of one-sided write operations via remote direct memory access to a pre-defined state mirror memory region on the other end includes: After completing the status flag encoding, perform a kernel cache synchronization operation to flush the cached data into physical memory; Initiate a one-sided write operation for remote direct memory access using a dedicated test queue; Write the status flag to the state mirror memory area of ​​the peer and update the state ready flag; Perform kernel cache synchronization operations to flush cached data to physical memory, including: The kernel direct memory access synchronization interface is invoked to synchronize the status flag data in the CPU cache to physical memory. Hardware-level data verification is performed through a memory consistency engine that uses remote direct memory access to the hardware. Once synchronization is complete, the physical memory data is marked as valid and accessible. The consistency determination unit is used to perform consistency determination based on the status identifier in the state mirror memory area and the local reconnection status, and output the determination result.

Images