CN116225991A - Solid state disk controller, command scheduling method, solid state disk and storage medium - Google Patents

Abstract

The embodiment of the application relates to the field of storage equipment application and discloses a solid state disk controller, a command scheduling method, a solid state disk and a storage medium, wherein the solid state disk controller comprises at least two ports, an arbiter module and a resource statistics module; the arbiter module is connected with the resource statistics module and used for arbitrating and determining the port name, the function name and the queue name of the host command to be responded according to the command number and the data quantity of each port and function sent by the resource statistics module; and the resource statistics module is connected with the arbiter module and is used for counting the number of commands and the data quantity of each port and function according to the acquired host commands. By feeding back the acquired command information of the host commands to the arbiter module, the arbiter module schedules the commands of the functions of at least two ports, and the application can flexibly schedule the commands of the functions so as to meet the performance requirements of each host.

Description

Solid state disk controller, command scheduling method, solid state disk and storage medium

Technical Field

The present disclosure relates to the field of storage device applications, and in particular, to a solid state disk controller, a command scheduling method, a solid state disk, and a storage medium.

Background

The solid state disk (Solid State Drives, SSD) is a hard disk made of a solid state electronic memory chip array, and the solid state disk is usually controlled by a solid state disk Controller (SSD Controller).

With the wider application of the solid state disk controller in the cloud or virtualization, a solid state disk controller supporting dual-port and Single-Root-IO Virtualization (SR-IOV) appears, which can utilize the attribute of physical Function (Physical Function, PF) and Virtual Function (VF) to implement one device to virtualize a plurality of high-speed serial computer expansion (Peripheral Component interconnect Expess, PCIe) devices. However, for controllers supporting dual-port and single-root IO virtualization, how to flexibly schedule commands of each function according to hardware resources so that the commands reach the performance requirement of each host is a great difficulty.

Disclosure of Invention

The embodiment of the application provides a solid state disk controller, a command scheduling method, a solid state disk and a storage medium, which can flexibly schedule commands of various functions so as to meet the performance requirements of each host.

The embodiment of the application provides the following technical scheme:

In a first aspect, an embodiment of the present application provides a solid state disk controller, including at least two ports, an arbiter module, and a resource statistics module;

the arbiter module is connected with the resource statistics module and used for arbitrating and determining the port name, the function name and the queue name of the host command to be responded according to the command number and the data quantity of each port and function sent by the resource statistics module;

and the resource statistics module is connected with the arbiter module and is used for counting the command number and the data volume of each port and function according to the acquired host command and transmitting the command number and the data volume of each port and function to the arbiter module.

In some embodiments, the arbiter module comprises a port arbiter, a function arbiter, and a queue arbiter;

the port arbiter is used for arbitrating and determining the port name of the host command to be responded according to the command number and the data volume of the port sent by the resource statistics module;

the function arbiter is used for arbitrating and determining the function name of the host computer command to be responded according to the command number and the data volume of the function sent by the resource statistics module;

and the queue arbiter is used for arbitrating and determining the queue name of the host command needing to respond according to the function name.

In some embodiments, the ports include a first port and a second port;

if the command number of the first port reaches the port command number threshold and the data volume of the first port reaches the port data volume threshold, the arbiter module responds to the request of the second port, wherein the command number of the second port does not reach the port command number threshold and the data volume of the second port does not reach the port data volume threshold.

In some embodiments, if the command number of all ports does not reach the port command number threshold and the data volume of all ports does not reach the port data volume threshold, the arbiter module determines the port name as the port name corresponding to the port with the greater arbitration weight.

In some embodiments, after determining the port name, the arbiter module determines whether the command number and the data size of each function corresponding to the port name reach a function command number threshold and a function data size threshold, respectively;

if the command number of the function does not reach the function command number threshold and the data volume of the function does not reach the function data volume threshold, the arbiter module arbitrates the function and determines the function name.

In some embodiments, the solid state disk controller further includes a command fetching module and a command parsing module;

The command fetching module is connected with the arbiter module and the command analysis module and is used for acquiring commands from the host according to the port names, the function names and the queue names determined by the arbiter module and sending the commands to the command analysis module;

the command analysis module is connected with the command fetching module and the resource statistics module and is used for analyzing the command sent by the command fetching module to obtain command information and sending the command information to the resource statistics module.

In a second aspect, an embodiment of the present application provides a command scheduling method, which is applied to the solid state disk controller in the first aspect, where the command scheduling method includes:

the arbiter module arbitrates and determines the port name, function name and queue name of the host command to be responded according to the command number and data quantity of each port and function sent by the resource statistics module;

the resource statistics module counts the command number and the data volume of each port and function according to the acquired host commands, and sends the command number and the data volume of each port and function to the arbiter module.

In some embodiments, the solid state disk controller further includes a command fetching module and a command parsing module;

The method further comprises the steps of:

