Data storage method, apparatus, NVM subsystem and host

Abstract

A data storage method, comprising: an NVM subsystem (120) receives a request message sent by a host (110), the request message being used for requesting the NVM subsystem (120) to receive, by means of a second port, service data sent by the host (110) by means of a first port, the request message comprising a communication parameter of the first port; and when the communication parameter of the first port is inconsistent with a communication parameter of a downlink device port, the NVM subsystem (120) sends a first response message to the host (110), the downlink device port comprising a second port, and the first response message indicating that the NVM subsystem (120) refuses to receive the service data by means of the second port. When the host (110) communicates with the NVM subsystem (120) by means of the NVMe over Fabric, the method avoids service instability caused by inconsistency of the communication parameter of the host (110) and the communication parameter of the NVM subsystem (120).

Description

Data storage method, device, NVM subsystem and host

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 1, 2023, with application number 202311445022.4 and application name “Data Storage Method, Device, NVM Subsystem and Host”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of storage technology, and in particular to a data storage method, device, NVM subsystem, and host. Background Art

[0003] Non-volatile memory express (NVMe) is an interface bus specification for communication between a host and a non-volatile memory (NVM) subsystem. NVMe is a high-speed specification that enables high-performance host access to NVM subsystems. NVMe over Fabric (NVMe over Fabric) over a switching network enables high-performance remote host access to NVM subsystems.

[0004] Due to configuration errors, configuration file errors, or insufficient configuration personnel experience, the host's communication parameters may be inconsistent with the NVM subsystem's communication parameters. When the host and NVM subsystem transmit service data using NVMe over Fabric, if these parameters are inconsistent, network performance may degrade, leading to unstable host services.

[0005] Summary of the Invention

[0006] Provided are a data storage method and device, an NVM subsystem, and a host, which can prevent business instability caused by inconsistency between communication parameters of the host and communication parameters of the NVM subsystem.

[0007] In a first aspect, a data storage method is provided, which is applied to a non-volatile memory NVM subsystem that communicates with a host through NVMe over Fabric, wherein the host has a first port and the NVM subsystem has a second port; the method includes: the NVM subsystem receives a request message sent by the host, the request message is used to request the NVM subsystem to receive business data sent by the host through the first port through the second port, wherein the request message includes communication parameters of the first port; when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the NVM subsystem sends a first response message to the host, the downstream device port includes the second port, and the first response message indicates that the NVM subsystem refuses to receive business data through the second port.

[0008] NVMe over Fabric enables the host to remotely access the NVM subsystem with high performance. High-performance remote access relies on the consistency of communication parameters between the host and the NVM subsystem. In other words, if the host's communication parameters are consistent with the NVM subsystem's communication parameters, NVMe over Fabric enables the host to remotely access the NVM subsystem with high performance. If the host's communication parameters are inconsistent with the NVM subsystem's communication parameters, the network performance of the host accessing the NVM subsystem through NVMe over Fabric will degrade, resulting in unstable host services. Configuration errors (configuration operation errors, configuration file errors, inexperienced configuration personnel, etc.), as well as configuration changes of the host or NVM subsystem during operation, may cause the host's communication parameters to be inconsistent with the NVM subsystem's communication parameters.

[0009] In related technologies, when a host needs to store service data to an NVM subsystem, the consistency of the host's communication parameters and the NVM subsystem's communication parameters is not considered. In other words, in related technologies, when the host and NVM subsystem initiate service data transmission based on NVMe over Fabric, they are unaware of whether their communication parameters are consistent, or they ignore any inconsistencies between the host and NVM subsystem. Therefore, in related technologies, regardless of whether the host's communication parameters and the NVM subsystem's communication parameters are consistent, the host sends service data to the NVM subsystem via NVMe over Fabric. This can easily lead to service instability caused by the inconsistency between the host's communication parameters and the NVM subsystem's communication parameters.

[0010] In the data storage method provided in an embodiment of the present application, when the host starts to run a service that needs to store service data in the NVM subsystem, the host sends a request message to the NVM subsystem. The request message includes the communication parameters of the first port used by the host to send service data, and the request message indicates the downstream device port through which the host sends service data to the NVM subsystem. For example, the request message indicates the second port used by the NVM subsystem to receive service data sent by the host. In this way, when the NVM subsystem receives the request message, it can obtain the communication parameters of the first port based on the request message and determine whether the communication parameters of the first port are consistent with the communication parameters of the downstream device port. For example, the communication parameters of the second port can be obtained based on the request message and determine whether the communication parameters of the first port are consistent with the communication parameters of the second port.

[0011] If the NVM subsystem confirms that the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the NVM subsystem can send a rejection message (i.e., a first response message) to the host to notify the host that the NVM subsystem refuses to receive service data through the second port. In this way, if the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the host will no longer send service data to the NVM subsystem through the first port using NVMe over Fabric, thereby preventing service instability caused by the inconsistency between the communication parameters of the host and the communication parameters of the NVM subsystem.

[0012] Furthermore, through the rejection message, the host can perceive that the communication parameters of the sending port used by the host to send business data are inconsistent with the communication parameters of the downstream device port, thereby triggering the host to take measures or other communication methods to ensure the consistency of the communication parameters, so as to ensure the stability of the business while the business is carried out. For example, the rejection message can trigger the host to provide prompt information, which prompts the user to reconfigure the communication parameters of the first port and / or the downstream device port so that the communication parameters of the first port are consistent with the communication parameters of the downstream device port. For another example, the rejection message can trigger the host to try to send business data through a port other than the first port, or request the NVM subsystem to receive business data through a port other than the second port. For another example, the rejection message can trigger the host to adopt a communication method other than NVMe over Fabric that is not affected by inconsistent communication parameters to send business data to the NVM subsystem. And so on.

[0013] In short, the data storage method provided in the embodiments of the present application enables the host to detect whether service data transmission between the host and the NVM subsystem via the first port and the second port can ensure service stability, even when the host and the NVM subsystem communicate using NVMe over Fabric. This prevents service data from being transmitted via the first port and the second port when service data transmission between the host and the NVM subsystem via the first port and the second port cannot ensure service stability, thereby preventing service instability.

[0014] In one possible implementation, the method further includes: when the communication parameters of the first port are consistent with the communication parameters of the downstream device port, the NVM subsystem sends a second response message to the host, where the second response message indicates that the NVM subsystem agrees to receive service data through the second port.

[0015] In this implementation, when the NVM subsystem confirms that the communication parameters of the first port are consistent with the communication parameters of the downstream device port, the NVM subsystem can send an approval message (i.e., a second response message) to the host to notify the host that the NVM subsystem agrees to receive business data through the second port. In this way, the host can use NVMe over Fabric to send business data to the NVM subsystem through the first port, and the NVM subsystem receives and stores the business data through the second port. The consistency of the communication parameters of the first port and the second port allows the performance of NVMe over Fabric to be fully utilized, thereby ensuring high-speed and stable transmission of business data, thereby allowing the business to proceed stably.

[0016] In one possible implementation, the request message includes an update indication, and the method further includes: when the communication parameters of the first port and the communication parameters of the second port are inconsistent, the NVM subsystem responds to the update indication and updates the communication parameters of the second port so that the communication parameters of the second port are consistent with the communication parameters of the first port.

[0017] In this implementation, an update indication can be configured in the request message. This update indication is used to instruct the NVM subsystem to update the communication parameters of the receiving port when the service data sending port and the service data receiving port are inconsistent. Thus, when the NVM subsystem confirms that the first port (i.e., the service data sending port) and the second port (i.e., the service data receiving port) are inconsistent, it can respond to the update indication and actively update the communication parameters of the second port, so that the communication parameters of the first port and the communication parameters of the second port are consistent, thereby allowing the host and the NVM subsystem to transmit service data through the first port and the second port, and ensuring the stability of the service.

