Data replay method, data processing unit, network interface card, device, and storage medium

Abstract

The present application relates to a data replay method, a data processing unit, a network interface card, a device, and a storage medium. The method comprises: when a storage stack is restarted, acquiring a replay-pending request queue from a persistent memory, the replay-pending request queue being a queue obtained by mapping a transmission buffer area into the persistent memory, and the transmission buffer area being used for receiving a request from a host side; on the basis of the replay-pending request queue, acquiring a replay-pending request from the persistent memory; and resending the replay-pending request to a target acceleration component directed to a storage device, so as to instruct the storage device to store target data which resides in the persistent memory and corresponds to the replay-pending request. In the method, a request queue, a request, and data corresponding to the request are stored in the persistent memory in advance, and if the storage stack is restarted, the replay-pending request is recovered from the persistent memory, eliminating the need for DMA and encryption / decryption techniques, and shortening an interruption duration of a storage data path, thereby improving data storage efficiency on the host side.

Description

Data replay method, data processor, network interface card, device and storage medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on August 28, 2024, with application number 202411194522X, entitled "Data Replay Method, Data Processor, Network Interface Card, Device and Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of data processor technology, and in particular to a data replay method, a data processor, a network interface card, a computer device, and a computer-readable storage medium. Background Technology

[0004] If the SPDK (Storage Performance Development Kit, hereinafter referred to as "storage stack") service in the Data Processing Unit (DPU) exits abnormally or needs to be upgraded, it will cause IO (input / output) requests that have been read from the driver queue on the host side into the DPU to fail to be processed normally. After the storage stack in the DPU is restarted, these IO requests need to be replayed to restore the interrupted data path on the host side.

[0005] In traditional data replay methods, after the storage stack is restarted, its process space and memory are initialized. The DPU needs to analyze the context information of the driver queue before the interrupt and use DMA (Direct Memory Access) to reread the I / O requests that need to be replayed from the host side to complete the subsequent I / O processing. This method requires a second DMA read of the I / O requests to be replayed, which leads to excessive interruption time in the storage data path and affects the data storage efficiency on the host side. Some DPUs also have hardware encryption and decryption processes designed in them. When rereading the I / O requests to be replayed from the host side, the use of hardware encryption and decryption processes will further increase the interruption time in the storage data path. Summary of the Invention

[0006] Therefore, it is necessary to provide a data replay method, a data processor, a network interface card, a computer device, and a computer-readable storage medium to address the aforementioned technical problems, which can shorten the interruption time of the storage data path on the host side and improve the data storage efficiency on the host side.

[0007] In a first aspect, this application provides a data replay method, which is applied to a data processor and includes:

[0008] In the event of a storage stack restart, the request queue to be replayed is retrieved from persistent memory; the request queue to be replayed is a queue obtained by mapping the transfer buffer in persistent memory, which is used to receive requests from the host side.

[0009] Retrieve requests to be replayed from persistent memory based on the queue of requests to be replayed;

[0010] The replay request is resent to the target acceleration component that points to the storage device, instructing the storage device to store the target data corresponding to the replay request in persistent memory.

[0011] In one embodiment, retrieving replay requests from persistent memory according to the request queue includes:

[0012] Retrieve each target request pointed to by each element in the request queue to be replayed from persistent memory;

[0013] Read the status of each target request;

[0014] Target requests in the initial or processing state are identified as requests to be replayed; the initial state indicates that the target request has not been submitted to the target acceleration component pointing to the storage device, and the processing state indicates that the target request has been submitted to the target acceleration component pointing to the storage device.

[0015] In one embodiment, retrieving the request queue to be replayed from persistent memory includes:

[0016] Retrieve cursor information for each request queue from persistent memory; cursor information includes head cursor information, tail cursor information, and middle cursor information.

[0017] The request queue whose head cursor information is inconsistent with the middle cursor information is identified as the request queue to be replayed.

[0018] Retrieve each target request pointed to by each element in the request queue to be replayed from persistent memory, including:

[0019] Based on the head cursor information and middle cursor information of the request queue to be replayed, at least one target element is obtained from the request queue to be replayed.

[0020] Retrieve at least one target request pointed to by a target element from persistent memory.

[0021] In one embodiment, persistent memory includes a data cache and a request store, and the method further includes:

[0022] The data cache area and the request storage area are split according to the set size to obtain data segments and request segments;

[0023] The address information of data segments is managed using the data memory pool of the data plane development kit;

[0024] The request memory pool of the data plane development kit is used to manage the address information of request segments;

[0025] During the initialization of the transfer buffer, the data memory pool is used to allocate target data segments for each element in the transfer buffer, and the request memory pool is used to allocate target request segments for each element in the transfer buffer.

[0026] Based on the address information of the target data segment, the data corresponding to each element in the transmission buffer is stored in the data buffer area;

[0027] Based on the address information of the target request segment, the requests corresponding to each element in the transmission buffer are stored in the request storage area.

[0028] In one embodiment, after retrieving the requests to be replayed from persistent memory according to the request queue to be replayed, the method further includes:

[0029] Remove the address information of the data segment corresponding to the request to be replayed from the data memory pool;

[0030] Remove the address information of the request segment corresponding to the request to be replayed from the request memory pool.

[0031] In one embodiment, after resending the replay request to the target acceleration component pointing to the storage device to instruct the storage device to store the target data corresponding to the replay request in persistent memory, the method further includes:

[0032] If a response to the request to replay is received, the response is placed in the receive buffer;

[0033] If it is detected that the host has completed the operation corresponding to the response, the element corresponding to the request to be replayed is removed from the request queue to be replayed.

[0034] In one embodiment, the state of the request stored in persistent memory includes any one of an initial state, a processing state, a waiting state, and a completion state; the method further includes:

[0035] After storing the requests corresponding to each element in the transfer buffer into persistent memory, the state of the requests in persistent memory is set to the initial state; the initial state is used to indicate that the request has not been submitted to the target acceleration component pointing to the storage device.

[0036] After resending the replay request to the target acceleration component pointing to the storage device, the status of the replay request is updated to the processing status; the processing status indicates that the request has been submitted to the target acceleration component pointing to the storage device.