the command fetching module acquires a command from the host according to the port name, the function name and the queue name determined by the arbiter module, and sends the command to the command analyzing module;

the command analysis module analyzes the command sent by the resource statistics module to obtain command information and sends the command information to the resource statistics module.

In a third aspect, an embodiment of the present application provides a solid state hard disk, including:

the solid state disk controller of the first aspect;

and the at least one flash memory medium is in communication connection with the solid state disk controller.

In a fourth aspect, embodiments of the present application also provide a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform the command scheduling method of the second aspect.

The beneficial effects of the embodiment of the application are that: under the condition different from the prior art, the embodiment of the application provides a solid state disk controller, including: at least two ports, an arbiter module, and a resource statistics module; the arbiter module is connected with the resource statistics module and used for arbitrating and determining the port name, the function name and the queue name of the host command to be responded according to the command number and the data quantity of each port and function sent by the resource statistics module; and the resource statistics module is connected with the arbiter module and is used for counting the number of commands and the data quantity of each port and function according to the acquired host commands. By feeding back the acquired command information of the host commands to the arbiter module, the arbiter module schedules the commands of the functions of at least two ports, and the application can flexibly schedule the commands of the functions so as to meet the performance requirements of each host.

Drawings

One or more embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which the figures of the drawings are not to be taken in a limiting sense, unless otherwise indicated.

Fig. 1 is a schematic structural diagram of a solid state disk provided in an embodiment of the present application;

FIG. 2 is a schematic flow chart of command processing according to an embodiment of the present application;

FIG. 3 is a schematic structural diagram of a solid state disk with dual ports according to an embodiment of the present disclosure;

FIG. 4 is a schematic structural diagram of a solid state disk supporting single root I/O virtualization according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a solid state disk controller according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of a port-queue relationship provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of a detailed structure of a solid state disk controller according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of an arbiter module according to an embodiment of the present application;

fig. 9 is a schematic flow chart of a command scheduling method according to an embodiment of the present application;

Fig. 10 is a detailed flowchart of command scheduling according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

It should be noted that, if not conflicting, the various features in the embodiments of the present application may be combined with each other, which is within the protection scope of the present application. In addition, while functional block division is performed in a device diagram and logical order is shown in a flowchart, in some cases, the steps shown or described may be performed in a different order than the block division in the device, or in the flowchart. Moreover, the words "first," "second," "third," and the like as used herein do not limit the data and order of execution, but merely distinguish between identical or similar items that have substantially the same function and effect.

The following specifically describes the technical scheme of the present application with reference to the drawings of the specification:

referring to fig. 1, fig. 1 is a schematic structural diagram of a solid state disk according to an embodiment of the present application;

as shown in fig. 1, the solid state disk 100 includes a flash memory medium 110 and a solid state disk controller 120 connected to the flash memory medium 110. The solid state disk 100 is in communication connection with the host 200 through a wired or wireless manner, so as to implement data interaction.

The Flash memory medium 110, which is a storage medium of the solid state disk 100, is also called a Flash memory, a NAND Flash, a Flash memory or Flash particles, belongs to one type of storage device, is a nonvolatile memory, and can store data for a long time even without current supply, and has storage characteristics equivalent to a hard disk, so that the Flash memory medium 110 becomes a base of storage media of various portable digital devices.

The solid state disk controller 120 includes a data converter 121, a processor 122, a buffer 123, a flash memory controller 124, and an interface 125.

The data converter 121 is connected to the processor 122 and the flash memory controller 124, respectively, and the data converter 121 is used for converting binary data into hexadecimal data and vice versa. Specifically, when the flash controller 124 writes data to the flash medium 110, binary data to be written is converted into hexadecimal data by the data converter 121, and then written to the flash medium 110. When the flash controller 124 reads data from the flash memory medium 110, hexadecimal data stored in the flash memory medium 110 is converted into binary data by the data converter 121, and then the converted data is read from the binary data page register. The data converter 121 may include a binary data register and a hexadecimal data register, among others. Binary data registers may be used to hold data converted from hexadecimal to binary, and hexadecimal data registers may be used to hold data converted from binary to hexadecimal.

The processor 122 is connected to the data converter 121, the buffer 123, the flash memory controller 124 and the interface 125, where the processor 122 is connected to the data converter 121, the buffer 123, the flash memory controller 124 and the interface 125 through buses or other manners, and is configured to execute nonvolatile software programs, instructions and modules stored in the buffer 123, so as to implement any method embodiment of the present application. On this basis, through firmware development, it is also used for the core processing of the flash translation layer (Flash translation layer, FTL).

The buffer 123 is mainly used for buffering the read/write command sent by the host 200 and the read data or write data obtained from the flash memory medium 110 according to the read/write command sent by the host 200.

The flash controller 124 is connected to the flash medium 110, the data converter 121, the processor 122 and the buffer 123, and is used for accessing the flash medium 110 at the back end and managing various parameters and data I/O of the flash medium 110.