[0018] In a possible implementation, an intermediate node is included between the host and the NVM subsystem, and the downstream device port further includes a third port, which is used by the intermediate node to forward data sent from the first port to the second port.

[0019] In this implementation, when data sent from a first port to a second port requires forwarding by an intermediate node, the NVM subsystem also determines whether the communication parameters used for the first port are consistent with the communication parameters of a third port used by the intermediate node to forward data. If they are inconsistent, the NVM subsystem refuses to receive the service data sent from the first port through the second port. This prevents service instability caused by inconsistencies between the communication parameters of the port sending service data and the port forwarding service data.

[0020] In one possible implementation, the method also includes: when the request message includes a mark, the NVN subsystem confirms that the communication parameters of the first port and the communication parameters of the downstream device port are inconsistent; wherein, the mark is added to the request message by the intermediate node when the communication parameters of the first port and the communication parameters of the third port are inconsistent.

[0021] In this implementation, the intermediate node can obtain the communication parameters of the first port and the communication parameters of the third port from the request message, and determine whether the communication parameters of the first port and the communication parameters of the third port are consistent. If it is determined that the communication parameters of the first port and the communication parameters of the third port are inconsistent, the intermediate node adds a flag to the request message, so that the NVM subsystem can determine whether the communication parameters of the first port and the communication parameters of the third port are consistent by determining whether the received request message includes the flag.

[0022] In a possible implementation, NVMe over Fabric is NVMe over RoCE, and the request message is an RDMA_IP_CM message, wherein the communication parameters of the first port are recorded in a reserved byte in the RDMA_IP_CM message.

[0023] In this implementation, the method can be applied to NVMe over RoCE to ensure business stability when the host communicates with the NVM subsystem through NVMe over RoCE. Specifically, NVMe over RoCE uses Ethernet to carry the NVMe protocol, and the communication parameters may include communication parameters used in lossless Ethernet construction technology, such as PFC priority. The communication parameters of the first port are consistent with the communication parameters of the downstream device port, which can ensure the construction of lossless Ethernet. The communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, which makes it difficult to build a lossless Ethernet, making the network performance of NVMe over RoCE fall short of expectations, resulting in business instability. In this implementation, when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the NVM subsystem refuses to receive business data sent by the host through the first port, thereby preventing business instability.

[0024] In addition, in this implementation, by extending the reserved bytes in the RDMA_IP_CM message, a request message for the communication parameters of the sending port (e.g., the first port) carrying the business data is obtained, thereby enabling the communication parameters of the sending port to be sent to the NVM subsystem without designing a new message.

[0025] In a possible implementation, the communication parameter includes at least one of a priority based on priority flow control (PFC) and a maximum transmission unit (MTU).

[0026] The PFC priority represents the virtual channel used for data transmission. When congestion occurs, data transmission on the corresponding virtual channel can be suspended according to the PFC priority. The communication parameters of the first port and the downstream device port are consistent, including the PFC priority of the first port and the downstream device port. In this way, when congestion occurs, the first port and the downstream device port can perform flow control on the same virtual channel, ensuring network performance.

[0027] MTU refers to the maximum data frame size. The communication parameters of the first port and the downstream device port are consistent, including the MTU of the first port being less than or equal to the MTU of the downstream device port. This allows the downstream device port's data frame buffer to cache data frames sent from the first port, ensuring that the downstream device can receive service data normally, thereby maintaining network performance.

[0028] In a second aspect, a data storage method is provided, which is applied to a host communicating with an NVM subsystem through NVMe over Fabric, the host having a first port and the NVM subsystem having a second port; the method includes: the host sending a request message to the NVM subsystem, the request message being used to request the NVM subsystem to receive business data sent by the host through the first port through the second port, wherein the request message includes communication parameters of the first port; the host receives a first response message sent by the NVM subsystem, the first response message indicating that the NVM subsystem refuses to receive business data through the second port; wherein the first response message is sent by the NVM subsystem when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, and the downstream device port includes the second port.

[0029] In one possible implementation, the method further includes: the host receiving a second response message sent by the NVM subsystem, the second response message indicating that the NVM subsystem agrees to receive service data through the second port; wherein the second response message is sent by the NVM subsystem when the communication parameters of the first port are consistent with the communication parameters of the downstream device port.

[0030] In one possible implementation, the request message includes an update indication; wherein, when the communication parameters of the first port and the communication parameters of the second port are inconsistent, the NVM subsystem is used to respond to the update indication and update the communication parameters of the second port based on the communication parameters of the first port so that the communication parameters of the second port are consistent with the communication parameters of the first port.

[0031] In a possible implementation, an intermediate node is included between the host and the NVM subsystem, the downstream device port includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

[0032] In a possible implementation, NVMe over Fabric is NVMe over RoCE, and the request message is an RDMA_IP_CM message, wherein the communication parameters of the first port are recorded in a reserved byte in the RDMA_IP_CM message.

[0033] In a possible implementation, the communication parameter includes at least one of a priority based on priority flow control (PFC) and a maximum transmission unit (MTU).

[0034] According to a third aspect, a data storage device is provided, which is configured in a non-volatile memory NVM subsystem that communicates with a host through NVMe over Fabric, wherein the host has a first port and the NVM subsystem has a second port; the device includes: a receiving unit for receiving a request message sent by the host, the request message being used to request the NVM subsystem to receive business data sent by the host through the first port through the second port, wherein the request message includes communication parameters of the first port; a sending unit for sending a first response message to the host when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the downstream device port including the second port, and the first response message indicating that the NVM subsystem refuses to receive business data through the second port.

[0035] In one possible implementation, the sending unit is further configured to: when the communication parameters of the first port are consistent with the communication parameters of the downstream device port, the NVM subsystem sends a second response message to the host, where the second response message indicates that the NVM subsystem agrees to receive service data through the second port.

[0036] In one possible implementation, the request message includes an update indication, and the device further includes: an update unit, configured to respond to the update indication and update the communication parameters of the second port when the communication parameters of the first port are inconsistent with the communication parameters of the second port, so that the communication parameters of the second port are consistent with the communication parameters of the first port.

[0037] In a possible implementation, an intermediate node is included between the host and the NVM subsystem, and the downstream device port further includes a third port, which is used by the intermediate node to forward data sent from the first port to the second port.

[0038] In one possible implementation, the device also includes: a confirmation unit, used to confirm that the communication parameters of the first port and the communication parameters of the downstream device port are inconsistent when the request message includes a mark; wherein the mark is added to the request message by the intermediate node when the communication parameters of the first port and the communication parameters of the third port are inconsistent.

[0039] In a fourth aspect, a data storage device is provided, which is configured on a host that communicates with an NVM subsystem through NVMe over Fabric, the host having a first port and the NVM subsystem having a second port; the device includes: a sending unit, used to send a request message to the NVM subsystem, the request message being used to request the NVM subsystem to receive business data sent by the host through the first port through the second port, wherein the request message includes communication parameters of the first port; a receiving unit, used to receive a first response message sent by the NVM subsystem, the first response message indicating that the NVM subsystem refuses to receive business data through the second port; wherein the first response message is sent by the NVM subsystem when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, and the downstream device port includes the second port.

[0040] In one possible implementation, the receiving unit is further used to: receive a second response message sent by the NVM subsystem, where the second response message indicates that the NVM subsystem agrees to receive business data through the second port; wherein the second response message is sent by the NVM subsystem when the communication parameters of the first port are consistent with the communication parameters of the downstream device port.