[0037] After receiving a response to the replay request, the status of the replay request is updated to a waiting state; the waiting state indicates that the storage device has responded but the host has not responded.

[0038] After detecting that the host has completed the operation corresponding to the response, the status of the request to be replayed is updated to the completed status; the completed status is used to indicate that the host has responded.

[0039] Remove the elements corresponding to the requests to be replayed from the request queue, including:

[0040] If the queue of requests to be replayed also includes at least one second element preceding the first element, then the state of the request pointed to by the at least one second element is determined; the first element is the element corresponding to the request to be replayed.

[0041] If at least one of the requests pointed to by the second element is in the completed state, then remove the first element and at least one second element from the request queue to be replayed.

[0042] Secondly, this application also provides a data processor, including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to perform the following steps:

[0043] In the event of a storage stack restart, the request queue to be replayed is retrieved from persistent memory; the request queue to be replayed is a queue obtained by mapping the transfer buffer in persistent memory, which is used to receive requests from the host side.

[0044] Retrieve requests to be replayed from persistent memory based on the queue of requests to be replayed;

[0045] The replay request is resent to the target acceleration component that points to the storage device, instructing the storage device to store the target data corresponding to the replay request in persistent memory.

[0046] Thirdly, this application also provides a network interface card, including the data processor and multiple interfaces as described above, through which the data processor communicates with the outside world.

[0047] Fourthly, this application also provides a computer device, including a central processing unit and a data processor as described above, wherein the data processor is used to schedule messages to the central processing unit or to process them itself, and the central processing unit is used to process messages scheduled by the data processor.

[0048] Fifthly, this application also provides a computer-readable storage medium storing computer-readable instructions thereon, which, when executed by a processor, perform the following steps:

[0049] In the event of a storage stack restart, the request queue to be replayed is retrieved from persistent memory; the request queue to be replayed is a queue obtained by mapping the transfer buffer in persistent memory, which is used to receive requests from the host side.

[0050] Retrieve requests to be replayed from persistent memory based on the queue of requests to be replayed;

[0051] The replay request is resent to the target acceleration component that points to the storage device, instructing the storage device to store the target data corresponding to the replay request in persistent memory.

[0052] The aforementioned data replay method, data processor, network interface card, computer device, and computer-readable storage medium, in the event of a storage stack restart, retrieve the request queue to be replayed from persistent memory. This request queue is a queue mapped from the transmission buffer in persistent memory, used to receive requests from the host side. Based on the request queue, the requests to be replayed are retrieved from persistent memory. These requests are then resent to the target acceleration component pointing to the storage device, instructing the storage device to store the target data corresponding to the replay request in persistent memory. This method pre-stores the request queue, requests, and corresponding data in persistent memory. If the storage stack restarts, the replay requests are recovered from the DPU's persistent memory, eliminating the need for DAM and encryption / decryption techniques. This shortens the interruption time of the host-side storage data path and improves host-side data storage efficiency. Attached Figure Description

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

[0054] Figure 1 is a schematic diagram of the data flow in a traditional data replay method;

[0055] Figure 2 is a flowchart illustrating a data replay method in one embodiment;

[0056] Figure 3 is a logic block diagram of a data processor in one embodiment;

[0057] Figure 4 is a flowchart illustrating the data replay method in another embodiment;

[0058] Figure 5 is a flowchart of the initialization process of the data replay method in one embodiment;

[0059] Figure 6 is a schematic diagram of the changes in the request queue in one embodiment;

[0060] Figure 7 is a block diagram of the internal structure of a computer device in one embodiment. Detailed Implementation

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

[0062] Understandably, hardware manufacturers typically customize proprietary SPDK services within the DPU to provide a more flexible storage acceleration solution. The proprietary SPDK service within the DPU utilizes TCP / RDMA (a combination of TCP protocol and RDMA technology; RDMA stands for Remote Direct Memory Access) to emulate remote storage resources as physical disk devices on the PCIe (a high-speed serial computer expansion bus standard) bus, mapping them to local block storage devices on the host / VM side. Combined with Virtio / NVMe hardware virtualization and encryption / decryption acceleration technologies, it provides high-performance and secure data storage services to the host / VM.

[0063] When the custom private SPDK service in the DPU exits abnormally or needs to be upgraded, it can cause IO requests already read from the host / VM driver queue into the DPU to fail to process properly. This can lead to host / VM IO hangs (slow disk read / write, causing threads and processes to suspend) or IO interruptions. These unfinished IO requests within the DPU are called replay IO. After the firmware handling stored data in the DPU restarts, it needs to replay this IO to restore the interrupted data path in the host / VM.

[0064] Referring to Figure 1, which is a schematic diagram of the data flow in a traditional data replay method, the ARM CPU refers to the core processing unit in the DPU. The traditional DPU replay IO data flow includes:

[0065] 1. The VHOST layer (virtual host layer) collects context information of the NVMe / Virtio driver queues on the host side before replay IO is interrupted in different scenarios such as NVMe (non-volatile memory host controller interface specification), virtio-blk (virtualized block storage), and virtio-crypto (for encryption and decryption operations in virtualization environments) in the DPU hardware registers. This information can include the physical address of the NVMe SQ (NVMe operation command submission queue), the physical address of the Virtqueue (the actual data link for data exchange between the front-end and back-end circular queues), and the position information of the driver queue cursor.

[0066] 2. VHOST calculates the number of replay IOs and their positions in the NVMe / vritio driver queue by collecting the driver queue context information. DPU then reads the replay IOs that need to be replayed from the host side through the Internal TX / RX ring (internal transmit or receive ring) using DMA path and hardware encryption / decryption technology.

[0067] 3. The BDEV layer (block device layer) sends the replay IO in the internal TX / RX ring to the remote Storage Cloud (cloud storage device) again through NVMe-OF Transport (TCP / RDMA).

[0068] 4. After Storage Cloud responds to read / write responses, it restores the interrupted data path on the host side.

[0069] It's important to note that prolonged interruptions to the storage data path can pose a risk of downtime for terminal services with high I / O continuity requirements, and also negatively impact the end-user experience. Shorter replay I / O times result in faster data path recovery and a more user-friendly experience.