The interface 125 is connected to the host 200 and the data converter 121, the processor 122 and the buffer 123, and is configured to receive data sent by the host 200, or receive data sent by the processor 122, so as to implement data transmission between the host 200 and the processor 122, where the interface 125 may be a SATA-2 interface, a SATA-3 interface, a SAS interface, a MSATA interface, a PCI-E interface, a ngaf interface, a CFast interface, a SFF-8639 interface and an m.2nvme/SATA protocol.

Referring to fig. 2, fig. 2 is a schematic flow chart of command processing according to an embodiment of the present application;

in the embodiment of the application, a communication protocol adopted between a Host (Host) and a Solid State Disk (SSD) is a Non-volatile memory standard (Non-Volatile Memory Express, NVMe), and specifically, the communication protocol runs on a high-speed serial computer expansion (Peripheral Component interconnect Expess, PCIe) port and is used for normalizing data transmission between a computer and a storage device.

As shown in fig. 2, the flow of the command processing includes:

step S1, writing a command to a command sending queue by a host;

specifically, a command Send Queue (SQ) is located in the memory of the Host (Host).

Step S2, the host writes a register to inform that a new command exists;

specifically, the host writes a command into a command sending queue tail register (Submission Queue Tail Doorbell) to inform the solid state disk controller to fetch the command from the host, wherein the command sending queue tail register is located inside the solid state disk controller.

S3, the solid state disk controller takes a command;

specifically, the solid state disk controller receives the notification and then fetches the command from the SQ.

S4, executing a command by the solid state disk controller;

Specifically, the solid state disk controller executes the command.

S5, writing a command execution result into a command completion queue by the solid state disk controller;

specifically, after the command execution is completed, the solid state disk controller writes the command execution result into a command Completion Queue (CQ), where the command Completion Queue is located in a memory of the Host (Host).

S6, generating an interrupt by the solid state disk controller;

specifically, the solid state disk controller sends an interrupt notification host command completion;

step S7, the host processes the command completion queue;

specifically, the host processes the CQ after receiving the interrupt, and checks the command completion status.

And S8, the host writes a register to inform the solid state disk controller.

Specifically, after the host computer processes the command execution result in the CQ, the host computer notifies the solid state disk controller through a command completion queue head register (Completion Queue Head Doorbell), wherein the command completion queue head register is positioned inside the solid state disk controller.

Referring to fig. 3, fig. 3 is a schematic structural diagram of a solid state disk with dual ports according to an embodiment of the present application;

as shown in fig. 3, the solid state disk includes a high-speed serial computer expansion port x (PCIe port x), a high-speed serial computer expansion port y (PCIe port y), and two solid state disk controllers, each of which is used to implement a high-speed serial computer expansion function 0 (PCIe function 0), and the whole flash memory space is divided into 3 logical spaces (namespaces, NS), where logical space a (NS a) is exclusively shared by the left-side solid state disk controller, logical space C (NS C) is exclusively shared by the right-side solid state disk controller, and logical space B (NS B) is shared by both.

It will be understood that exclusive refers to that only the associated solid state disk controller can access the NS, and that other solid state disk controllers cannot access it, and shared refers to that the NS (e.g., NS B in fig. 3) is commonly accessible by two solid state disk controllers.

It can be understood that a solid state disk adopting NVMe protocol mainly comprises a solid state disk controller, a flash memory space and PCIe ports. If the flash memory space is divided into several independent logical spaces, each space Logical Block Address (LBA) ranges from 0 to N-1 (N is the logical space size), and each logical space thus divided is called NS. Each NS has a name and an ID, and the solid state disk distinguishes different NS by the NS number (ID), for example: in fig. 3, the entire flash space is divided into three NSs, named NSA, NS B and NS C, respectively, and corresponding logical space Numbers (NSID) are 1, 2 and 3, respectively.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a solid state disk supporting single root I/O virtualization according to an embodiment of the present application;

in the embodiment of the application, the solid state disk supports Single Root-IO Virtualization (SR-IOV), wherein the SR-IOV technology allows PCIe devices to be shared between virtual machines efficiently, and the SR-IOV technology is realized in hardware, so that IO performance which can be comparable with the performance of a local machine can be obtained. A single IO resource (single solid state disk) may be shared by many virtual machines, the shared device will provide dedicated resources, and also use shared generic resources so that each virtual machine can access unique resources.

As shown in fig. 4, the solid state disk, as a terminal of PCIe, implements a physical function 0 and 4 virtual functions associated with the physical function 0: virtual function (0, 1), virtual function (0, 2), virtual function (0, 3), and virtual function (0, 4). Physical function 0 has its own NS exclusive to each virtual function, for example: physical function 0 exclusively shares logical space A (NS A), with the logical space number of NS A being 1 (NSID 1); virtual function (0, 1) exclusively shares logical space B (NS B), logical space number of NS B being 3 (NSID 3); virtual function (0, 2) exclusively shares logical space C (NS C), with NS C having logical space number 4 (NSID 4); the virtual functions (0, 3) exclusively share a logical space D (NS D), the logical space number of NS D being 5 (NSID 5); the virtual functions (0, 4) exclusively share a logical space E (NS E), the logical space number of NS E being 6 (NSID 6).