[0041] In one possible implementation, the request message includes an update indication; wherein, when the communication parameters of the first port and the communication parameters of the second port are inconsistent, the NVM subsystem is used to respond to the update indication and update the communication parameters of the second port based on the communication parameters of the first port so that the communication parameters of the second port are consistent with the communication parameters of the first port.

[0042] In a possible implementation, an intermediate node is included between the host and the NVM subsystem, the downstream device port includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

[0043] In a fifth aspect, an NVM subsystem is provided, comprising: a second port; a memory for storing an executable program; and a controller for executing the method provided in the first aspect by running the executable program.

[0044] In a sixth aspect, a host is provided, comprising: a first port; a memory for storing an executable program; and a processor for executing the method provided in the second aspect by running the executable program.

[0045] In a seventh aspect, a computer-readable storage medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device, the computing device executes the method provided in the first aspect.

[0046] In an eighth aspect, a computer-readable storage medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device, the computing device executes the method provided in the second aspect.

[0047] In a ninth aspect, a computer program product comprising instructions is provided, which, when executed by a computing device, causes the computing device to execute the method provided in the first aspect.

[0048] In a tenth aspect, a computer program product comprising instructions is provided, which, when executed by a computing device, causes the computing device to execute the method provided in the second aspect.

[0049] In the eleventh aspect, a storage system is provided, comprising a host and an NVM subsystem that communicates with the host through NVMe over Fabric; the host has a first port and the NVM subsystem has a second port; wherein the host is used to send a request message to the NVM subsystem, the request message being used to request the NVM subsystem to receive business data sent by the host through the first port through the second port, wherein the request message includes communication parameters of the first port; the NVM subsystem is used to send a first response message to the host when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the downstream device port including the second port, and the first response message indicating that the NVM subsystem refuses to receive business data through the second port.

[0050] The beneficial effects of the second to eleventh aspects can be referred to the above introduction to the beneficial effects of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] FIG1 is a schematic diagram of the structure of a storage system provided in an embodiment of the present application;

[0052] FIG2 is a flow chart of a data storage method provided in an embodiment of the present application;

[0053] FIG3 is a schematic diagram of a message format provided in an embodiment of the present application;

[0054] FIG4 is a schematic diagram of a message format provided in an embodiment of the present application;

[0055] FIG5 is a schematic diagram of a message format provided in an embodiment of the present application;

[0056] FIG6 is a schematic structural diagram of a data storage device provided in an embodiment of the present application;

[0057] FIG7 is a schematic structural diagram of a data storage device provided in an embodiment of the present application;

[0058] FIG8 is a schematic structural diagram of an NVM subsystem provided in an embodiment of the present application;

[0059] FIG9 is a schematic structural diagram of a host provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] The following describes the solutions provided by the embodiments of the present application in conjunction with the accompanying drawings. In the embodiments of the present application, "plurality" refers to two or more than two. "First," "second," and the like are merely used to distinguish similar objects and are not necessarily used to describe a specific order or number of objects.

[0061] To facilitate understanding of the solutions provided in the embodiments of the present application, before introducing the solutions provided in the embodiments of the present application, some technical terms that may be involved in the embodiments of the present application are first introduced.

[0062] NVMe over Fabric: A technology that uses a fabric to carry the NVMe protocol, enabling high-performance (e.g., high throughput, low latency) remote host access to the NVM subsystem. The fabric can be InfiniBand (IB), Ethernet, or Fibre Channel (FC).

[0063] Internet wide-area RDMA protocol (iWARP): An Ethernet protocol used by NVMe over Fabric technology to carry the NVMe protocol.

[0064] RDMA over converged Ethernet (RoCE): Another Ethernet used by NVMe over Fabric technology to carry the NVMe protocol.

[0065] NVMe over RoCE: NVMe over Fabric technology that uses RoCE to carry the NVMe protocol.

[0066] NVM subsystem: A system that provides data storage services to a host. It includes one or more controllers, one or more storage media, and one or more ports. The storage media can be packaged in one or more memory chips. The memory chips can be flash memory chips, dynamic random access memory (DRAM), and so on. The ports receive data, and the controller stores the data received by the ports in the storage media.

[0067] Because NVMe enables high-performance remote host access to NVM subsystems, an increasing number of hosts are communicating with NVM subsystems via NVMe over Fabric to store business data. The performance of NVMe over Fabric communication depends on the consistency of communication parameters between the two ends. NVMe over Fabric can only achieve its full performance when these parameters are consistent. Inconsistent communication parameters can lead to decreased network performance, such as increased packet loss and latency. In particular, NVMe over RoCE uses Ethernet to carry the NVMe protocol. Ethernet is lossy. When congestion occurs on an Ethernet network, transmitted packets are discarded, severely degrading network performance. To address this, the industry has proposed technologies such as priority-based flow control (PFC) and explicit congestion notification (ECN) to build lossless Ethernet networks. However, PFC and other lossless Ethernet technologies rely on consistent communication parameters between the two ends of the Ethernet network to achieve their intended effect.

[0068] Due to incorrect configuration of communication parameters, errors in configuration files, and insufficient experience or capabilities of configuration personnel, the communication parameters of the host and the NVM subsystem may be inconsistent. As a result, when the host communicates with the NVM subsystem through NVMe over Fabric, network performance degrades, leading to business instability.

[0069] An embodiment of the present application provides a data storage method. When the host needs to store business data in the NVM subsystem, the host can send a request message to the NVM subsystem, and the request message includes the communication parameters of the sending port for the host to send business data, and the request message is used to request the NVM subsystem to receive the business data sent by the host through the sending port through the receiving port. When the NVM subsystem receives the request message, it can determine whether the communication parameters of the receiving port and the communication parameters of the sending port are consistent. If they are inconsistent, the NVM subsystem refuses to receive the business data sent by the host through the sending port through the receiving port. In this way, it can prevent the host from still sending business data to the NVM subsystem through NVMe over Fabric when the communication parameters of the port for sending business data and the communication parameters of the port for receiving business data are inconsistent, thereby avoiding business instability.

[0070] Next, the data storage method provided in the embodiment of the present application is described.

[0071] Figure 1 illustrates a storage system 100 that can implement a data storage method. As shown in Figure 1 , storage system 100 includes a host 110 and an NVM subsystem 120. Storage system 100 is based on the NVMe over Fabric architecture. Host 110, also known as an NVMe host, supports the NVMe protocol and can communicate with NVM subsystem 120 via NVMe over Fabric.

[0072] Host 110 can run services and store data generated by these services in NVM subsystem 120. The data generated by these services can be referred to as service data. Host 110 can be any device, equipment, platform, or cluster with data processing and communication capabilities, such as a server, virtual machine (VM), or container.

[0073] As shown in Figure 1, the host 110 may include a processor 111 and at least one port, such as port A1. The processor 111 may control port A1 to send data to the NVM subsystem 120 in accordance with the relevant protocols or specifications of NVMe over Fabric. Exemplarily, the processor 111 may control port A1 by executing an NVMe-driven program, so that port A1 sends data to the NVM subsystem 120 in accordance with the relevant protocols or specifications of NVMe over Fabric. The data sent may be business data or signaling data. Signaling data refers to data used for communication negotiation or management between the host and the NVM subsystem, such as request messages, response messages, etc.