[0070] In traditional data replay methods, since the process space and memory are initialized after the storage stack is restarted, the DPU needs to analyze the context information of the driver queue before the interrupt and use DMA (Direct Memory Access) to reread the IO requests that need to be replayed from the host side to complete the subsequent IO processing. This approach has the following problems:

[0071] The secondary DMA-based I / O request retrieval involves data interaction between the DPU and the host side, including DMA transfer initiation, data retransmission and verification, host-side response and scheduling, all of which consume time. This leads to excessively long interruptions in the storage data path, impacting host-side data storage efficiency. The design incorporates hardware encryption / decryption procedures, which further increase the interruption time when rereading I / O requests requiring replay from the host side. In different scenarios such as NVMe and virtio blk / crypto, separate replay logic needs to be developed for the different descriptor types stored in the driver queues, resulting in high code complexity and maintenance difficulty.

[0072] The data replay method provided in this application stores the request queue, requests, and corresponding data in persistent memory in advance. If the storage stack restarts, the requests to be replayed are recovered from the DPU's persistent memory. This eliminates the need for DAM and encryption / decryption technologies, shortening the interruption time of the host-side storage data path and improving host-side data storage efficiency. It standardizes the replay process across different storage business scenarios, handling encryption / decryption, NVMe, and virtio (virtualization) scenarios without distinction. The logic is simple and maintenance is easy.

[0073] In an exemplary embodiment, as shown in FIG2, a data replay method is provided, the method being applied to a data processor, comprising:

[0074] Step 202: In the event of a storage stack restart, retrieve the request queue to be replayed from persistent memory; the request queue to be replayed is a queue obtained by mapping the transmission buffer in persistent memory, and the transmission buffer is used to receive requests from the host side.

[0075] The storage stack is the SPDK (Storage Performance Development Kit) running in the Data Processor (DPU). When the SPDK service exits abnormally or needs to be upgraded, it will cause IO requests that have been read from the driver queue on the host side into the DPU to fail to be processed normally. After the SPDK restarts, these IO requests need to be replayed to restore the interrupted data path on the host side.

[0076] It is understandable that the transmission buffer, i.e., the tx ring (transmission ring buffer) within the DPU, is used to receive requests from the host side. The tx ring is associated with one or more drive queues on the host side, and the tx ring and drive queues cooperate to perform data transmission. Optionally, the request queues (or replay queues) stored in persistent memory correspond one-to-one with the drive queues on the host side.

[0077] Persistent memory (PMEM) is a type of storage hardware that ensures data is not lost when power is off. Optionally, persistent memory can be persistent huge pages (HugePages) within the DPU.

[0078] In its implementation, the VHOST layer allocates four parts of persistent shared memory (i.e., persistent memory) to store request queues, cursor information, data, and requests, respectively. During replay, the starting physical address of each shared memory can be obtained based on its shared memory identifier (shmid). Assuming 32K replay queues are reserved, each corresponding one-to-one with the driver queue, the request queue occupies 32K * 512 (queue size) * 8B = 128MB of contiguous shared memory. The starting position of each replay queue can be found using a global qid index.

[0079] The request queue stored in persistent memory includes at least one element, each of which is a pointer to a replay request.

[0080] Step 204: Retrieve the requests to be replayed from the persistent memory according to the request queue to be replayed.

[0081] From persistent memory, determine the requests pointed to by each element in the request queue to be replayed, and identify the replay requests (i.e., requests to be replayed) from among them. In one implementation, each element in the request queue to be replayed includes a request address (replay request addr), pointing to a replay request object in the mempool. Based on the address information of the replay request object in the mempool, retrieve the corresponding request from persistent memory, and determine the request to be replayed from the requests corresponding to each element in the request queue to be replayed.

[0082] Step 206: The replay request is resent to the target acceleration component pointing to the storage device to instruct the storage device to store the target data corresponding to the replay request in persistent memory.

[0083] The storage device is a remote storage device mounted on the PCIe bus (such as Storage Cloud in Figure 1). The target acceleration component is a vhost target that points to the storage device, used to accelerate data transfer from virtual machines to backend storage or network devices.

[0084] The persistent memory also stores the data corresponding to each request. The BDEV layer resends the request to be replayed to the remote storage device, restores the interrupted data path, and instructs the storage device to store the target data corresponding to the request to be replayed in the persistent memory.

[0085] Referring to Figure 3, which is a logical block diagram of a data processor in one embodiment, an internal TX / RX ring and a replay queue are set in the persistent huge page memory (HugePages) resources of the DPDK (Data Plane Development Kit). By persistently replaying IO through the huge page memory resources within the DPU, the storage data path can be recovered efficiently.

[0086] In one implementation, after receiving a write data request through the tx ring, the DPU places the request in the tx ring into the replay queue. By traversing the replay queue, it identifies unprocessed requests and sends them to the target acceleration component pointing to the storage device. That is, the data replay method and normal IO process provided in this application both use the replay queue to send requests, thus unifying the replay process and normal IO processing process for different services.

[0087] In the aforementioned data replay method, in the event of a storage stack restart, the request queue to be replayed is retrieved from persistent memory. This queue is a mapping of the transmission buffer to persistent memory, used to receive requests from the host side. Based on this queue, the requests to be replayed are retrieved from persistent memory. These requests are then resent to the target acceleration component pointing to the storage device, instructing the storage device to store the target data corresponding to the replay request in persistent memory. This method pre-stores the request queue, requests, and corresponding data in persistent memory. If the storage stack restarts, the replay requests are recovered from the DPU's persistent memory, eliminating the need for DAM and encryption / decryption techniques. This shortens the interruption time of the host-side storage data path and improves host-side data storage efficiency.

[0088] In an exemplary embodiment, step 204 includes: obtaining each target request pointed to by each element in the request queue to be replayed from persistent memory; reading the status of each target request; determining the target request with the status of initial state or processing state as the request to be replayed; the initial state is used to indicate that the target request has not been submitted to the target acceleration component pointing to the storage device, and the processing state is used to indicate that the target request has been submitted to the target acceleration component pointing to the storage device.