Wherein physical function 0 and each virtual function also have a common logical space F (NS F), with a logical space number of 2 (NSID 2), which allows the virtual functions to share physical devices and execute port commands without processor and virtual machine hypervisor software overhead.

However, for a solid state disk controller supporting dual-port and single-root IO virtualization, multiple SQs can be created for each function in each port, and at present, the solid state disk controller can support up to 1024 queues, so how to flexibly schedule commands of each queue according to hardware resources, so that it is a great difficulty to achieve the performance requirement of each user, i.e., host.

Based on this, the embodiment of the application provides a solid state disk controller, a command scheduling method, a solid state disk and a storage medium, so that commands of each queue can be flexibly scheduled to meet the performance requirement of each host.

Referring to fig. 5, fig. 5 is a schematic structural diagram of a solid state disk controller according to an embodiment of the present disclosure;

in the embodiment of the application, the solid state disk controller supports single-root I/O virtualization and can be in communication connection with a plurality of hosts. The solid state disk controller comprises at least two ports, wherein each port is a PCIe port, a communication protocol adopted between a host and the solid state disk is a Non-volatile memory standard (Non-Volatile Memory Express, NVMe), and the communication protocol runs on the PCIe port and is used for standardizing data transmission of a computer and storage equipment.

As shown in fig. 5, the solid state disk controller 500 includes an arbiter module 501 and a resource statistics module 502, where the arbiter module 501 is communicatively connected to the resource statistics module 502.

The arbiter module 501 is connected to the resource statistics module 502, and is configured to arbitrate and determine a port name, a function name, and a queue name of a host command to be responded according to the number of commands and the data amount of each port and function sent by the resource statistics module 502.

The resource statistics module 502 is connected with the arbiter module 501, and is configured to count the number of commands and the data amount of each port and each function according to the acquired host command, and send the number of commands and the data amount of each port and each function to the arbiter module.

It can be understood that the solid state disk controller includes at least two ports, each Port (Port) includes at least one Function (Function), each user (i.e., host) corresponds to one Function (Function), the memory of each user (i.e., host) includes at least one command Sending Queue (SQ), and the flow of command processing performed by the host and the solid state disk controller is the same as the command processing flow in fig. 2, which is not described herein again.

Referring to fig. 6, fig. 6 is a schematic diagram of a relationship between a port and a queue according to an embodiment of the present disclosure;

in this embodiment of the present application, the solid state disk controller includes at least two ports, and fig. 6 illustrates a relationship between each port and a queue by taking two ports as an example.

As shown in fig. 6, two ports: port0 (Port 0) and Port1 (Port 1), each Port comprising at least one Function (Function), for example: port0 includes Function0 (Function 0), … …, function N (Function N), where N is a positive integer; port1 includes Function0 (Function 0), … …, function N (Function N), where N is a positive integer, each Function corresponding to at least one command Send Queue (SQ), for example: function0 (Function 0) corresponds to a command transmission queue 0 (SQ 0), … …, a command transmission queue N (SQ N), wherein N is a positive integer; function N (Function N) corresponds to command send queues 0 (SQ 0), … …, command send queue N (SQ N), where N is a positive integer.

In the embodiment of the application, the command of each function of at least two ports is scheduled by the arbiter module by feeding back the acquired command information of the host commands to the arbiter module.

Referring to fig. 7, fig. 7 is a detailed schematic diagram of a solid state disk controller according to an embodiment of the present disclosure;

as shown in fig. 7, the solid state disk controller 500 includes an arbiter module 501, a resource statistics module 502, a command fetching module 503, and a command parsing module 504.

The arbiter module 501 is communicatively connected to the resource statistics module 502 and the command fetching module 503, and the command parsing module 504 is communicatively connected to the command fetching module 503 and the resource statistics module 502.

The arbiter module 501 is connected to the resource statistics module 502, and is configured to arbitrate and determine a port name, a function name, and a queue name of a host command to be responded according to the number of commands and the data amount of each port and function sent by the resource statistics module 502.

Specifically, referring to fig. 8, fig. 8 is a schematic structural diagram of an arbiter module according to an embodiment of the present application;

As shown in fig. 8, the arbiter module 501 includes a port arbiter 5011, a function arbiter 5012, and a queue arbiter 5013;

the Port arbiter 5011 is configured to arbitrate and determine a Port name (Port ID) where a host command to be responded is located according to the number of commands and the data size of the ports sent by the resource statistics module.