[0074] The NVM subsystem 120 can provide data storage services for the host 110. As shown in Figure 1, the NVM subsystem 120 may include: at least one controller such as a controller 121, at least one storage medium such as a storage medium 122, and at least one port such as a port A2. In some embodiments, the NVM subsystem 120 may adopt a distributed architecture, wherein the controller 121 and the storage medium 122 may be located locally on the port A2 or remotely on the port A2. In some embodiments, the NVM subsystem may be an independent NVMe storage device or a storage array composed of multiple NVMe storage devices. When the NVM subsystem is a storage array composed of multiple storage devices, the storage array may adopt a distributed architecture, that is, some storage devices are located locally on the port A2, and some storage devices are located remotely on the port A2. In some embodiments, the NVMe storage device may be an NVMe solid state disk (SSD).

[0075] Port A2 can receive data according to the relevant protocols or specifications of NVMe over Fabric and send the received data to the controller 121. If the data is business data, the controller 121 can store the business data in the storage medium 122. If the data is signaling data, the controller 121 can parse the signaling data and perform corresponding processing in response to the signaling data.

[0076] In some embodiments, the storage system 110 further includes an intermediate node 130 disposed between the host 110 and the NVM subsystem 120. Specifically, the intermediate node 130 is located on the network path between the host 110 and the NVM subsystem 120. The intermediate node 130 is used to forward data sent from the host 110 to the NVM subsystem 120, and to forward data sent from the NVM subsystem 120 to the host 110. More specifically, as shown in FIG1 , the intermediate node 130 includes a port A3 and a processor 131. Under the control of the processor 131, port A3 can receive data sent from port A1 and send the data to port A2 in accordance with the relevant protocols or specifications of NVMe over Fabric. Exemplarily, the intermediate node 130 can be a switch. The intermediate node 130 can be a physical switch or a virtual switch.

[0077] In some embodiments, the ports (e.g., port A1, port A2, or port A3) may be network cards, such as remote direct data access network interface cards (RDMA network interface cards, RNICs). In some embodiments, the ports may be logical ports in the network card. In some embodiments, the ports may be transport layer ports, i.e., the ports may transmit data according to a transport layer protocol.

[0078] In some embodiments, the above-mentioned processor (for example, processor 111, processor 131) can be any one of a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), a field programmable gate array (FPGA), etc.

[0079] In addition, in the scenario where the host 110 sends business data to the NVM subsystem 120, the NVM subsystem 120 is a downstream device. If the storage system 100 also includes an intermediate node 130, the intermediate node 130 is also a downstream device. Therefore, in the following description, when the NVM subsystem 120 and the intermediate node 130 are not distinguished, they can be simply referred to as downstream devices. That is, in the embodiment of the present application, the downstream device refers to the NVM subsystem 120, and can also refer to the intermediate node 130, or can also refer to the NVM subsystem 120 and the intermediate node 130 at the same time. Accordingly, when no special distinction is made between port A2 and port A3, they can be simply referred to as downstream device ports.

[0080] The above examples introduce the storage system 100 provided in the embodiment of the present application. Next, the process of the data storage method provided in the embodiment of the present application is introduced in conjunction with the storage system 100.

[0081] In step 201, the host 110 may select a port for sending service data and a port for receiving service data. The port for sending service data is a port of the host 110, also known as a source port, specifically a port used by the host 110 to send service data. The port for receiving service data is a port of the NVM subsystem 120, also known as a destination port, specifically a port used by the NVM subsystem 120 to receive service data sent by the host 110. Generally speaking, when the host 110 runs a service, it is necessary to store service data in the NVM subsystem 120. Therefore, when the host 110 starts a service, step 201 and the subsequent steps described below may be executed. The host 110 may run one or more services, and each time the host 110 starts a service, step 201 and the subsequent steps described below may be executed.

[0082] As shown in FIG. 2 , it can be configured that, in step 201, the host 110 selects port A1 as the port for sending service data. When port A1 is the only port on the host 110, port A1 is selected by default as the port for sending service data. When the host 110 has multiple ports, port A1 can be randomly selected by the host 110 from the multiple ports, or can be selected by the host 110 based on a preset rule (e.g., prioritizing ports with low usage or ports with high bandwidth).

[0083] When the host 110 selects port A1 as the port for sending business data, the host 110 can obtain the communication parameters of port A1. The communication parameters of the port can also be called network configuration parameters, which are parameters used to regulate or control the behavior of the port in sending or receiving data. For example, the communication parameter can be the priority of the PFC. Among them, the priority of the PFC represents the virtual channel used for data transmission. When congestion occurs, the data transmission on the corresponding virtual channel can be suspended according to the priority of the PFC. For another example, the communication parameter can be the maximum transmission unit (MTU). MTU refers to the size of the maximum data frame. Through the MTU, the size of the data frame sent or received by the port can be regulated. The communication parameters of the port can also be other parameters, which are not listed here one by one.

[0084] Continuing with FIG. 2 , it can be assumed that in step 201, host 110 selects port A2 as the receiving port for service data. Host 110 can select a receiving port for service data from the ports of NVM subsystem 120 and request NVM subsystem 120 to receive service data sent by host 110 through the receiving port selected by host 110.

[0085] In some embodiments, as described above, the storage system 100 is an NVMe over Fabric architecture, and the NVMe over Fabric architecture has a routing server. The routing server stores the routing information of the NVM subsystem. The routing information of the NVM subsystem includes at least one port identifier (port ID) of the NVM subsystem. The at least one port identifier corresponds one-to-one to at least one port of the NVM subsystem. In step 201, the host 110 can obtain the routing information of the NVM subsystem 120 from the routing server, and obtain at least one port identifier of the NVM subsystem 1210 from the routing information of the NVM subsystem 120. Then, the host 110 can select the port identifier of port A2 from the at least one port identifier to select port A2 as the receiving port for business data.

[0086] Continuing with FIG. 2 , after selecting the port for sending and receiving service data, host 110 may, in step 202, send a request message C1 to NVM subsystem 120. Request message C1 is used to request NVM subsystem 120 to receive, via port A2, service data sent by host 111 via port A1. Request message C1, also referred to as a connection request, is used to request NVM subsystem 120 to agree to establish a link between port A1 and port A2 for transmitting service data between ports A1 and A2.

[0087] The request message C1 includes the port identifier of port A2. That is, the host 110 may add the port identifier of the receiving port selected in step 201 to the request message C1, so that the NVM subsystem 120 recognizes the receiving port as port A2 when receiving the request message C1.

[0088] The request message C1 includes the communication parameters of port A1. That is, the host 110 may add the communication parameters of port A1 obtained in step 201 to the request message C1, so that the NVM subsystem 120 can determine whether the communication parameters of port A1 and port A2 are consistent when receiving the request message C1.

[0089] In some embodiments, the request message C1 also includes an update indication. The update indication, also known as a consistency configuration indication, is used to instruct the downstream device to update the communication parameters of the downstream device port based on the communication parameters of port A1 when the communication parameters of the downstream device port are inconsistent with the communication parameters of port A1. The updated communication parameters of the downstream device port are consistent with the communication parameters of port A1.

[0090] In some embodiments, the request message C1 further includes a verification instruction, which is also called a consistency verification instruction and is used to instruct the downstream device to detect whether the communication parameters of the downstream device port are consistent with the communication parameters of port A1.

[0091] In some embodiments, the NVMe over Fabric used for communication between the host 110 and the NVM subsystem 120 is NVMe over RoCE. The relevant protocols or specifications of NVMe over RoCE define the RDMA internet protocol connection management (RDMA internet protocol connection management, RDMA_IP_CM) service and the RDMA_IP_CM message. In this embodiment, the reserved byte in the RDMA_IP_CM message can be expanded to obtain the request message C1. That is, the request message C1 belongs to the RDMA_IP_CM message, wherein the reserved byte of the RDMA_IP_CM message carries the communication parameters of port A1, that is, the communication parameters of port A1 are recorded in the reserved bytes of the RDMA_IP_CM message. Exemplarily, the RDMA_IP_CM message includes a connection management request (CM REQ) message, and the request message C1 can be obtained by expanding the reserved bytes of the connection management request message. The specific description is as follows.