[0089] The request records different states, including initial state (replay init), processing state (spdk_inflight), waiting state (rx_enqueue), and completion state (vpe_finish). The queue of requests to be replayed contains N elements pointing to N target requests. Requests in the initial or processing state are identified as those to be replayed. An initial state indicates that the DPU obtained the target request from the host before the storage stack restarted, but did not submit it to the target acceleration component pointing to the storage device. A processing state indicates that the DPU submitted the target request to the target acceleration component pointing to the storage device before the storage stack restarted, but subsequent I / O processing was interrupted.

[0090] In this embodiment, by setting the status of the request, it is possible to determine which requests in the request queue need to be resent, ensuring that unfinished requests can be recovered after the storage stack restarts, thereby improving the stability and reliability of data storage.

[0091] In an exemplary embodiment, retrieving the request queue to be replayed from persistent memory includes: retrieving cursor information corresponding to each request queue from persistent memory; the cursor information includes head cursor information, tail cursor information, and middle cursor information; and determining the request queues whose head cursor information and middle cursor information are inconsistent as the request queues to be replayed.

[0092] Retrieve each target request pointed to by each element in the request queue to be replayed from persistent memory, including: retrieving at least one target element from the request queue to be replayed based on the head cursor information and middle cursor information corresponding to the request queue to be replayed; and retrieving each target request pointed to by at least one target element from persistent memory.

[0093] The head cursor information refers to the head cursor information of the request queue, the middle cursor information refers to the spdk_head cursor information of the request queue, and the tail cursor information refers to the tail cursor information of the request queue. In any request queue, all elements in the request queue are stored between the head and tail; the requests pointed to by each element between the head and spdk_head have been submitted to the vhost target. Persistent memory includes a contiguous shared memory area used to store cursor information.

[0094] If the cursor information at the head of a request queue matches the cursor information at the middle, it indicates that the request queue is empty or that all requests pointed to by elements in the request queue have been processed. If the cursor information at the head of a request queue does not match the cursor information at the middle, it indicates that the request queue contains elements that have not been processed, and the request queue is identified as a request queue to be replayed.

[0095] Based on the head cursor information and middle cursor information of the request queue to be replayed, at least one target element between head and spdk_head is obtained from the request queue to be replayed. Based on the information carried by at least one target element, the corresponding target request is obtained from persistent memory.

[0096] In one implementation, the starting address of the shared memory of the request queue and the shared memory of the cursor information is obtained through a unique shmid identifier, thereby accessing the shared memory of the request queue and the shared memory of the cursor information. The corresponding information is indexed in the shared memory of the request queue and the shared memory of the cursor information through a global qid, thereby retrieving the requests that need to be replayed from head to tail in all request queues.

[0097] In this embodiment, by storing the cursor information of the request queue in persistent memory, the loss of cursor information can be prevented, the consistency of information during data transmission can be maintained, and after the storage stack is restarted, it can quickly return to the previous state and continue to process unfinished requests, thus shortening the interruption time of the storage data path on the host side.

[0098] In an exemplary embodiment, as shown in FIG4, the persistent memory includes a data cache area and a request storage area, and the method further includes:

[0099] Step 402: Split the data cache area and the request storage area according to the set size to obtain the data segment and the request segment.

[0100] Persistent memory includes a data buffer and a request buffer. The data buffer can be understood as a shared memory area (out buffer) used to store data, and the request buffer can be understood as a shared memory area (replay request) used to store requests.

[0101] In one implementation, the out buffer stores data in the out direction, comprising multiple 2MB hugepages that are physically contiguous. Similarly, the replay request also comprises multiple physically contiguous 2MB hugepages.

[0102] Set the size to the size of each element stored in the memory pool of the Data Plane Development Kit (DPDK), for example, 4KB. Optionally, obtain the starting address of the shared memory area of ​​the out buffer and replay request using a unique shmid identifier, and cut all contiguous 2MB hugepages in the shared memory area of ​​the out buffer and replay request into 4KB segments.

[0103] Step 404: Use the data memory pool of the data plane development kit to manage the address information of the data segment.

[0104] Step 406: Use the request memory pool of the data plane development kit to manage the address information of the request segment.

[0105] The split data segments are injected into the DPDK's out buffer mempool, and the split request segments are injected into the DPDK's request mempool.

[0106] Understandably, the DPU's Vhost layer requests two idle DPDK mempools to manage replay request objects and out buffer objects, respectively. Each element in the mempool is 4KB in size, and all element information in the mempool can be linked through the replay queue.

[0107] In one implementation, the address information of the data segment is injected into the out buffer mempool, allowing access to the data segment region located in persistent memory. Similarly, the address information of the request segment is injected into the request mempool, enabling access to the request segment region located in persistent memory. Optionally, the address information can be the starting address of either the data segment or the request segment.

[0108] Step 408: During the initialization of the transmission buffer, target data segments are allocated to each element in the transmission buffer using the data memory pool, and target request segments are allocated to each element in the transmission buffer using the request memory pool.

[0109] The transfer buffer (tx ring) can be understood as a hardware queue within the DPU. During DPU hardware queue initialization, a target data segment (i.e., a small data buffer) is pre-allocated from the DPDK's data memory pool and injected into each entry of the tx ring, thus associating each element in the transfer buffer with the target data segment in the data buffer. Similarly, a target request segment (i.e., a small request storage area) is pre-allocated from the DPDK's request memory pool and injected into each entry of the tx ring, thus associating each element in the transfer buffer with the target request segment in the request storage area.

[0110] Step 410: Based on the address information of the target data segment, store the data corresponding to each element in the transmission buffer into the data buffer area.

[0111] Step 412: Based on the address information of the target request segment, store the requests corresponding to each element in the transmission buffer into the request storage area.

[0112] When the DPU reads write request data from the host side, it places the data into the data buffer associated with the tx ring and the request into the request storage area associated with the tx ring, based on the address information of the target data segment and the address information of the target request segment corresponding to each element in the pre-allocated request.