In this embodiment of the present application, the ports include a first port and a second port, and if the number of commands of the first port reaches the port command number threshold and the data volume of the first port reaches the port data volume threshold, the port arbiter in the arbiter module responds to the request of the second port, where the number of commands of the second port does not reach the port command number threshold and the data volume of the second port does not reach the port data volume threshold.

The port command number threshold and the port data amount threshold may be preset in the solid state disk controller, for example: if the solid state disk controller supports 1024 commands to be executed in parallel, in order to ensure the performance of each port is the same, the threshold of the number of commands of each port may be set to 512.

In this embodiment of the present application, if the number of commands of all ports does not reach the threshold number of commands of the ports and the data volume of all ports does not reach the threshold number of data volumes of the ports, then the port arbiter in the arbiter module determines that the port name is the port name corresponding to the port with the large arbitration weight, where the arbitration weight is determined by the performance requirement of the user, i.e., the host, on the port, and the arbitration weight ratio of all the ports is the bandwidth ratio.

For example: PCIe for each port supports the fifth generation standard (Gen 5X 2), where the number of buses is 2, the highest bandwidth is 8GB/s, and according to the performance requirement of the user, i.e., the host, for each port, if the performance requirement of port 0 is 8GB/s and the performance requirement of port 1 is 4GB/s, then the arbitration weight of port 0 may be set to 2, and the arbitration weight of port 1 may be set to 1.

In this embodiment of the present application, if the arbitration weights of at least two ports are the same, the port arbiters in the arbitration module sequentially poll the ports with the same arbitration weights, that is, the port arbiters issue a query at regular time, sequentially query whether each port needs its service, and give the service immediately, and then query another port after the service is finished, and then repeat.

In the present embodiment, the port arbiter 5011 includes, but is not limited to, a weighted round robin (Weighted Round Robin, WRR) arbiter. Preferably, the port arbiter is a weighted round robin arbiter.

The Function arbiter 5012 is configured to arbitrate and determine a Function name (Function ID) where the host command to be responded is located according to the number of commands and the data size of the Function sent by the resource statistics module. Specifically, the function arbiter 5012 determines all functions belonging to the port according to the port name obtained by the port arbiter 5011, and decides which functions participate in the arbitration according to the number of commands and the data amount of each function counted by the resource counting module, thereby determining the function name.

Specifically, after the port arbiter in the arbiter module determines the port name, the function arbiter determines whether the command number and the data size of each function corresponding to the port name reach the function command number threshold and the function data size threshold, respectively.

The function command number threshold and the function data amount threshold may be preset in the solid state disk controller, for example: the solid state disk controller supports a fifth generation high-speed serial computer expansion standard (PCIe Gen 5), wherein the number of buses is 4, 32 functions (each user is a host corresponding to one function) can be supported, 1024 commands can be executed in parallel, and if the performance of each user is the host is guaranteed to be the same, the threshold value of the number of the function commands can be set to 1024/32=32, so that the performance of each user is 512 MB/s. If a certain user, i.e. host, wants to achieve a performance of 1GB/s, its function command number threshold can be configured to 64.

It will be appreciated that when a function exceeds a function command number threshold or a function data amount threshold (when the performance requirements set by the user, i.e., the host, have been met), the function arbiter ignores the request for the function and does not respond to the function. If a function exceeds a function command number threshold or a function data amount threshold, the function arbiter also responds to the function, resulting in other functions not achieving the desired performance.

Further, if the number of commands of the function does not reach the threshold number of commands of the function and the data volume of the function does not reach the threshold number of data volumes of the function, a function arbiter in the arbiter module arbitrates the function to determine the function name.

Specifically, for a plurality of functions satisfying the above conditions, the function arbiter determines the function name as the name of the function with the highest bandwidth, i.e., the function with the highest performance requirement of the user (host). If the bandwidths of the two functions are the same, the function arbitrator polls the two functions in turn.

In the present embodiment, the functional arbiter includes, but is not limited to, a Round Robin (RR) arbiter. Preferably, the functional arbiter is a poll arbiter.

The queue arbiter 5013 is configured to determine a queue name where a host command to be responded is located according to function name arbitration, specifically, the queue arbiter 5013 determines all queues belonging to the function, that is, command Sending Queues (SQ), according to the function name obtained by the function arbiter 5012, and makes all the queues with requests participate in arbitration, and determines the queue name of the response according to the related information of each queue.

Specifically, the solid state disk controller determines the queue with the request through the command sending queue tail register. It can be understood that after the host writes the command into the command sending queue, the command is written into the tail register of the command sending queue, which means that the command sending queue has a request and needs to be responded by the solid state disk controller.

In the present embodiment, the queue arbiters include, but are not limited to, weighted Round Robin (Weighted Round Robin, WRR) arbiters, round Robin (RR) arbiters.

In the embodiment of the application, at least two ports and single-root I/O virtualization are supported through the solid state disk controller, and 3-layer arbitration selection is adopted: the method and the device enable command scheduling to meet the performance requirement of each user, namely a host, in a layer-by-layer progressive manner from the port-function-queue.