[0092] NVMe over RoCE-related protocols or specifications include the NVMe RDMA transport layer specification (NVM-Express-RDMA-transport specification) and the InfiniBand protocol. The NVMe RDMA transport layer specification specifies the RDMA transport layer connection management service used to establish a link between the NVMe host and the NVMe subsystem as the RDMA_IP_CM service. The InfiniBand protocol specifically defines the RDMA_IP_CM service and RDMA_IP_CM messages (such as connection management request messages).

[0093] Figure 3 shows the format of a connection management request message. As shown in Figure 3, the connection management request message consists of 92 bytes. The InfiniBand protocol defines the first 36 bytes of these 92 bytes. The details are as follows.

[0094] In the following description, counting starts from 0, that is, the 0th one represents the beginning or the front one.

[0095] Of the 92 bytes, bits 0 to 7 and bits 8 to 7 of bytes 0 to 3 record the source port. Bits 16 to 23 of bytes 0 to 3 record the IP version and the reserved field (Res). Bits 16 to 23 of bytes 0 to 3 record the maximum version (MajV) and minimum version (MinV).

[0096] The 4th to 7th bytes, the 8th to 11th bytes, the 12th to 15th bytes, and the 16th to 19th bytes of the 92 bytes are all used to record the source IP address. The source IP address can occupy up to 128 bits. Bytes 16 to 19 are used to record data on bits 0 to 31 of the 128 bits, bytes 12 to 15 are used to record data on bits 32 to 63 of the 128 bits, bytes 8 to 11 are used to record data on bits 64 to 95 of the 128 bits, and bytes 4 to 7 are used to record data on bits 96 to 127 of the 128 bits.

[0097] Bytes 20 to 23, 24 to 27, 28 to 31, and 32 to 35 of the 92 bytes are used to record the destination IP address. The destination IP address can occupy up to 128 bits. Bytes 32 to 35 are used to record data on bits 0 to 31 of the 128 bits, bytes 28 to 31 are used to record data on bits 32 to 63 of the 128 bits, bytes 24 to 27 are used to record data on bits 64 to 95 of the 128 bits, and bytes 20 to 23 are used to record data on bits 96 to 127 of the 128 bits.

[0098] The remaining 56 bytes of the 92 bytes, excluding the 36 bytes mentioned above, can be used to record application layer private data. The application layer can also be called a consumer, and accordingly, the application layer private data can also be called consumer private data.

[0099] In addition, the NVMe RDMA transport layer specification defines the first 10 bytes of the 56 bytes, and the remaining 46 bytes are reserved bytes for the connection management request message. Figure 4 shows the format of the first 42 bytes of the 56 bytes. As shown in Figure 4, bytes 0 to 1 of the 42 bytes record the format of the RDMA private data, bytes 2 to 3 record the queue ID (QID), bytes 4 to 5 record the size of the RDMA queue pair (QP) host receive queue (RQ), bytes 6 to 7 record the size of the RDMA queue pair (QP) host send queue (SQ), bytes 6 to 7 record the solid-state drive controller ID (controller ID), and bytes 10 to 31 are reserved bytes for the connection management request message.

[0100] In step 202, one or more bytes from the 10th to the 31st bytes shown in FIG4 (i.e., the reserved bytes of the connection management request message) can be expanded to use the one or more bytes to carry the communication parameters of port A1, that is, to use the one or more bytes to record the communication parameters of port A1.

[0101] In one example, the 10th byte of the 42 bytes shown in FIG. 4 can be used to record an update indication and / or a verification indication. In one example, referring to FIG. 5 , the value recorded in the 10th byte represents an update indication or a verification indication. A value of 0 in the 10th byte indicates that the host 110 instructs the downstream device to not consider whether the communication parameters of port A1 are consistent with the communication parameters of the downstream device port. In other words, a 0 in the 10th byte indicates that neither a consistency check nor a consistency configuration is performed. A value of 1 in the 10th byte indicates that the host 110 instructs the downstream device to check whether the communication parameters of port A1 are consistent with the communication parameters of the downstream device port. In other words, a 1 in the 10th byte indicates that a consistency check is performed. A value of 2 in the 10th byte indicates that the host 110 instructs the downstream device to update the communication parameters of the downstream device port if the communication parameters of port A1 are inconsistent with the communication parameters of the downstream device port, so that the updated communication parameters of the downstream device port are consistent with the communication parameters of port A1. That is, the 2 recorded in the 10th byte represents an update indication.

[0102] In one example, the 11th byte of the 42 bytes shown in FIG4 is used to record the network type of the network between the host 110 and the NVM subsystem 120. Specifically, when the network between the host 110 and the NVM subsystem 120 is an NVMe over Fabric network, the update indication and / or detection indication in the request message C1 is valid. That is, when the network between the host 110 and the NVM subsystem 120 is an NVMe over Fabric network, the downstream device responds to the update indication and / or detection indication in the request message C1 and performs an update operation and / or a detection operation. When the network between the host 110 and the NVM subsystem 120 is not an NVMe over Fabric network, the update indication and / or detection indication in the request message C1 is invalid. That is, when the network between the host 110 and the NVM subsystem 120 is not an NVMe over Fabric network, the downstream device does not respond to the update indication and / or detection indication in the request message C1. In one example, when the network between the host 110 and the NVM subsystem 120 is not an NVMe over Fabric network, the NVM subsystem 120 may directly reply with a reject message. The reject message will be described in detail below and will not be repeated here. In one example, the value recorded in the 11th byte represents the network type of the network between the host 110 and the NVM subsystem 120. The value recorded in the 11th byte is 1, indicating that the network type of the network between the host 110 and the NVM subsystem 120 is an NVMe over Fabric network. The value recorded in the 11th byte is not 1, indicating that the network type of the network between the host 110 and the NVM subsystem 120 is not an NVMe over Fabric network.

[0103] In one example, the 12th byte of the 42 bytes shown in FIG4 is used by the intermediate node 130 to add a flag to the request message C1. When the communication parameters of port A1 and port A3 are inconsistent, the intermediate node 130 records the flag in the 12th byte to add the flag to the request message C1. The flag, also known as the switch path verification flag, is used to indicate that the communication parameters of port A1 and port A3 are inconsistent. In one example, if the value recorded in the 12th byte is 0, it indicates that the intermediate node 130 did not add the flag to the request message C1. If the value recorded in the 12th byte is not 0, it indicates that the intermediate node 130 added the flag to the request message C1. The communication parameters of a port can be one or more, and the value recorded in the 12th byte represents the number of inconsistent communication parameters.

[0104] In one example, the request message C1 may include n communication parameters for port A1, where n is an integer greater than or equal to 1. Bytes 12+1 through 12+n of the 42 bytes shown in FIG4 record the n communication parameters. As shown in FIG5 , each byte records one communication parameter. For example, the 13th byte records communication parameter 1, ..., and the 12+nth byte records communication parameter n.

[0105] The above example introduces the request message C1. Next, the transmission process of the request message C1 is described.

[0106] Continuing to refer to FIG. 2 , in step 202 , the host 110 may send a request message C1 to the NVM subsystem 120 .

