DPU-based NOF storage server system supporting adaptive scheduling

Abstract

The invention provides a DPU-based NOF storage server system supporting adaptive scheduling, and belongs to the technical field of computers. According to the system, a host end is connected with an NVMe SSD, provides a shared memory area for P2P transmission, responds to direct memory access of a DPU end, and completes command and data delivery of the SSD; the DPU end runs a user mode NOF storage service, analyzes an NOF command from the initiator end, and drives a host end SSD to complete I / O; and the initiator end establishes double I / O paths with the NOF service of the host end and the DPU end at the same time, an adaptive scheduler is integrated, and an I / O request is dynamically routed to an optimal path according to real-time load information. According to the method, protocol unloading is achieved in a software and hardware combination mode, the CPU consumption of a host is remarkably reduced, the hardware unloading performance and the software flexibility are both achieved, and characteristic optimization and rapid iteration upgrading can be conveniently conducted on the storage device.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a NOF storage service client system based on DPU that supports adaptive scheduling. Background Technology

[0002] With the significant increase in data-intensive applications in cloud computing centers, the demand for high-performance storage has also increased accordingly. Compared to traditional HDDs and SSDs using SATA interfaces, Non-Volatile Memory Express (NVMe) SSDs can provide higher throughput and lower latency. Therefore, NVMe SSDs have been widely used in data-intensive workloads such as machine learning, big data analytics, and database systems.

[0003] However, NVMe SSDs in cloud computing centers often face low utilization rates. NVMe over Fabrics (NOF), as a high-performance remote storage access protocol, can efficiently access remote NVMe devices, thus solving this low utilization problem to some extent. NOF is a protocol that extends NVMe to the network. In the NVMe-oF architecture, the storage service (target) has actual NVMe SSD disk storage resources, and the user (initiator) accesses the target through different network transport protocols (TCP / RDMA), thereby accessing the remote NVMe disk storage resources.

[0004] NOF can be further subdivided into NVMe over TCP and NVMe over RDMA based on the underlying network medium. Traditional NVMe over TCP solutions based on kernel-driven NVMe are easy to deploy but consume significant host-side CPU resources and exhibit poor I / O performance. In contrast, NVMe over RDMA solutions deployed in environments supporting RDMA consume fewer host-side CPU resources while offering superior I / O performance. However, the NOF software stack consumes substantial CPU resources on the target side. When other applications running on the host compete for CPU resources with the NOF software stack, the storage performance provided by NOF will also decrease.

[0005] To address the issue of excessive CPU resource consumption on the host side, one existing solution is to offload the NOF target from the host to emerging hardware, such as smart network interface cards (NICs) that provide NOF offloading capabilities. This solution does not consume host-side CPU resources while providing I / O performance comparable to the solutions mentioned above. However, this hardware-based offloading solution is limited by hardware resources; currently, only a very small number of smart NICs support this hardware offloading capability, making large-scale deployment difficult. Furthermore, hardware-based solutions struggle to update to new features in a timely manner, lacking flexibility. Additionally, this solution lacks optimization for quirks (non-standard behaviors of NVMe disks from different vendors), directly leading to performance degradation. Moreover, the scalability of hardware-based offloading solutions is limited by the processing capacity of the offloading hardware. Specifically, the processing capacity for offloading hardware typically runs out before data packets saturate the network bandwidth, resulting in underutilization of network bandwidth.

[0006] With the widespread deployment of Data Processing Units (DPUs) in cloud computing centers, recent research has focused on offloading storage tasks to DPUs. A DPU is a SoC-based smart network interface card (NIC) equipped with general-purpose computing and storage resources, enabling network requests to be processed promptly upon arrival at the NIC, thus efficiently handling received NOF data packets. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the present invention aims to provide a NOF storage service client system based on DPU that supports adaptive scheduling. This system offloads the NOF storage service to the general-purpose processing core of the DPU, providing a hardware and software combined offloading solution. This reduces the consumption of host CPU resources, facilitates the optimization of quirks for various storage devices, and enables the rapid addition of new storage features as well as rapid fault repair and version update iteration.