The resource statistics module 502 is connected with the arbiter module 501 and the command parsing module 504, and is configured to count the number of commands and the data amount of each port and function according to the acquired host command, and send the number of commands and the data amount of each port and function to the arbiter module. Specifically, the resource statistics module 502 counts the number of commands and the data amount of each port and function according to the command information sent by the command parsing module 504, and sends the number of commands and the data amount to the arbiter module 501.

In the present embodiment, the resource statistics module 502 includes, but is not limited to, a micro control unit (Microcontroller Unit, MCU), a central processing unit (Central Processing Unit, CPU).

The command fetching module 503 is connected to the arbiter module 501 and the command parsing module 504, and is configured to obtain a command from a host according to the port name, the function name and the queue name determined by the arbiter module 501, and send the command to the command parsing module 504.

In the embodiment of the present application, the command fetching module 503 includes, but is not limited to, a micro control unit (Microcontroller Unit, MCU), a central processing unit (Central Processing Unit, CPU).

The command parsing module 504 is connected to the command fetching module 503 and the resource statistics module 502, and is configured to parse the command sent by the command fetching module 503, obtain command information, and send the command information to the resource statistics module 502, where the command information includes a command size and a command type, the command size includes a command number and a data amount, and the command type includes a read command and a write command.

In the present embodiment, the command parsing module 504 includes, but is not limited to, a micro control unit (Microcontroller Unit, MCU), a central processing unit (Central Processing Unit, CPU).

In the embodiment of the application, the command information of the acquired host command is fed back to the arbiter module, and the arbiter module schedules the commands of the functions of at least two ports.

Referring to fig. 9, fig. 9 is a flow chart of a command scheduling method according to an embodiment of the present application;

the command scheduling method is applied to a solid state disk controller, wherein the solid state disk controller supports single-root I/O virtualization, the solid state disk controller comprises at least two ports, each port is a PCIe port, a communication protocol adopted between a host and the solid state disk is a nonvolatile memory standard (Non-Volatile Memory Express, NVMe), and the communication protocol runs on the PCIe port and is used for standardizing data transmission of a computer and a storage device.

In this embodiment of the present application, the solid state disk controller further includes an arbiter module and a resource statistics module.

As shown in fig. 9, the command scheduling method includes:

step S901: the arbiter module arbitrates and determines the port name, function name and queue name of the host command to be responded according to the command number and data quantity of each port and function sent by the resource statistics module;

It can be understood that the solid state disk controller includes at least two ports, each Port (Port) includes at least one Function (Function), each user (i.e., host) corresponds to one Function (Function), the memory of each user (i.e., host) includes at least one command Sending Queue (SQ), and the flow of command processing performed by the host and the solid state disk controller is the same as the command processing flow in fig. 2, which is not described herein again.

Specifically, the arbiter module includes a port arbiter, a function arbiter, and a queue arbiter.

In this embodiment of the present application, the port arbiter is configured to arbitrate and determine, according to the number of commands and the data size of the port sent by the resource statistics module, a port name where a host command to be responded is located.

In this embodiment of the present application, the ports include a first port and a second port, and if the number of commands of the first port reaches the port command number threshold and the data volume of the first port reaches the port data volume threshold, the port arbiter in the arbiter module responds to the request of the second port, where the number of commands of the second port does not reach the port command number threshold and the data volume of the second port does not reach the port data volume threshold.

The port command number threshold and the port data amount threshold may be preset in the solid state disk controller, for example: if the solid state disk controller supports 1024 commands to be executed in parallel, in order to ensure the performance of each port is the same, the threshold of the number of commands of each port may be set to 512.

In this embodiment of the present application, if the number of commands of all ports does not reach the threshold number of commands of the ports and the data volume of all ports does not reach the threshold number of data volumes of the ports, then the port arbiter in the arbiter module determines that the port name is the port name corresponding to the port with the large arbitration weight, where the arbitration weight is determined by the performance requirement of the user, i.e., the host, on the port, and the arbitration weight ratio of the two ports is the bandwidth ratio.

For example: PCIe for each port supports the fifth generation standard (Gen 5X 2), where the number of buses is 2, the highest bandwidth is 8GB/s, and according to the performance requirement of the user, i.e., the host, for each port, if the performance requirement of port 0 is 8GB/s and the performance requirement of port 1 is 4GB/s, then the arbitration weight of port 0 may be set to 2, and the arbitration weight of port 1 may be set to 1.

In this embodiment of the present application, if the arbitration weights of at least two ports are the same, the port arbiters in the arbitration module sequentially poll the ports with the same arbitration weights, that is, the port arbiters issue a query at regular time, sequentially query whether each port needs its service, and give the service immediately, and then query another port after the service is finished, and then repeat.