[0113] In this embodiment, by managing the split data segments and request segments through DPDK's memory pool, the use of persistent memory can be controlled and managed. Compared to requesting persistent memory on demand and obtaining address information from DPDK's memory pool, this method is faster and more efficient. Pre-allocating data storage resources and request storage resources during initialization improves the transmission performance of the IO path.

[0114] In an exemplary embodiment, after step 204, the method further includes: removing the address information of the data segment corresponding to the request to be replayed from the data memory pool; and removing the address information of the request segment corresponding to the request to be replayed from the request memory pool.

[0115] After determining the replay queue that needs to be replayed, the data memory pool and request memory pool are traversed, and the address information of the data segment and the address information of the request segment related to the request to be replayed are removed.

[0116] Understandably, since the initialization process of the transmission buffer includes the address information associated with the replay request, removing the address information of the data segment and request segment associated with the replay request prevents other normal I / O operations from obtaining the address information of the data segment and request segment associated with the replay request when requesting data resources and requesting resources from the memory pool. Since concurrent access will lead to write data anomalies, this application prevents concurrent access to the data buffer and request storage area associated with the replay request by removing the address information, thus improving the security of data transmission.

[0117] In an exemplary embodiment, after step 206, the method further includes: if a response to the request to be replayed is received, the response is placed in a receiving buffer; if it is detected that the host side has completed the operation corresponding to the response, the element corresponding to the request to be replayed is removed from the request queue to be replayed.

[0118] After SPDK processes the replay request, it returns it to BDEV. BDEV then completes the response process with the host, specifically placing the response into the VHOST internal rx ring, i.e., the receive buffer. After completing the response process with the host and detecting that the host has completed the operation corresponding to the response, the element corresponding to the replay request is removed from the replay queue. Optionally, if an update to the tail cursor information in the receive buffer is detected, it is determined that the host has completed the operation corresponding to the response. Optionally, based on the operation of removing an element from the request queue, the request and data pointed to by that element are further deleted from persistent memory.

[0119] In this embodiment, replayed requests are removed from the request queue to free up memory resources for subsequent requests, thereby improving resource utilization.

[0120] In an exemplary embodiment, the state of the request stored in persistent memory includes any one of an initial state, a processing state, a waiting state, and a completion state; the method further includes:

[0121] After storing the requests corresponding to each element in the transmission buffer into persistent memory, the state of the requests in persistent memory is set to the initial state; the initial state indicates that the request has not been submitted to the target acceleration component pointing to the storage device. After resending the request to be replayed to the target acceleration component pointing to the storage device, the state of the request to be replayed is updated to the processing state; the processing state indicates that the request has been submitted to the target acceleration component pointing to the storage device. After receiving a response to the request to be replayed, the state of the request to be replayed is updated to the waiting state; the waiting state indicates that the storage device has responded but the host has not responded. After detecting that the host has completed the operation corresponding to the response, the state of the request to be replayed is updated to the completed state; the completed state indicates that the host has responded.

[0122] Remove the element corresponding to the request to be replayed from the request queue to be replayed, including: if the request queue to be replayed also includes at least one second element located before the first element, then determine the status of the request pointed to by the at least one second element; the first element is the element corresponding to the request to be replayed; if the status of the requests pointed to by the at least one second element is the completed status, then remove the first element and at least one second element from the request queue to be replayed.

[0123] By storing the status of requests, the rollback mechanism can correctly handle requests that were not successfully added or removed from the request queue. If the SPDK process exits during the process of adding or removing requests from the request queue, and is then restarted, this rollback mechanism can correctly handle requests that were not successfully added or removed from the request queue.

[0124] In one implementation, after storing the requests corresponding to each element in the transfer buffer to persistent memory, the state of the requests in persistent memory is set to the initial state. Optionally, after successfully placing the pointers to the requests corresponding to each element in the transfer buffer into the request queue, the tx ring head cursor information of the transfer buffer is updated. If the SPDK process exits before successfully placing the request into the request queue, and is restarted, the elements between the tx ring head and tx ring tail are reread from the transfer buffer. Assuming a request's state is in the initial state, it means the DPU has obtained the request from the host side but has not submitted it to the target acceleration component pointing to the storage device.

[0125] In one implementation, after resending the request to be replayed to the target acceleration component pointing to the storage device, the status of the request to be replayed is updated to the processing status. Optionally, after successfully updating the processing status, the spdk_head cursor information of the request queue to be replayed is updated. If the SPDK process exits before updating spdk_head or before the processing status update process is completed, and the SPDK process is restarted, requests with a status of initial or processing are searched in the request queue to be replayed and resubmitted to the target acceleration component pointing to the storage device. Assuming a request is in the processing status, it means that the DPU has submitted the request to the target acceleration component pointing to the storage device, but the subsequent IO processing process has not yet been completed.

[0126] In one implementation, after receiving a response to a request to be replayed, the status of the request to be replayed is updated to a waiting state. Optionally, after receiving a response to a request to be replayed, the response is placed in a receive buffer, the tail cursor information of the receive buffer is updated, and after the tail cursor information of the receive buffer is updated, the status of the request to be replayed is updated to a waiting state. If the SPDK process exits before updating the status of the request to be replayed, after restarting the SPDK process, it searches for requests with a status of initial or processing in the request queue to be replayed, and resubmits them to the target acceleration component pointing to the storage device. Assuming that the status of a certain request is a waiting state, it means that the DPU has already submitted the request to the target acceleration component pointing to the storage device, the storage device has responded, but the host side has not responded.

[0127] In one implementation, after detecting that the host side has completed the operation corresponding to the response, the status of the request to be replayed is updated to the completed state. Optionally, after the hardware processes the response in the receive buffer, it updates the head cursor information of the receive buffer and updates the status of the request to be replayed to the completed state.