[0008] This application provides a NOF storage service client system based on DPU that supports adaptive scheduling, including: a host, a DPU, and an initiator. The host end is connected to at least one NVMe SSD to output storage resources, provides and manages a shared memory area dedicated to P2P transmission, and responds to direct memory access requests from the DPU end to complete command submission and data transfer to the NVMe SSD; wherein, the shared memory area includes a P2P data buffer and a P2P NVMe queue; The DPU is configured to run a user-space NOF storage service, receive and parse NOF commands from the initiator, and drive the NVMe SSD to complete I / O operations. The initiator is configured to simultaneously establish connections with the NOF storage service on the host side and the NOF storage service on the DPU side, forming two independent I / O paths. It integrates an adaptive scheduler to dynamically route the I / O requests of the upper-layer application to the host-side path or the DPU-side path based on the real-time load information obtained from the DPU side.

[0009] This invention implements a flexible offloading scheme through a general-purpose processing core and software, offloading the NOF storage service to the general-purpose processing core of the DPU, running in user space, avoiding kernel switching overhead, and adding support for specific storage device feature optimization and other storage features on the general-purpose processing core of the DPU; at the same time, connecting the dual storage services constructs a hybrid offloading architecture, which is different from a single hardware offloading or pure software solution, and combined with an adaptive scheduler, introduces the concept of intelligent scheduling, and collaboratively realizes a flexible offloading structure.

[0010] In one embodiment, the P2P NVMe queue includes multiple pairs of commit queues and complete queues to support concurrent I / O operations with multiple NVMe SSDs or multiple queues of a single SSD.

[0011] In one embodiment, the DPU is further configured with a load detection module, which is used to start multiple threads to poll I / O requests, obtain the load status of a single thread based on the ratio of the time each thread spends processing I / O to the total execution time, and average the load status of all threads to obtain real-time load information.

[0012] This invention introduces a load detection module to establish a zero-overhead load synchronization mechanism and clarifies load calculation based on thread monitoring, thereby achieving efficient load information synchronization without introducing any additional network overhead.

[0013] In one embodiment, the real-time load information is synchronized to the initiator by reusing the reserved fields in the NVMe Keep-Alive response message; the NVMe Keep-Alive response message is used to monitor the connection status between the initiator and the storage service to ensure the normal operation of the communication link.

[0014] In one embodiment, during the initialization of the NOF storage service client system, the device identification information of the connected NVMe SSD is obtained from the host, and feature optimization for the specific storage is performed based on the device identification information.

[0015] In one embodiment, receiving and parsing the NOF command from the initiator to drive the NVMe SSD to complete I / O operations includes: The DPU receives and parses the NOF command from the initiator, extracts the NOF command metadata, obtains the metadata through RDMA, writes the metadata to the P2P data buffer using direct memory access, reassembles the NOF command and submits it to the submission queue, polls the completion queue to obtain the completion status, and returns a response to the initiator.

[0016] In one embodiment, reconstructing a NOF command includes: parsing the NOF command to extract metadata, and filling the NOF command structure based on the metadata to obtain the reconstructed NOF command.

[0017] In one embodiment, the adaptive scheduler distinguishes between latency-sensitive and throughput-sensitive I / O requests and routes paths based on different load thresholds. For latency-sensitive I / O requests, when the real-time load on the DPU is higher than a first preset threshold, the request is routed to the host path. For throughput-sensitive I / O requests, when the real-time load on the DPU is higher than the second preset threshold, the request is routed to the host path.

[0018] This invention employs an intelligent scheduling method to achieve joint optimization scheduling based on request semantics and real-time load, thereby minimizing host-side CPU consumption while ensuring low latency and high throughput.

[0019] Furthermore, the first preset threshold is lower than the second preset threshold.

[0020] This invention also provides a NOF storage service client method based on DPU and supporting adaptive scheduling. The NOF storage service client method uses the aforementioned NOF storage service client system based on DPU and supporting adaptive scheduling, and includes the following steps: The host connects to an NVMe SSD to output storage resources, providing and managing a shared memory area dedicated to P2P transmission. The shared memory area includes a P2P data buffer and a P2P NVMe queue. In response to direct memory access requests from the DPU, it completes command submission and data transfer to the NVMe SSD. The DPU receives and parses the NOF command from the initiator to drive the NVMe SSD to complete I / O operations; On the initiator side, the NOF storage service on the host side and the NOF storage service on the DPU side are connected simultaneously to form two independent I / O paths. An adaptive scheduler is integrated to dynamically route the I / O requests of the upper-layer application to the host-side path or the DPU-side path based on the real-time load information obtained from the DPU side.