[0107] In some embodiments, host 110 can send request message C1 to NVM subsystem 120 via the physical layer. That is, in this embodiment, request message C1 does not need to be encapsulated according to an upper-layer protocol; instead, request message C1 is sent directly to NVM subsystem 120 via the physical layer. The upper-layer protocol herein refers to a layer protocol above the physical layer, such as the application layer, transport layer, network layer, or data link layer. In some embodiments, host 110 can send request message C1 to NVM subsystem 120 via port A1.

[0108] The host 110 may add the IP address of the NVM subsystem 120 (e.g., the IP address of port A2) to the request message C1 and issue the request message C1 to send the request message C1 to the NVM subsystem 120. In some embodiments, as described above, the request message C1 may be a connection management request message, and the IP address of the NVM subsystem may be used as the destination address and recorded in one or more bytes from the 20th to the 35th bytes of the request message C1, thereby adding the IP address of the NVM subsystem to the request message C1.

[0109] In some embodiments, the storage system 100 further includes an intermediate node 130. As shown in Figure 2, step 202 includes: step 2021, the host 110 sends a request message C1 to the intermediate node 130. Exemplarily, the intermediate node 130 may receive the request message C1 sent by the host 110 through port A3.

[0110] In the first example of this embodiment, upon receiving the request message C1, the intermediate node 130 may directly send the request message C1 to the NVM subsystem 120. That is, in this example, the intermediate node 130 is only used to forward the request message C1.

[0111] In the second example of this embodiment, as shown in Figure 2, step 202 also includes step 2022, in which the intermediate node 130 determines whether the communication parameters of port A1 and port A3 are consistent. Specifically, upon receiving request message C1, the intermediate node 130 may parse request message C1 and obtain the communication parameters of port A1 from request message C1. Then, the intermediate node 130 determines whether the communication parameters of port A1 and port A3 are consistent. In one example, the communication parameter may be a PFC priority, where consistency between the communication parameters of port A1 and port A3 means that the PFC priority of port A1 and the PFC priority of port A3 are the same. In another example, the communication parameter may be an MTU, where consistency between the communication parameters of port A1 and port A3 means that the MTU of port A3 is greater than or equal to the MTU of port A1. And so on.

[0112] Here, only when the request message C1 includes a verification indication, the intermediate node 130 executes the solution of the second example; otherwise, the intermediate node 130 executes the solution of the first example.

[0113] In a first possible implementation of the second example, if the result of the determination in step 2022 is negative, that is, the communication parameters of port A1 and port A3 are inconsistent, the intermediate node 130 executes step 2023 to add a flag to the request message C1. In the embodiment shown in Figures 4 and 5, the intermediate node 130 may record the flag in the 12th byte of the 42 bytes shown in Figure 4 to add the flag to the request message C1. When the flag is added to the request message C1, the intermediate node 130 may, in step 2023, send the request message C1 with the flag added (i.e., the request message C1 with the flag added) to the NVM subsystem 120. That is, if the communication parameters of port A1 and port A3 are inconsistent, the request message C1 sent by the intermediate node 130 to the NVM subsystem 120 includes the flag. The flag is used to indicate that the communication parameters of port A1 and port A3 are inconsistent.

[0114] If the result of step 202 is yes, that is, the communication parameters of port A1 and port A3 are consistent, then intermediate node 130 may directly execute step 2024 and send a request message C1 to NVM subsystem 120. In other words, if the communication parameters of port A1 and port A3 are consistent, request message C1 sent by intermediate node 130 to NVM subsystem 120 does not include the aforementioned flag.

[0115] In a second possible implementation of the second example, if the determination result of step 2022 is negative and the request message C1 includes an update indication, the intermediate node 130 may respond to the update indication and, based on the communication parameters of port A1, update the communication parameters of port A3 so that the communication parameters of port A3 are consistent with the communication parameters of port A1. For example, if the PFC priority of port A3 is different from the PFC priority of port A1, the updated PFC priority of port A3 is the same as the PFC priority of port A1. For another example, if the MTU of port A3 is smaller than the MTU of port A1, the updated MTU of port A3 is greater than or equal to the MTU of port A1.

[0116] After completing the above update, the intermediate node 130 may send a request message C1 to the NVM subsystem 120. The request message C1 here does not include the above tag.

[0117] NVM subsystem 120 may receive the request message C1. The request message C1 may be sent directly from host 110 to NVM subsystem 120 or forwarded by intermediate node 130. In some embodiments, NVM subsystem 120 may receive the request message C1 through port A2.

[0118] 2 , upon receiving the request message C1 , the NVM subsystem 120 may execute step 203 to determine whether the communication parameters of the port A1 and the communication parameters of the port A2 are consistent.

[0119] As described above, request message C1 includes a port identifier. NVM subsystem 120 obtains the port identifier from request message C1. If the port identifier is identified as port A2, it can be recognized that request message C1 is used to request NVM subsystem 120 to receive service data sent by host 110 through port A1 through port A2.

[0120] The NVM subsystem 120 can obtain the communication parameters of port A2 and the communication parameters of port A1 from the request message C1. The NVM subsystem 120 can then execute step 203 to determine whether the communication parameters of port A1 and port A2 are consistent. In one example, the communication parameter can be a PFC priority. The consistency of the communication parameters of port A1 and port A2 means that the PFC priority of port A1 and the PFC priority of port A2 are the same. In another example, the communication parameter can be an MTU. The consistency of the communication parameters of port A1 and port A2 means that the MTU of port A2 is greater than or equal to the MTU of port A1. And so on.

[0121] In some embodiments, as shown in FIG2 , if the result of step 203 is yes, that is, the communication parameters of port A1 and port A2 are consistent, the NVM subsystem 120 may execute step 204a to send a response message B1 to the host 110. Response message B1 may also be referred to as an agree message, indicating that the NVM subsystem 120 agrees to receive, through port A2, the service data sent by the host 110 through port A1.

[0122] In some embodiments, the request message C1 includes an update indication. If the result of the judgment in step 203 is no, the NVM subsystem 120 can respond to the update indication and update the communication parameters of port A2 based on the communication parameters of port A1, so that the communication parameters of port A2 are consistent with the communication parameters of port A1. For example, if the PFC priority of port A2 is different from the PFC priority of port A1, the updated PFC priority of port A2 is the same as the PFC priority of port A1. For another example, if the MTU of port A2 is smaller than the MTU of port A1, the updated MTU of port A2 is greater than or equal to the MTU of port A1. After completing the update of the communication parameters of port A2, the NVM subsystem 120 can execute step 204a and send a response message B1 to the host 110.

[0123] Upon receiving response message B1, host 110 may send service data through port A1. This service data is transmitted via NVMe over Fabric between host 110 and NVM subsystem 120 and reaches NVM subsystem 120. NVM subsystem 120 receives this service data through port A2. The controller 121 of NVM subsystem 120 may store this service data in storage medium 122, thereby completing the storage of the service data.

[0124] In some embodiments, if the result of the determination in step 203 is negative, that is, the communication parameters of port A1 and port A2 are inconsistent, the NVM subsystem 120 may execute step 204b to send a response message B2 to the host 110. The response message B2 may also be referred to as a rejection message or a connection rejection message, and is used to indicate that the NVM subsystem 120 refuses to receive, through port A2, service data sent by the host 110 through port A1, or to indicate that the NVM subsystem 120 refuses to establish a link between port A1 and port A2.

[0125] In some embodiments, the NVM subsystem 120 may further detect whether the request message C1 includes a flag. If the request message C1 includes a flag, the NVM subsystem 120 executes step 204b and sends a response message B2 to the host 110, regardless of whether the communication parameters of port A1 and port A2 are consistent.

[0126] In some embodiments, upon receiving the response message B2, the host 110 may provide prompt information, such as displaying a prompt information or announcing a prompt information by voice. The prompt information is used to prompt the user to modify the communication parameters of port A1 and / or port A2 so that the communication parameters of port A1 and port A2 are consistent.