In this embodiment of the present application, the function arbiter is configured to arbitrate and determine, according to the number of commands and the data size of the function sent by the resource statistics module, a function name where the host command to be responded is located. Specifically, the function arbiter determines all functions belonging to the port according to the port names obtained by the port arbiter, and decides which functions participate in the arbitration according to the number of commands and the data quantity of each function counted by the resource counting module, thereby determining the function names.

Specifically, after the port arbiter in the arbiter module determines the port name, the function arbiter determines whether the command number and the data size of each function corresponding to the port name reach the function command number threshold and the function data size threshold, respectively.

The function command number threshold and the function data amount threshold may be preset in the solid state disk controller, for example: the solid state disk controller supports a fifth generation high-speed serial computer expansion standard (PCIe Gen 5), wherein the number of buses is 4, 32 functions (each user, namely, a host corresponds to one function) can be supported, 1024 commands can be executed in parallel, and if the performance of each user, namely, the host is guaranteed to be the same, the threshold value of the number of the function commands can be set to 1024/32=32, so that each user can reach 512MB/s of performance. If a certain user, i.e. host, wants to achieve a performance of 1GB/s, its function command number threshold can be configured to 64.

It will be appreciated that when a function exceeds a function command number threshold or a function data amount threshold (when a user-set performance requirement has been met), the function arbiter ignores the request for the function and does not respond to the function. If a function exceeds a function command number threshold or a function data amount threshold, the function arbiter also responds to the function, resulting in other functions not achieving the desired performance.

Further, if the number of commands of the function does not reach the threshold number of commands of the function and the data volume of the function does not reach the threshold number of data volumes of the function, a function arbiter in the arbiter module arbitrates the function to determine the function name.

Specifically, for a plurality of functions satisfying the above conditions, the function arbiter determines the function name as the name of the function with the highest bandwidth, i.e., the function with the highest performance requirement of the user (host). If the bandwidths of the two functions are the same, the function arbitrator polls the two functions in turn.

In this embodiment of the present application, the queue arbiter is configured to determine, according to function name arbitration, a queue name where a host command to be responded is located, specifically, the queue arbiter determines, according to the function name obtained by the function arbiter, all queues belonging to the function, that is, command sending queues, and makes all queues having requests participate in arbitration, and determines, according to relevant information of each queue, a queue name to be responded at this time.

Specifically, the solid state disk controller determines the queue with the request through the command sending queue tail register. It can be understood that after the host writes the command into the command sending queue, the command is written into the tail register of the command sending queue, which means that the command sending queue has a request and needs to be responded by the solid state disk controller.

Step S902: the resource statistics module counts the command number and the data volume of each port and function according to the acquired host commands, and sends the command number and the data volume of each port and function to the arbiter module.

Specifically, after the port name, the function name and the queue name of the host command to which the arbiter module needs to respond are located, the solid state disk controller takes out the corresponding host command from the host according to the port name, the function name and the queue name, and then the resource statistics module counts the number of commands and the data quantity of each port and function according to the obtained host command, and sends the number of commands and the data quantity of each port and function to the arbiter module.

Referring to fig. 10, fig. 10 is a detailed flowchart of command scheduling according to an embodiment of the present application;

in this embodiment of the present application, the solid state disk controller further includes a command fetching module and a command parsing module.

As shown in fig. 10, the detailed flow of command scheduling includes:

step S1001: the arbiter module arbitrates and determines the port name, function name and queue name of the host command to be responded according to the command number and data quantity of each port and function sent by the resource statistics module;

specifically, the step is the same as step S901, and will not be described here again.

Step S1002: the command fetching module acquires a command from the host according to the port name, the function name and the queue name determined by the arbiter module, and sends the command to the command analyzing module;

specifically, the command fetching module determines the position of a host command to be responded according to the port name, the function name and the queue name determined by the arbiter module, acquires the command from the host, and then sends the acquired command to the command analyzing module.

Step S1003: the command analysis module analyzes the command sent by the command acquisition module to obtain command information and sends the command information to the resource statistics module;

specifically, the command information includes a command size including a command number and a data amount, and a command type including a read command and a write command.

Step S1004: the resource statistics module counts the number of commands and the data volume of each port and each function according to the command information sent by the command analysis module, and sends the number of commands and the data volume of each port and each function to the arbiter module.

Specifically, the resource statistics module counts the number of commands and the data volume of each port and function according to the command information of the commands retrieved from the host, and sends the number of commands and the data volume of each port and function to the arbiter module, so that the arbiter flexibly schedules the commands of each function of at least two ports, thereby achieving the performance requirement of each user, namely the host.

In an embodiment of the present application, a command scheduling method is provided and applied to a solid state disk controller, where the solid state disk controller includes at least two ports, an arbiter module and a resource statistics module, and the method includes: the arbiter module arbitrates and determines the port name, function name and queue name of the host command to be responded according to the command number and data quantity of each port and function sent by the resource statistics module; the resource statistics module counts the command number and the data volume of each port and function according to the acquired host commands, and sends the command number and the data volume of each port and function to the arbiter module. By feeding back the retrieved command information to the arbiter, the arbiter schedules the commands of the respective functions of the at least two ports, the present application enables flexible scheduling of the commands of the respective functions to achieve the performance requirements of each host.