[0021] Compared with the prior art, the beneficial effects of the present invention include at least the following: (1) Regarding the problem of hardware offloading schemes, this invention does not require dedicated hardware support. It is a software and hardware combination scheme implemented on a general-purpose processing core using a general-purpose programming language. Compared with hardware offloading schemes, it is more flexible and easier to deploy on various DPUs, reducing the consumption of host CPU resources. It can also easily and quickly introduce quirks optimization for different storage devices, solving the problem that hardware offloading schemes are difficult to modify, optimize and iterate.

[0022] (2) To address the issue of limited scalability due to the processing capacity of the offloaded hardware, this solution introduces both host-side and DPU-side NOF storage services to handle user requests. When the DPU load is saturated, the host-side NOF storage service is used to process more requests, thereby effectively improving the overall processing capacity and greatly enhancing the scalability of this solution.

[0023] (3) To address the problem of head-of-line blocking for latency-sensitive I / O requests, this solution introduces both host-side and DPU-side NOF storage services to handle user requests. When the load on the DPU side exceeds the first preset threshold, latency-sensitive I / O requests are sent to the host side, thus solving the head-of-line blocking problem.

[0024] (4) To address other scalability challenges faced by the hardware offloading scheme, this scheme establishes two data paths between the initiator and the NOF service on the host and DPU sides: an offloading path and a non-offloading path. Simultaneously, a load-aware scheduler is added to the initiator, which classifies I / O requests into latency-sensitive and throughput-sensitive types and routes paths based on different load thresholds. By utilizing both the offloading and non-offloading paths, the maximum throughput performance that the system can provide is further improved, and network bandwidth resources are utilized more fully. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0026] Figure 1This is a schematic diagram of the structure of the NOF storage service client system based on DPU and supporting adaptive scheduling provided by the present invention.

[0027] Figure 2 This is a schematic diagram of the I / O operation process provided in an embodiment of the present invention. Detailed Implementation

[0028] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, exemplary embodiments will be described in detail below, examples of which are illustrated in the accompanying drawings. In the following description relating to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of methods and systems consistent with some aspects of this application as detailed in the appended claims.

[0029] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0030] The following detailed description of the specific implementation methods, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided in detail.

[0031] Terminology Explanation: DPU: Data Processing Unit, is a type of smart network interface card (NIC) with additional computing capabilities deployed in data centers. PCIe: Peripheral Component Interconnect Express, a standard for interconnecting computer peripheral components; NVMe: Non-Volatile Memory Access Express; RDMA: Remote Direct Memory Access; NOF: NVMe over Fabrics, refers to the NVMe protocol that operates across network architectures (RDMA or TCP). SSD: Solid State Drive, a high-performance storage component; P2P: PCIe Peer to Peer, refers to a communication method on a PCIe link where two devices directly transmit messages without going through the host CPU. DMA: Direct Memory Access; SPDK: The Storage Performance Development Kit. SPDK is a development framework designed specifically for high-performance user-space storage applications. It supports protocols such as NVMe and NVMe-oF, and uses a polling mechanism to bypass the kernel, improving storage access efficiency.

[0032] ASIC: Application-Specific Integrated Circuit; TCP: Transmission Control Protocol; SQ: Submission Queue; CQ: Completion Queue; CQE: Completion Queue Entry, CQ port; Head-Of-Line: Head-of-line congestion.

[0033] like Figure 1 The diagram shows the overall framework of the NOF storage service client system based on DPU and supporting adaptive scheduling designed in this invention. This scheme offloads the NOF storage service (NOF target) to the general-purpose processing core of the DPU. After the initiator establishes a connection with the NOF storage service client of the DPU using RDMA (corresponding to...), Figure 1 The DPU accesses the SSD storage resources of the host (storage service provider) connected to it by sending NOF read and write commands. The process of reading and writing SSD does not require the intervention of the host (storage service provider) CPU, thereby reducing the CPU consumption of the host (storage service provider).

[0034] Existing hardware-based offloading solutions cannot optimize quirks for individual storage devices in a timely manner. This solution, however, is a flexible hardware-software hybrid offloading approach that allows for easy addition of specific storage device optimizations and other storage feature support to the general-purpose processing core of the DPU. Furthermore, this invention is not dependent on specific hardware but runs on a general-purpose processing core. This enables rapid deployment on DPUs from different manufacturers and models, achieving a flexible offloading architecture.