[0127] In an example of this embodiment, the user may trigger the host 110 to send a request message C1 to the NVM subsystem 120 again, so as to again request the NVM subsystem 120 to receive the service data sent by the host 110 through the port A1 through the port A2.

[0128] In another example of this embodiment, upon receiving the response message B2, the host 110 may start a timer. The timer duration may be preset, such as 10 seconds, 60 seconds, etc. When the timer expires, the host 110 may again send a request message C1 to the NVM subsystem 120 to again request the NVM subsystem 120 to receive, via port A2, the service data sent by the host 110 via port A1.

[0129] In some embodiments, the host 110 further includes a port A4 (not shown). Port A4 can be implemented with reference to the above description of port A1 and will not be described in detail here. Upon receiving the response message B2, the host 110 can send a request message C2 to the NVM subsystem 120. The request message C2 is used to request the NVM subsystem 120 to receive, via port A2, the service data sent by the host 110 via port A4. The request message C2 includes the communication parameters of port A4. Upon receiving the request message C2, the NVM subsystem 120 can determine whether the communication parameters of port A4 are consistent with the communication parameters of port A2. If they are consistent, the NVM subsystem 120 sends a response message B1 to the host 110. If they are inconsistent, the NVM subsystem 120 sends a response message B2 to the host 110. For details, reference can be made to the above description of the embodiment shown in FIG. 2 and will not be described in detail here.

[0130] In some embodiments, the NVM subsystem 120 further includes a port A5 (not shown). Port A5 can be implemented with reference to the above description of port A2 and will not be described in detail here. Upon receiving the response message B2, the host 110 can send a request message C3 to the NVM subsystem 120. The request message C3 is used to request the NVM subsystem 120 to receive, via port A5, the service data sent by the host 110 via port A1. The request message C3 includes the communication parameters of port A1. Upon receiving the request message C3, the NVM subsystem 120 can determine whether the communication parameters of port A5 are consistent with the communication parameters of port A1. If they are consistent, the NVM subsystem 120 sends a response message B1 to the host 110. If they are inconsistent, the NVM subsystem 120 sends a response message B2 to the host 110. For details, reference can be made to the above description of the embodiment shown in FIG. 2 and will not be described in detail here.

[0131] In summary, when a host and an NVM subsystem communicate using NVMe over Fabric, and when service data needs to be stored in the NVM subsystem, the NVM subsystem can first determine whether the communication parameters of the transmit port used by the host to transmit service data are consistent with the communication parameters of the receive port used by the NVM subsystem to receive service data. If they are inconsistent, the NVM subsystem can refuse to receive service data through the receive port, thereby preventing service instability caused by the inconsistency between the communication parameters of the transmit port and the receive port. In other words, this method allows the host to determine whether service stability can be guaranteed by transmitting service data between the host and the NVM subsystem via the first port and the second port when the host and the NVM subsystem communicate using NVMe over Fabric. This prevents service data from being transmitted via the first port and the second port when service stability cannot be guaranteed, thereby preventing service instability.

[0132] The present application provides a data storage device 600, which is configured in an NVM subsystem (e.g., NVM subsystem 120). The NVM subsystem communicates with a host (e.g., host 110) via NVMe over Fabric. The host has a first port (e.g., port A1), and the NVM subsystem has a second port (e.g., port A2). As shown in FIG6 , the device 600 includes:

[0133] a receiving unit 610, configured to receive a request message sent by the host, the request message being used to request the NVM subsystem to receive, through the second port, service data sent by the host through the first port, wherein the request message includes communication parameters of the first port;

[0134] The sending unit 620 is used to send a first response message to the host when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, and the downstream device port includes the second port. The first response message indicates that the NVM subsystem refuses to receive the business data through the second port.

[0135] In some embodiments, the sending unit 620 is further configured to: when the communication parameters of the first port are consistent with the communication parameters of the downstream device port, the NVM subsystem sends a second response message to the host, where the second response message indicates that the NVM subsystem agrees to receive the service data through the second port.

[0136] In an example of this embodiment, the request message includes an update indication, and the device 600 also includes: an update unit 630, which is used to respond to the update indication and update the communication parameters of the second port when the communication parameters of the first port and the communication parameters of the second port are inconsistent, so that the communication parameters of the second port are consistent with the communication parameters of the first port.

[0137] In some embodiments, an intermediate node is included between the host and the NVM subsystem, and the downstream device port further includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

[0138] In an example of this embodiment, the device 600 also includes: a confirmation unit 640, which is used to confirm that the communication parameters of the first port and the communication parameters of the downstream device port are inconsistent when the request message includes a mark; wherein the mark is added to the request message by the intermediate node when the communication parameters of the first port and the communication parameters of the third port are inconsistent.

[0139] The functions of the various functional units of the apparatus 600 may be implemented with reference to the above description of the NVM subsystem 120 and will not be described in detail here.

[0140] The present application provides a data storage device 700, which is configured on a host, such as host 110. The host communicates with an NVM subsystem (such as NVM subsystem 120) via NVMe over Fabric. The host has a first port, and the NVM subsystem has a second port. As shown in FIG7 , the device 700 includes:

[0141] a sending unit 710, configured to send a request message to the NVM subsystem, wherein the request message is used to request the NVM subsystem to receive, through the second port, service data sent by the host through the first port, wherein the request message includes communication parameters of the first port;

[0142] The receiving unit 720 is used to receive a first response message sent by the NVM subsystem, where the first response message indicates that the NVM subsystem refuses to receive the service data through the second port; wherein the first response message is sent by the NVM subsystem when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, and the downstream device port includes the second port.

[0143] In some embodiments, the receiving unit 720 is further used to: receive a second response message sent by the NVM subsystem, where the second response message indicates that the NVM subsystem agrees to receive the business data through the second port; wherein the second response message is sent by the NVM subsystem when the communication parameters of the first port are consistent with the communication parameters of the downstream device port.

[0144] In an example of this embodiment, the request message includes an update indication; wherein, when the communication parameters of the first port and the communication parameters of the second port are inconsistent, the NVM subsystem is used to respond to the update indication and update the communication parameters of the second port based on the communication parameters of the first port so that the communication parameters of the second port are consistent with the communication parameters of the first port.

[0145] In some embodiments, an intermediate node is included between the host and the NVM subsystem, and the downstream device port includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

[0146] The present embodiment provides an NVM subsystem 800. As shown in FIG8 , NVM subsystem 800 includes a port 810, a memory 820, and a controller 830. Memory 820 is used to store executable programs, and controller 830 is used to execute the operations described above for NVM subsystem 120 by running the executable programs.

[0147] The present embodiment provides a host 900. As shown in FIG9 , the host 900 includes a port 910, a memory 920, and a processor 930. The memory 920 is used to store executable programs; the processor 930 is used to execute the operations performed by the host 110 described above by running the executable programs.

[0148] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be executed on a computing device or stored in any available medium. When the computer program product is executed on a computing device, the computing device performs the operations described above for the NVM subsystem 120.

[0149] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on a computing device, it causes the computing device to perform the operations described above for host 110.

[0150] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the operations performed by the NVM subsystem 120 described above.

[0151] Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of storing data on a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be magnetic, optical, or semiconductor media. The computer-readable storage medium includes instructions that instruct the computing device to perform the operations described above for host 110.