[0128] Understandably, assuming the element corresponding to the request to be replayed is located at the k-th position in the request queue to be replayed, if the requests pointed to by the first k elements in the request queue to be replayed are all in the "complete" state, then the first k elements are removed from the request queue to be replayed, and the head cursor information of the request queue to be replayed is updated so that the head cursor information points to the (k+1)-th element. Specifically, after updating the status of the request to be replayed to the "complete" state, it is determined whether there is a second element in the request queue to be replayed before the first element. If there is no second element, the first element is directly removed. If there is at least one second element, the status of the requests pointed to by the second element is determined. If the status of the requests pointed to by the second element is all in the "complete" state, then the first element and at least one second element are removed simultaneously. If the status of the requests pointed to by the second element is not all of the completed status, the element is not removed and the head cursor information of the request queue to be replayed is not updated. Instead, the system continues to search for requests with the status of initial or processing status according to the request queue to be replayed, and resubmits them to the target acceleration component pointing to the storage device, until the status of all requests pointed to by all elements in the request queue to be replayed is completed.

[0129] In this embodiment, tracking the processing progress of requests and updating the corresponding status can prevent requests from being lost or processed in a chaotic manner, thereby improving the reliability of data transmission.

[0130] In an exemplary embodiment, referring to Figure 5, which illustrates the initialization flow of a data replay method in one embodiment, four shared memory areas are reserved in advance: a shared memory area for the request queue (replay queue), a shared memory area for cursor information (replay cusor), a shared memory area for data (out buffer), and a shared memory area for requests (replay request). Two free DPDK mempools are allocated for request and out buffer, respectively, to manage replay request objects and out buffer objects.

[0131] Each element in the request queue is a pointer to a request, including the replay request addr, which points to a replay request object in the request mempool. Each request has a different status. The initialization process of the data replay method is as follows:

[0132] 1. Divide the consecutive 2MB hugepages in the out buffer area and replay request area into 4KB segments, and register them in the DPDK request mempool and out buffer mempool respectively.

[0133] 2. Based on the data in the replay queue and replay custodian areas, retrieve the requests that need to be replayed. In this way, the interrupted stored data path can be reconstructed.

[0134] 3. Traverse the DPDK request mempool and out buffer mempool, and remove all element elements related to requests that need to be replayed.

[0135] 4. Based on head, tail, and spdk_head, traverse the replay queue and resubmit any unprocessed requests to SPDK BDEV, which will then send them to the target acceleration component pointing to the storage device.

[0136] 5. If the request is processed, BDEV completes the response process with the host and removes the replay request from the replay queue.

[0137] In an exemplary embodiment, referring to Figure 6, which is a schematic diagram of the changes in the request queue in one embodiment, the processing steps for the request queue are as follows:

[0138] ① The DPU retrieves the requests [x1, x5] from the VHOST internal tx ring and sets their status to the initial state, i.e., status = replay_init. The head cursor information of the tx ring is not updated until [x1, x5] is successfully added to the replay queue. If the SPDK process exits while adding an element, after the SPDK process re-retrieves the request, it finds the request [x1, x5] between the head and tail cursors in the tx ring and repeats the addition action in step ①. In the normal process (without an SPDK process restart), the request [x1, x5] is added, the tail cursor of the replay queue is updated, and the process proceeds to step ②.

[0139] ② Retrieve the request [x1, x4] from the replay queue and submit it to the vhost target. Update the status of [x1, x4] in the replay queue to the processing status, i.e., status = spdk_inflight. After successfully updating the status of [x1, x4], update the spdk_head cursor information. If the SPDK process exits before updating the spdk_head cursor information or partially updating the processing status, after the SPDK process re-retrieves the data, it searches for the [x1, x4] request with the initial or processing status between the head and tail of the replay queue and resubmits it to the vhost target. In a normal process, after updating the spdk_head cursor information, proceed to step ③.

[0140] ③ After SPDK completes the request for [x2,x3] out of order, BDEV needs to put the response and status into the VHOST internal rx ring and update the tail cursor information of the rx ring. After successfully updating the tail cursor information of the rx ring, the status of [x2,x3] in the replay queue is updated to a waiting state, i.e., status = rx_enqueue. If the SPDK process exits before updating the status of [x2,x3], after the SPDK process re-fetches the request, it returns to step ② and resubmits [x2,x3]. In the normal process, after updating the status of [x2,x3], it proceeds to step ④.

[0141] ④ After the hardware finishes processing the data related to x2 in the VHOST internal rx ring, it notifies the software to update the status of the x2 request to a completed state, i.e., status = vpe_finish, and updates the head cursor information of the rx ring. It checks the status of the x1 request in the replay queue to determine if it is in a completed state. If the status of the x1 request is not completed, it continues to wait for the processing result of the x1 request. If the SPDK process exits before updating the head cursor information, after the SPDK process re-fetches the data, it searches for requests with an initial or processing status between the head and tail of the replay queue and resubmits them to the vhost target. In a normal process, after updating the status of x2, it proceeds to step ⑤.

[0142] ⑤ Starting from the head of the replay queue, detect consecutive completed x1 and x2 requests in the replay queue, update the cursor information of the head of the replay queue to point to the x3 element, remove x1 and x2 from the replay queue, and proceed to step ⑥.

[0143] ⑥ Repeat steps ③ to ⑤ starting from position x3 until the request for [x3, x4] is successfully removed from the replay queue.

[0144] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0145] In one exemplary embodiment, a data processor is provided, including a memory and a processor. The memory stores computer-readable instructions, and the processor, when executing the computer-readable instructions, performs the following steps: in the event of a storage stack restart, retrieving a queue of requests to be replayed from persistent memory; the queue of requests to be replayed is a queue mapped in persistent memory for a transfer buffer used to receive requests from the host side; retrieving requests to be replayed from persistent memory according to the queue of requests to be replayed; and resending the requests to be replayed to a target acceleration component pointing to a storage device to instruct the storage device to store target data corresponding to the requests to be replayed in persistent memory.

[0146] In one embodiment, when the processor executes computer-readable instructions, it further performs the following steps: retrieves each target request pointed to by each element in the request queue to be replayed from persistent memory; reads the status of each target request; and determines the target requests with the status of initial state or processing state as the requests to be replayed; the initial state is used to indicate that the target request has not been submitted to the target acceleration component pointing to the storage device, and the processing state is used to indicate that the target request has been submitted to the target acceleration component pointing to the storage device.