[0035] Compared to the host processor, the ARM processor on the DPU side has relatively weaker performance. Therefore, to avoid performance degradation caused by operating system user / kernel mode switching, this invention considers running the NOFtarget offloading logic in the user mode of the DPU ARM processor, replacing the interrupt-based notification method in the traditional kernel driver with a polling I / O queue, thus avoiding performance loss due to frequent context switching. Furthermore, using RDMA instead of TCP as the underlying network protocol further reduces the processing burden on the DPU.

[0036] Since the DPU cannot directly read or write NVMe SSDs connected to the host, how to enable the DPU to access NVMe SSDs is the problem that this invention needs to solve. In this invention, a dedicated P2P (Peer-to-Peer) data buffer is created on the host side, and this host-side memory is used as a transition between the DPU and the NVMe SSD.

[0037] Specifically, firstly, a dedicated P2P NVMe queue and a dedicated P2P data buffer are created on the host side for each storage device (NVMe SSD). These queues and buffers are used to store NVMe commands and data submitted by the target on the DPU to the corresponding storage device (the dedicated NVMe queue is further subdivided into multiple pairs of SQs and CQs). After the P2P queues and buffers are created on the host side, the host provides the P2P-related addresses of the queues and buffers to the NOF target on the DPU. Subsequently, the NOF storage service on the DPU side can access the P2P NVMe queues and P2P data buffers located on the host side via DMA, thereby interacting with the NVMe SSD. In addition, some extra information is passed to the NOF target on the DPU side during initialization, such as the device ID and vendor ID of the storage device. The NOF target on the DPU side uses this information to perform some device-related quirks optimizations.

[0038] The specific I / O path in this solution is further illustrated by taking the writing of data from the DPU-side NOF storage service to the SSD as an example: After establishing a connection with the initiator, the DPU-side NOF target begins to process the NOF packets sent by the initiator.

[0039] The overall I / O process is as follows: Figure 2As shown, the specific steps are as follows: 1. First, the DPU-side NOF target parses the received NOF packet, extracts the metadata related to the NVMe command, and obtains the corresponding metadata using RDMA; 2. The received metadata is sent to the P2P data buffer registered during initialization via the DMA engine; 3. The NVMe command is reassembled based on the metadata related to the NVMe command, and the reassembled NVMe command is sent to the P2P NVMe SQ registered during initialization; 4. The doorbell is pressed to inform the SSD that it can retrieve the command from the corresponding queue; 5. The NVMe SSD retrieves the NVMe command from the P2P SQ and parses it; 6. The NVMe SSD retrieves the data related to this command from the P2P data buffer; 7. After the SSD completes the execution of the command, it generates a CQE and puts the CQE into the CQ; 8. The DPU-side NOF target continuously polls the P2P CQ queue until a CQE is retrieved (indicating that an I / O command is completed); 9. After retrieving the CQE from the NOF storage service on the DPU side, it returns a NOF response packet to the initiator side.

[0040] To further improve the I / O performance of the pure offloading solution while addressing potential scalability issues, this invention utilizes the NVMe multipath feature (NVMe multipath allows access to the same NVMe disk using multiple paths): A NOF target also runs on the host side. While establishing a connection with the NOF target on the DPU side (corresponding to the offloading path), the initiator also establishes an additional connection with the NOF target on the host side (corresponding to the non-offloading path). This means the initiator can access the underlying NVMe SSD through any NOF target, and can use the host side to help process additional NOF packets when the DPU is under saturation. This design significantly improves the performance of this solution and ensures that the storage performance of the initiator is not affected even under high DPU load.

[0041] To shield users at the initiator level from the differences between the two underlying paths and to optimize overall I / O performance through optimal path selection, this invention introduces a scheduler in the initiator. This scheduler selects which path to send user-initiated I / O requests to. To minimize CPU consumption on the host side, the scheduler defaults to sending all I / O requests to the DPU offload side when the DPU is idle. When the DPU is under high load, the scheduler will send some I / O requests to non-offload paths on the host side based on the characteristics of the user's I / O requests.

[0042] In this invention, the scheduler in the initiator performs scheduling based on the load information of the DPU. To enable the scheduler in the initiator to obtain the load status of the DPU, a load detection and synchronization module is designed on the DPU side. The implementation of the load detection module is based on the programming model of this invention. Multiple threads are started to poll I / O requests, and the load status of each thread is obtained by dividing the I / O processing time of each thread by the total execution time. Finally, the load status of all threads is averaged to obtain the overall average load. After completing the load detection, a certain mechanism is needed to synchronize the load information to the initiator. The load synchronization in this solution relies on the NVMe Keep-Alive command. The NVMe Keep-Alive command is used to monitor the connection status between the initiator and the target to ensure the normal operation of the communication link. The initiator periodically sends a Keep-Alive command to the target at certain time intervals, and the target needs to send a Keep-Alive response back to the initiator. The Keep-Alive response contains some unused reserved fields. This solution uses these fields to transmit the average load information calculated by the load detection module, thereby achieving efficient load information synchronization without introducing any additional network overhead.