The embodiments also provide a non-volatile computer storage medium storing computer executable instructions that are executable by one or more processors, for example, the one or more processors may perform a method for lifetime prediction of a flash memory block in any of the method embodiments described above, for example, perform a method for command scheduling in any of the method embodiments described above, for example, perform the steps described above.

The apparatus or device embodiments described above are merely illustrative, in which the unit modules illustrated as separate components may or may not be physically separate, and the components shown as unit modules may or may not be physical units, may be located in one place, or may be distributed over multiple network module units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

From the above description of embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by means of software plus a general purpose hardware platform, or may be implemented by hardware. Based on such understanding, the foregoing technical solution may be embodied essentially or in a part contributing to the related art in the form of a software product, which may be stored in a computer readable storage medium, such as ROM/RAM, a magnetic disk, an optical disk, etc., and include several instructions for up to a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method of each embodiment or some parts of the embodiments.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; the technical features of the above embodiments or in the different embodiments may also be combined under the idea of the present application, the steps may be implemented in any order, and there are many other variations of the different aspects of the present application as above, which are not provided in details for the sake of brevity; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims (10)

1. The solid state disk controller is characterized by comprising at least two ports, an arbiter module and a resource statistics module;

the arbiter module is connected with the resource statistics module and used for arbitrating and determining the port name, the function name and the queue name of the host command to be responded according to the number and the data quantity of the commands of each port and function sent by the resource statistics module;

The resource statistics module is connected with the arbiter module and is used for counting the command number and the data volume of each port and function according to the acquired host commands and sending the command number and the data volume of each port and function to the arbiter module.

2. The solid state disk controller of claim 1, wherein the arbiter module comprises a port arbiter, a function arbiter, and a queue arbiter;

the port arbiter is used for arbitrating and determining the port name of the host command to be responded according to the command number and the data quantity of the port sent by the resource statistics module;

the function arbiter is used for arbitrating and determining the function name of the host command to be responded according to the command number and the data quantity of the function sent by the resource statistics module;

and the queue arbiter is used for arbitrating and determining the queue name of the host command needing to be responded according to the function name.

3. The solid state disk controller of claim 1 or 2, wherein the ports comprise a first port and a second port, and the arbiter module is responsive to a request for the second port if the number of commands for the first port reaches a port command number threshold and the data amount for the first port reaches a port data amount threshold, wherein the number of commands for the second port does not reach a port command number threshold and the data amount for the second port does not reach a port data amount threshold.

4. The solid state disk controller of claim 1 or 2, wherein the arbiter module determines the port name as the port name corresponding to the port with the greater arbitration weight if the command number of all the ports does not reach the port command number threshold and the data amount of all the ports does not reach the port data amount threshold.

5. The solid state disk controller of claim 4, wherein the arbiter module determines whether the command number and the data size of each of the functions corresponding to the port name reach a function command number threshold and a function data size threshold, respectively, after determining the port name;

and if the command number of the function does not reach the function command number threshold and the data volume of the function does not reach the function data volume threshold, the arbiter module arbitrates the function and determines the function name.

6. The solid state disk controller of any one of claims 1, 2, or 5, further comprising a command fetching module and a command parsing module;

the command fetching module is connected with the arbiter module and the command analysis module and is used for obtaining a command from a host according to the port name, the function name and the queue name determined by the arbiter module and sending the command to the command analysis module;

The command analysis module is connected with the command taking module and the resource statistics module and is used for analyzing the command sent by the command taking module to obtain command information and sending the command information to the resource statistics module.

7. A command scheduling method, applied to the solid state disk controller of any one of claims 1 to 6, comprising:

the arbiter module arbitrates and determines the port name, function name and queue name of the host command to be responded according to the command number and data quantity of each port and function sent by the resource statistics module;

and the resource statistics module counts the command number and the data volume of each port and function according to the acquired host command, and sends the command number and the data volume of each port and function to the arbiter module.

8. The method of claim 7, wherein the solid state disk controller further comprises a command fetching module and a command parsing module, the method further comprising:

the command fetching module obtains a command from a host according to the port name, the function name and the queue name determined by the arbiter module, and sends the command to the command analyzing module;

The command analysis module analyzes the command sent by the resource statistics module to obtain command information and sends the command information to the resource statistics module.

9. A solid state disk, comprising:

the solid state disk controller recited in any one of claims 1-6;

and the at least one flash memory medium is in communication connection with the solid state disk controller.

10. A non-transitory computer readable storage medium storing computer executable instructions which, when executed by a processor, cause the processor to perform the command scheduling method of claim 7 or 8.

Images