[0147] In one embodiment, when the processor executes computer-readable instructions, it further performs the following steps: obtaining cursor information corresponding to each request queue from persistent memory; the cursor information includes head cursor information, tail cursor information, and middle cursor information; identifying request queues whose head cursor information and middle cursor information are inconsistent as request queues to be replayed; obtaining at least one target element from the request queues to be replayed based on the head cursor information and middle cursor information corresponding to the request queues to be replayed; and obtaining each target request pointed to by at least one target element from persistent memory.

[0148] In one embodiment, when the processor executes computer-readable instructions, it further performs the following steps: splitting the data buffer and the request storage area according to a set size to obtain data segments and request segments; managing the address information of the data segments using the data memory pool of the data plane development kit; managing the address information of the request segments using the request memory pool of the data plane development kit; during the initialization of the transfer buffer, allocating target data segments to each element in the transfer buffer using the data memory pool, and allocating target request segments to each element in the transfer buffer using the request memory pool; storing the data corresponding to each element in the transfer buffer into the data buffer according to the address information of the target data segments; and storing the requests corresponding to each element in the transfer buffer into the request storage area according to the address information of the target request segments.

[0149] In one embodiment, when the processor executes computer-readable instructions, it further performs the following steps: removing the address information of the data segment corresponding to the request to be replayed from the data memory pool; and removing the address information of the request segment corresponding to the request to be replayed from the request memory pool.

[0150] In one embodiment, when the processor executes computer-readable instructions, it further performs the following steps: if a response to the request to be replayed is received, the response is placed in a receive buffer; if it is detected that the host has completed the operation corresponding to the response, the element corresponding to the request to be replayed is removed from the request queue to be replayed.

[0151] In one embodiment, when the processor executes computer-readable instructions, it further implements the following steps: after storing the requests corresponding to each element in the transfer buffer to persistent memory, setting the state of the requests in persistent memory to an initial state; the initial state is used to indicate that the request has not been submitted to the target acceleration component pointing to the storage device; after resending the request to be replayed to the target acceleration component pointing to the storage device, updating the state of the request to be replayed to a processing state; the processing state is used to indicate that the request has been submitted to the target acceleration component pointing to the storage device; after receiving a response to the request to be replayed, updating the state of the request to be replayed to a waiting state; the waiting state is used to indicate that the storage device has responded but the host has not responded; after detecting that the host has completed the operation corresponding to the response, updating the state of the request to be replayed to a completed state; the completed state is used to indicate that the host has responded; if the request queue to be replayed also includes at least one second element located before the first element, then determining the state of the request pointed to by the at least one second element; the first element is the element corresponding to the request to be replayed; if the states of the requests pointed to by the at least one second element are both completed, then removing the first element and at least one second element from the request queue to be replayed.

[0152] In one exemplary embodiment, a network interface card is provided, including a data processor as provided in any of the above embodiments and multiple interfaces, such as PCI / PCIE interfaces, network interfaces, etc., through which the data processor communicates with the outside world.

[0153] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in Figure 7. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer-readable instructions. The internal memory provides an environment for the operation of the operating system and computer-readable instructions in the non-volatile storage medium. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with external terminals via a network connection. When the computer-readable instructions are executed by the processor, they implement a data replay method.

[0154] In one exemplary embodiment, the computer device provided in this application includes a central processing unit (CPU) and a data processor as provided in any of the above embodiments. The data processor is used to schedule messages to the CPU or to process them itself, and the CPU is used to process the messages scheduled by the data processor.

[0155] For example, a central processing unit (CPU) can interact with storage devices through a data processing unit (DPU) to store and retrieve data.

[0156] Those skilled in the art will understand that the structure shown in Figure 7 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0157] In one embodiment, a computer-readable storage medium is provided having computer-readable instructions stored thereon, which, when executed by a processor, perform the following steps: in the event of a storage stack restart, retrieving a queue of requests to be replayed from persistent memory; the queue of requests to be replayed is a queue mapped in persistent memory for a transfer buffer used to receive requests from the host side; retrieving requests to be replayed from persistent memory according to the queue of requests to be replayed; and resending the requests to be replayed to a target acceleration component pointing to a storage device to instruct the storage device to store target data corresponding to the requests to be replayed in persistent memory.

[0158] In one embodiment, when the computer-readable instructions are executed by the processor, the following steps are also performed: retrieving each target request pointed to by each element in the request queue to be replayed from persistent memory; reading the status of each target request; determining the target requests with the status of initial state or processing state as the request to be replayed; the initial state is used to indicate that the target request has not been submitted to the target acceleration component pointing to the storage device, and the processing state is used to indicate that the target request has been submitted to the target acceleration component pointing to the storage device.

[0159] In one embodiment, when the computer-readable instructions are executed by the processor, the following steps are also performed: obtaining cursor information corresponding to each request queue from persistent memory; the cursor information includes head cursor information, tail cursor information, and middle cursor information; determining the request queues whose head cursor information and middle cursor information are inconsistent as request queues to be replayed; obtaining at least one target element from the request queues to be replayed according to the head cursor information and middle cursor information corresponding to the request queues to be replayed; and obtaining each target request pointed to by at least one target element from persistent memory.

[0160] In one embodiment, when the computer-readable instructions are executed by the processor, the following steps are also performed: splitting the data buffer and the request storage area according to a set size to obtain data segments and request segments; managing the address information of the data segments using the data memory pool of the data plane development kit; managing the address information of the request segments using the request memory pool of the data plane development kit; during the initialization of the transfer buffer, allocating target data segments to each element in the transfer buffer using the data memory pool, and allocating target request segments to each element in the transfer buffer using the request memory pool; storing the data corresponding to each element in the transfer buffer into the data buffer according to the address information of the target data segments; and storing the requests corresponding to each element in the transfer buffer into the request storage area according to the address information of the target request segments.

[0161] In one embodiment, when the computer-readable instructions are executed by the processor, the following steps are also performed: removing the address information of the data segment corresponding to the request to be replayed from the data memory pool; and removing the address information of the request segment corresponding to the request to be replayed from the request memory pool.

[0162] In one embodiment, when the computer-readable instructions are executed by the processor, the following steps are also performed: if a response to the request to be replayed is received, the response is placed in a receive buffer; if it is detected that the operation corresponding to the response has been completed on the host side, the element corresponding to the request to be replayed is removed from the request queue to be replayed.