[0043] The scheduler in this solution further subdivides user I / O requests at the initiator end into two categories based on their different characteristics: latency-sensitive I / O requests and throughput-sensitive I / O requests. Latency-sensitive I / O requests generally have shorter data lengths and strict requirements for latency performance, while throughput-sensitive I / O requests generally have longer data lengths, focus more on peak throughput, and have relatively lower requirements for latency performance. The scheduler in this solution uses different scheduling strategies for these two different types of I / O requests. Latency-sensitive I / O requests may encounter a head-of-line problem when the NOF target is under high load. That is, when there is a large I / O request at the head of the request queue, the latency response of latency-sensitive requests at the tail of the request queue will be greatly increased because the target prioritizes processing the large I / O request at the head of the queue. To avoid this head-of-line problem, the scheduler forwards requests to the non-offload path on the host (storage service side) when it detects that the load of the NOF target on the DPU side is >50%, thereby ensuring that latency-sensitive I / O requests can be processed in a timely manner. For throughput-sensitive I / O requests, in order to obtain the highest possible throughput peak and improve the scalability of this solution, the scheduler only forwards requests to the non-offload path on the host (storage service side) when it detects that the load is >90%, so as to maximize the overall processing capacity of this solution and minimize the CPU utilization of the host side under the premise of this.

[0044] Therefore, the complete framework of this solution is as follows: the initiator utilizes multipath features to establish connections simultaneously with the NOF targets on both the DPU and host sides. The load monitoring module on the NOF target located on the DPU side continuously tracks the current NOF target load and periodically synchronizes this load information to the initiator. The scheduler module on the initiator, based on the acquired load information and the characteristics of the work set running on the initiator (latency-sensitive or throughput-sensitive applications), sends I / O requests to different I / O paths, which are then processed jointly by the NOF targets on both the host and DPU sides. This design effectively balances the need for high performance with the need to minimize host CPU utilization.

[0045] Based on the same inventive concept, an embodiment of a NOF storage service client method based on DPU and supporting adaptive scheduling, wherein the NOF storage service client method uses the aforementioned NOF storage service client system based on DPU and supporting adaptive scheduling, includes the following steps: The host connects to an NVMe SSD to output storage resources, providing and managing a shared memory area dedicated to P2P transmission. The shared memory area includes a P2P data buffer and a P2P NVMe queue. In response to direct memory access requests from the DPU, it completes command submission and data transfer to the NVMe SSD. The DPU receives and parses the NOF command from the initiator to drive the NVMe SSD to complete I / O operations; On the initiator side, the NOF storage service on the host side and the NOF storage service on the DPU side are connected simultaneously to form two independent I / O paths. An adaptive scheduler is integrated to dynamically route the I / O requests of the upper-layer application to the host-side path or the DPU-side path based on the real-time load information obtained from the DPU side.

[0046] The NOF storage service client system and method based on DPU and supporting adaptive scheduling, as described above, has a series of significant advantages: 1. Regarding the issue of traditional NVMe-over-TCP and NVMe-over-RDMAtargets running on the host (storage service side) consuming a lot of host-side CPU resources, this solution does not consume any host-side CPU resources in most cases. Only under very high load conditions will the Initiator's requests be sent to the host side for processing to a moderate extent, at which time the CPU resources consumed are small.

[0047] 2. Regarding the issues with hardware offloading solutions, our solution does not require dedicated hardware support. It is an offloading solution based on a general-purpose processing core on the DPU, which is more flexible and easier to deploy on various DPUs compared to hardware offloading solutions. Furthermore, since our solution is a software solution, it can be easily and quickly optimized for different storage devices using quirks, solving the problem of difficulty in modifying, optimizing, and iterating hardware offloading solutions.

[0048] 3. To address the Head-Of-Line problem for latency-sensitive I / O requests, this solution introduces a NOF target on both the host and DPU sides to handle user requests. When the load on the DPU side exceeds 50%, latency-sensitive I / O requests are sent to the host side, thus resolving the Head-Of-Line issue.