[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A data storage method, characterized in that: A non-volatile memory NVM subsystem is applied to communicate with a host through NVMe over Fabric, the host has a first port, and the NVM subsystem has a second port; the method includes: The NVM subsystem receives a request message sent by the host, wherein the request message is used to request the NVM subsystem to receive service data sent by the host through the first port through the second port, wherein the request message includes communication parameters of the first port; When the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the NVM subsystem sends a first response message to the host, the downstream device port includes the second port, and the first response message indicates that the NVM subsystem refuses to receive the service data through the second port.

2. The method according to claim 1, characterized in that The method further includes: when the communication parameters of the first port are consistent with the communication parameters of the downstream device port, the NVM subsystem sends a second response message to the host, and the second response message indicates that the NVM subsystem agrees to receive the service data through the second port.

3. The method according to claim 2, characterized in that The request message includes an update indication, and the method further includes: When the communication parameters of the first port are inconsistent with the communication parameters of the second port, the NVM subsystem updates the communication parameters of the second port in response to the update indication so that the communication parameters of the second port are consistent with the communication parameters of the first port.

4. The method according to any one of claims 1 to 3, characterized in that An intermediate node is included between the host and the NVM subsystem, and the downstream device port further includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

5. The method according to claim 4, characterized in that The method further includes: when the request message includes a tag, the NVN subsystem confirming that the communication parameters of the first port and the communication parameters of the downstream device port are inconsistent; The mark is added by the intermediate node to the request message when the communication parameters of the first port and the communication parameters of the third port are inconsistent.

6. The method according to any one of claims 1 to 5, characterized in that The NVMe over Fabric is NVMe over RoCE, and the request message is an RDMA_IP_CM message, wherein the communication parameters of the first port are recorded in reserved bytes in the RDMA_IP_CM message.

7. The method according to any one of claims 1 to 6, characterized in that The communication parameters include at least one of a priority based on priority flow control PFC and a maximum transmission unit MTU.

8. A data storage method, characterized in that: The method is applied to a host communicating with an NVM subsystem via NVMe over Fabric, wherein the host has a first port and the NVM subsystem has a second port; the method comprises: The host sends a request message to the NVM subsystem, wherein the request message is used to request the NVM subsystem to receive, through the second port, service data sent by the host through the first port, wherein the request message includes communication parameters of the first port; The host receives a first response message sent by the NVM subsystem, where the first response message indicates that the NVM subsystem refuses to receive the service data through the second port; The first response message is sent by the NVM subsystem when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, and the downstream device port includes the second port.

9. The method according to claim 8, characterized in that The method further includes: the host receiving a second response message sent by the NVM subsystem, the second response message indicating that the NVM subsystem agrees to receive the service data through the second port; The second response message is sent by the NVM subsystem when the communication parameters of the first port are consistent with the communication parameters of the downstream device port.

10. The method according to claim 9, characterized in that The request message includes an update indication; wherein, When the communication parameters of the first port are inconsistent with the communication parameters of the second port, the NVM subsystem is used to respond to the update indication and update the communication parameters of the second port based on the communication parameters of the first port so that the communication parameters of the second port are consistent with the communication parameters of the first port.

11. The method according to any one of claims 8 to 10, characterized in that: An intermediate node is included between the host and the NVM subsystem, and the downstream device port includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

12. The method according to any one of claims 8 to 11, characterized in that The NVMe over Fabric is NVMe over RoCE, and the request message is an RDMA_IP_CM message, wherein the communication parameters of the first port are recorded in reserved bytes in the RDMA_IP_CM message.

13. The method according to any one of claims 8 to 12, characterized in that: The communication parameters include at least one of a priority based on priority flow control PFC and a maximum transmission unit MTU.

14. A data storage device, characterized in that: A non-volatile memory NVM subsystem configured to communicate with a host via NVMe over Fabric, the host having a first port, and the NVM subsystem having a second port; the device comprising: a receiving unit, configured to receive a request message sent by the host, wherein the request message is used to request the NVM subsystem to receive, through the second port, service data sent by the host through the first port, wherein the request message includes communication parameters of the first port; A sending unit is used to send a first response message to the host when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the downstream device port includes the second port, and the first response message indicates that the NVM subsystem refuses to receive the service data through the second port.

15. The device according to claim 14, characterized in that The sending unit is further used for: when the communication parameters of the first port are consistent with the communication parameters of the downstream device port, the NVM subsystem sends a second response message to the host, and the second response message indicates that the NVM subsystem agrees to receive the service data through the second port.

16. The device according to claim 15, characterized in that The request message includes an update indication, and the apparatus further includes: An updating unit is used for updating the communication parameters of the second port in response to the update indication when the communication parameters of the first port are inconsistent with the communication parameters of the second port, so that the communication parameters of the second port are consistent with the communication parameters of the first port.

17. The device according to any one of claims 14 to 16, characterized in that An intermediate node is included between the host and the NVM subsystem, and the downstream device port further includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

18. The device according to claim 17, characterized in that The device also includes: a confirmation unit, configured to confirm that the communication parameters of the first port and the communication parameters of the downstream device port are inconsistent when the request message includes a tag; The mark is added by the intermediate node to the request message when the communication parameters of the first port and the communication parameters of the third port are inconsistent.

19. A data storage device, characterized in that: A device configured for a host communicating with an NVM subsystem via NVMe over Fabric, wherein the host has a first port and the NVM subsystem has a second port; the device comprises: a sending unit, configured to send a request message to the NVM subsystem, wherein the request message is used to request the NVM subsystem to receive, through the second port, the service data sent by the host through the first port, wherein the request message includes a communication parameter of the first port; a receiving unit, configured to receive a first response message sent by the NVM subsystem, wherein the first response message indicates that the NVM subsystem refuses to receive the service data through the second port; The first response message is sent by the NVM subsystem when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, and the downstream device port includes the second port.

20. The device according to claim 19, characterized in that The receiving unit is further used to: receive a second response message sent by the NVM subsystem, where the second response message indicates that the NVM subsystem agrees to receive the service data through the second port; The second response message is sent by the NVM subsystem when the communication parameters of the first port are consistent with the communication parameters of the downstream device port.

21. The device according to claim 20, characterized in that The request message includes an update indication; wherein, When the communication parameters of the first port are inconsistent with the communication parameters of the second port, the NVM subsystem is used to respond to the update indication and update the communication parameters of the second port based on the communication parameters of the first port so that the communication parameters of the second port are consistent with the communication parameters of the first port.

22. The device according to any one of claims 19 to 21, characterized in that An intermediate node is included between the host and the NVM subsystem, and the downstream device port includes a third port, and the third port is used by the intermediate node to forward data sent from the first port to the second port.

23. A NVM subsystem, characterized in that: include: Second port; A memory for storing executable programs; A controller, configured to execute the method according to any one of claims 1 to 7 by running the executable program.

24. A host, characterized in that: include: First port; A memory for storing executable programs; A processor, configured to execute the method according to any one of claims 8 to 13 by running the executable program.

25. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device, the computing device performs the method according to any one of claims 1 to 7 or the method according to any one of claims 8 to 13.

26. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device, the computing device is caused to perform the method according to any one of claims 1 to 7 or the method according to any one of claims 8 to 13.

27. A storage system, characterized in that: The invention comprises a host and an NVM subsystem communicating with the host via NVMe over Fabric; the host has a first port, and the NVM subsystem has a second port; wherein, The host is used to send a request message to the NVM subsystem, wherein the request message is used to request the NVM subsystem to receive, through the second port, service data sent by the host through the first port, wherein the request message includes communication parameters of the first port; The NVM subsystem is used to send a first response message to the host when the communication parameters of the first port are inconsistent with the communication parameters of the downstream device port, the downstream device port includes the second port, and the first response message indicates that the NVM subsystem refuses to receive the service data through the second port.

Images