[0163] In one embodiment, when the computer-readable instructions are executed by the processor, the following steps are further implemented: after storing the requests corresponding to each element in the transfer buffer to persistent memory, the state of the requests in persistent memory is set to an initial state; the initial state is used to indicate that the request has not been submitted to the target acceleration component pointing to the storage device; after resending the request to be replayed to the target acceleration component pointing to the storage device, the state of the request to be replayed is updated to a processing state; the processing state is used to indicate that the request has been submitted to the target acceleration component pointing to the storage device; after receiving a response to the request to be replayed, the state of the request to be replayed is updated to a waiting state; the waiting state is used to indicate that the storage device has responded and the host has not responded; after detecting that the host has completed the operation corresponding to the response, the state of the request to be replayed is updated to a completed state; the completed state is used to indicate that the host has responded; if the queue of requests to be replayed also includes at least one second element located before the first element, the state of the request pointed to by the at least one second element is determined; the first element is the element corresponding to the request to be replayed; if the states of the requests pointed to by the at least one second element are both completed, the first element and the at least one second element are removed from the queue of requests to be replayed.

[0164] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0165] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a non-volatile computer-readable storage medium. When executed, the computer-readable instructions can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0166] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0167] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A data replay method, wherein, The data replay method is applied to a data processor, and the method includes: In the event of a storage stack restart, a queue of requests to be replayed is retrieved from persistent memory; the queue of requests to be replayed is a queue obtained by mapping a transmission buffer in the persistent memory, the transmission buffer being used to receive requests from the host side. According to the request queue to be replayed, retrieve the requests to be replayed from the persistent memory; The request to be replayed is resent to the target acceleration component pointing to the storage device, instructing the storage device to store the target data corresponding to the request to be replayed in the persistent memory.

2. The method according to claim 1, wherein, The step of retrieving replay requests from the persistent memory according to the replay request queue includes: From the persistent memory, retrieve the target requests pointed to by each element in the request queue to be replayed; Read the status of each target request; Target requests in the initial state or the processing state are identified as requests to be replayed; the initial state is used to indicate that the target request has not been submitted to the target acceleration component pointing to the storage device, and the processing state is used to indicate that the target request has been submitted to the target acceleration component pointing to the storage device.

3. The method according to claim 2, wherein, The step of retrieving the request queue to be replayed from persistent memory includes: Obtain the cursor information corresponding to each request queue from the persistent memory; the cursor information includes the head cursor information, the tail cursor information, and the middle cursor information; The request queue whose head cursor information is inconsistent with the middle cursor information is identified as the request queue to be replayed. The step of retrieving each target request pointed to by each element in the request queue to be replayed from the persistent memory includes: Based on the head cursor information and middle cursor information corresponding to the request queue to be replayed, at least one target element is obtained from the request queue to be replayed. Retrieve each target request pointed to by the at least one target element from the persistent memory.

4. The method according to claim 1, wherein, The persistent memory includes a data cache and a request storage area, and the method further includes: The data cache area and the request storage area are split according to the set size to obtain data segments and request segments respectively; The address information of the data segment is managed using the data memory pool of the data plane development kit; The address information of the request segment is managed using the request memory pool of the data plane development kit. During the initialization of the transmission buffer, the data memory pool is used to allocate target data segments to each element in the transmission buffer, and the request memory pool is used to allocate target request segments to each element in the transmission buffer. Based on the address information of the target data segment, the data corresponding to each element in the transmission buffer is stored in the data buffer area; Based on the address information of the target request segment, the requests corresponding to each element in the transmission buffer are stored in the request storage area.

5. The method according to claim 4, wherein, After retrieving the replay requests from the persistent memory based on the replay request queue, the method further includes: Remove the address information of the data segment corresponding to the replay request from the data memory pool; Remove the address information of the request segment corresponding to the request to be replayed from the request memory pool.

6. The method according to any one of claims 1 to 5, wherein, After resending the replay request to the target acceleration component pointing to the storage device to instruct the storage device to store the target data corresponding to the replay request in the persistent memory, the method further includes: If a response is received for the request to be replayed, the response is placed in the receive buffer; If it is detected that the host has completed the operation corresponding to the response, then the element corresponding to the request to be replayed is removed from the request queue to be replayed.

7. The method according to claim 6, wherein, The request state stored in the persistent memory includes any one of the following: initial state, processing state, waiting state, and completion state; the method further includes: After storing the requests corresponding to each element in the transmission buffer into the persistent memory, the state of the requests in the persistent memory is set to an initial state; the initial state is used to indicate that the request has not been submitted to the target acceleration component pointing to the storage device; After resending the replay request to the target acceleration component pointing to the storage device, the status of the replay request is updated to a processing status; the processing status indicates that the request has been submitted to the target acceleration component pointing to the storage device. After receiving a response to the replay request, the status of the replay request is updated to a waiting state; the waiting state indicates that the storage device has responded but the host has not responded. After detecting that the host side has completed the operation corresponding to the response, the status of the request to be replayed is updated to the completed status; the completed status is used to indicate that the host side has responded. Removing the element corresponding to the request to be replayed from the request queue to be replayed includes: If the queue of requests to be replayed also includes at least one second element located before the first element, then the state of the request pointed to by the at least one second element is determined; the first element is the element corresponding to the request to be replayed. If the requests pointed to by at least one second element are both in the completed state, then the first element and the at least one second element are removed from the request queue to be replayed.

8. A data processor, comprising a memory and a processor, wherein the memory stores computer-readable instructions, When the processor executes the computer-readable instructions, it implements the steps of the method according to any one of claims 1 to 7.

9. A network interface card, wherein, It includes the data processor as described in claim 8 and multiple interfaces, through which the data processor communicates externally.

10. A computer device, wherein, It includes a central processing unit and a data processor as described in claim 8, wherein the data processor is used to schedule messages to the central processing unit or to process them itself, and the central processing unit is used to process messages scheduled by the data processor.

11. A computer-readable storage medium having stored thereon computer-readable instructions, wherein, When the computer-readable instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images