[0049] 4. To address the limitation of scalability caused by the processing capacity of offloaded hardware, this solution introduces both host-side and DPU-side NOF targets to handle user requests. When the DPU load is saturated, the host-side NOF target is used synchronously to handle more requests, thereby effectively improving the overall processing capacity and greatly enhancing the scalability of this solution.

[0050] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit it; obviously, the accompanying drawings are only some examples or embodiments of this application, and those skilled in the art can also apply this application to other similar situations based on these drawings, without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of the content of this application.

[0051] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention. Therefore, the scope of protection of this application shall be determined by the appended claims.

Claims

1. A NOF storage service client system based on DPU and supporting adaptive scheduling, characterized in that, include: The host, DPU, and initiator sides; The host end is connected to at least one NVMe SSD to output storage resources, provides and manages a shared memory area dedicated to P2P transmission, responds to direct memory access requests from the DPU end, and completes command submission and data transfer to the NVMe SSD; wherein, the shared memory area includes a P2P data buffer and a P2P NVMe queue; The DPU is configured to run a user-space NOF storage service, receive and parse NOF commands from the initiator, and drive the NVMe SSD to complete I / O operations. The initiator is configured to establish connections simultaneously with both the NOF storage service on the host and the NOF storage service on the DPU, forming two independent I / O paths. It integrates an adaptive scheduler to dynamically route I / O requests from upper-layer applications to either the host path or the DPU path based on real-time load information obtained from the DPU.

2. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 1, characterized in that, The P2P NVMe queue includes multiple pairs of commit queues and complete queues to support concurrent I / O operations with multiple NVMe SSDs or multiple queues of a single SSD.

3. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 1, characterized in that, The DPU is further configured with a load detection module, which is used to start multiple threads to poll I / O requests, obtain the load of a single thread based on the ratio of the time each thread spends processing I / O to the total execution time, and average the load of all threads to obtain real-time load information.

4. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 3, characterized in that, The real-time load information is synchronized to the initiator by reusing the reserved fields in the NVMe Keep-Alive response message; the NVMe Keep-Alive response message is used to monitor the connection status between the initiator and the storage service to ensure the normal operation of the communication link.

5. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 1, characterized in that, During the initialization of the NOF storage service client system, the device identification information of the connected NVMe SSD is obtained from the host, and feature optimizations for the specific storage are performed based on the device identification information.

6. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 2, characterized in that, The process of receiving and parsing the NOF command from the initiator to drive the NVMe SSD to complete I / O operations includes: The DPU receives and parses the NOF command from the initiator, extracts the metadata from the NOF command, writes the metadata to the P2P data buffer using direct memory access, reassembles the NVMe command and submits it to the submission queue, polls the completion queue to obtain the completion status, and returns a response to the initiator.

7. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 6, characterized in that, Reconstructing NVMe commands includes: parsing the header and structure of the NOF command to extract metadata, and filling the NVMe command structure based on the metadata to obtain the reconstructed NVMe command.

8. The NOF storage service client system based on DPU and supporting adaptive scheduling according to claim 1, characterized in that, The adaptive scheduler categorizes I / O requests into latency-sensitive and throughput-sensitive types and routes them based on different load thresholds. For latency-sensitive I / O requests, when the real-time load on the DPU is higher than a first preset threshold, the request is routed to the host path. For throughput-sensitive I / O requests, when the real-time load on the DPU exceeds the second preset threshold, the request is routed to the host path. The first preset threshold is lower than the second preset threshold.

9. A NOF storage service client method based on DPU supporting adaptive scheduling, characterized in that, The NOF storage service client method uses the DPU-based NOF storage service client system with adaptive scheduling as described in any one of claims 1-8, and includes the following steps: The host connects to an NVMe SSD to output storage resources, providing and managing a shared memory area dedicated to P2P transmission. The shared memory area includes a P2P data buffer and a P2P NVMe queue. In response to direct memory access requests from the DPU, it completes command submission and data transfer to the NVMe SSD. The DPU receives and parses the NOF command from the initiator to drive the NVMe SSD to complete I / O operations; On the initiator side, connections are established simultaneously with the NOF storage service on the host side and the NOF storage service on the DPU side, forming two independent I / O paths. An adaptive scheduler is integrated to dynamically route the I / O requests of the upper-layer application to the host-side path or the DPU-side path based on the real-time load information obtained from the DPU side.

Images