Multi-NS flow control method and device for solid state disk, and storage medium

Abstract

The invention discloses a multi-NS traffic control method and device for a solid state disk, and a storage medium. The method comprises the following steps: configuring an initial token parameter for each IO path based on a token bucket algorithm; associating the plurality of NS with the plurality of IO paths one by one so as to determine an association relationship between each NS and each IO path; receiving a target NS input by the host and a target flow control parameter corresponding to the target NS; searching a target IO path corresponding to the target NS according to the association relationship; configuring the target flow control parameter into the target IO path, and updating the initial token parameter according to the target flow control parameter to determine a target token parameter; receiving an IO service issued by the host; and processing the IO service and carrying out flow limitation on the IO service according to the target token parameter. According to the method and the device, the resource efficiency, the performance balance and the performance stability of the solid state disk in a multi-NS scene are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of solid state drives, and in particular to a multi-NS flow control method, device and storage medium for a solid state drive. Background Art

[0002] In the field of modern storage technology, solid-state drives (SSDs) are widely used in various data-intensive application scenarios due to their high-speed read and write performance and low latency characteristics. However, with the development of technology and the diversification of application requirements, the use scenarios of multiple namespaces (NS) have become more and more common. In this context, SSDs in the prior art face a series of challenges. First, the performance imbalance between multiple NSs is a significant problem. Under the same business model, different namespaces will cause huge performance fluctuations due to resource competition. This fluctuation not only affects the performance of a single namespace, but also seriously affects the overall performance of the entire SSD. Secondly, low resource efficiency is also a problem. Due to the lack of an effective resource constraint mechanism, each namespace cannot fully utilize resources under different business models, resulting in the overall performance of the SSD disk being affected. Finally, inconsistent user experience is also a problem that cannot be ignored. Due to the competition for performance resources between namespaces, existing SSDs may not be able to provide a consistent user experience. Users may perceive that the performance fluctuates during use, especially in variable usage scenarios. This experience is particularly obvious. Therefore, existing SSD storage devices have deficiencies in processing user data access behavior in multi-NS scenarios. Summary of the invention

[0003] The embodiments of the present invention provide a multi-NS traffic control method, device and storage medium for a solid-state drive, aiming to solve the problems of uneven performance, low resource efficiency and inconsistent user experience of existing SSD storage devices when processing user data access behavior in multi-NS scenarios.

[0004] In a first aspect, an embodiment of the present invention provides a multi-NS flow control method for a solid state drive, the method comprising:

[0005] Configure initial token parameters for each IO path based on the token bucket algorithm;

[0006] Associating the multiple NSs with the multiple IO paths one by one to determine the association relationship between each NS and each IO path;

[0007] Receiving a target NS and a target flow control parameter corresponding to the target NS inputted from a host;

[0008] Find the target IO path corresponding to the target NS according to the association relationship;

[0009] configuring the target flow control parameters into the target IO path, and updating the initial token parameters according to the target flow control parameters to determine the target token parameters;

[0010] Receive IO services sent by the host;

[0011] The IO service is processed and flow control is performed on the IO service according to the target token parameter.

[0012] In a second aspect, an embodiment of the present invention further provides a multi-NS flow control device for a solid state drive, comprising a unit for executing the above method.

[0013] In a third aspect, an embodiment of the present invention further provides a computer device, which includes a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the above method when executing the computer program.

[0014] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program can implement the above method when executed by a processor.

[0015] The embodiment of the present invention provides a multi-NS flow control method, device and storage medium for a solid state drive. The method includes: configuring an initial token parameter for each IO path based on a token bucket algorithm; associating multiple NSs with multiple IO paths one by one to determine the association relationship between each NS and each IO path; receiving a target NS and a target flow control parameter corresponding to the target NS input from a host; searching for a target IO path corresponding to the target NS according to the association relationship; configuring the target flow control parameter to the target IO path, and updating the initial token parameter according to the target flow control parameter to determine the target token parameter; receiving an IO service issued by the host; processing the IO service and limiting the flow of the IO service according to the target token parameter. This application configures flow control parameters for each NS through a token bucket algorithm, so that the performance peak between each NS can be limited to a reasonable range, ensuring that the performance between multiple NSs is relatively balanced; and because each NS has a flow limit, there is no malicious competition for performance resources between the NSs, and the resources are fully utilized, thereby improving the overall performance of the solid-state drive; and performance isolation is achieved between each NS, and the NS cannot occupy the bandwidth of other NSs. The user will clearly perceive the stability of the performance, avoid erratic performance perception, improve performance consistency, and improve user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying any creative work.

[0017] Figure 1 A schematic diagram of a flow chart of a multi-NS flow control method for a solid state drive provided by an embodiment of the present invention;

[0018] Figure 2 A logical schematic diagram of a multi-NS flow control method for a solid state drive provided by an embodiment of the present invention;

[0019] Figure 3 A schematic block diagram of a multi-NS flow control device for a solid state drive provided by an embodiment of the present invention;

[0020] Figure 4 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0021] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0022] It should be understood that when used in this specification and the appended claims, the terms "include" and "comprises" indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0023] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0024] It should be further understood that the term "and / or" used in the present description and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0025] As used in this specification and the appended claims, the term "if" may be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if [described condition or event] is detected" may be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0026] In order to facilitate understanding of the embodiments of the present invention, the terms appearing below are first explained accordingly.

[0027] The Token Bucket Algorithm (TBA) is a flow control and rate limiting algorithm. The Token Bucket Algorithm controls the data transmission rate through a "bucket" that stores a certain number of "tokens". Each token represents the sending permission of a data packet. Tokens are generated at a fixed rate. The sending of data packets requires the consumption of tokens. If there are no tokens in the bucket, the data packet needs to wait until a token is available. The basic working principle of the Token Bucket Algorithm includes the generation and consumption of tokens and the judgment and processing of data packets. Token generation: The system adds tokens to the bucket at a fixed rate (such as r tokens per second). The bucket has a maximum capacity limit. When the bucket is full, the newly added tokens will be discarded or ignored. Token consumption: Whenever a data packet is sent, the corresponding number of tokens is removed from the bucket. The number of tokens is related to the size of the data packet. For example, a data packet of n bytes may require the consumption of n tokens. Data packet judgment and processing: If the number of tokens in the bucket can meet the demand for tokens by the data packet, the data packet will be output; otherwise, it will be discarded or processed in other ways (such as queuing).

[0028] NS refers to Name space. In SSD technology, especially those that follow the NVMe standard, a namespace is a logical storage unit. Each namespace can be regarded as an independent partition or volume on the SSD. It can have its own size, configuration, and attributes, and can be physically or logically isolated from other namespaces. In a shared SSD environment, namespaces can provide independent logical spaces for different tenants to avoid data conflicts and interference, and each namespace can perform encryption operations independently, thereby improving data security.

[0029] Firmware refers to Firmware, FW, also known as disk. Firmware is software embedded in hardware devices, which provides basic control and initialization functions for hardware. Firmware is usually stored in non-volatile memory (such as ROM, EEPROM, flash memory) to ensure that the device can retain its content after power failure. The main function of firmware is to provide the most basic instruction set for the hardware, so that the device can start and communicate with other system components. Firmware is mainly used for initializing hardware, low-level control, providing interfaces, and updating and maintenance. Among them, initializing hardware: The firmware is responsible for executing the initialization program when the device starts, setting hardware parameters, checking the hardware status, and preparing the operating environment for the operating system or other advanced software. Low-level control: The firmware interacts directly with the hardware and manages the operation of the hardware, such as reading and writing data, handling interrupts, controlling peripherals, etc. It is a bridge between the hardware and the operating system. Providing interfaces: The firmware usually provides a set of APIs (application programming interfaces) for the operating system or application to call to achieve control and management of the hardware. Update and maintenance: The firmware can be updated to fix vulnerabilities, improve performance, add new features, or solve compatibility issues. Manufacturers usually release firmware updates, and users can update them through the tools or management interfaces that come with the device. In general, firmware is the operating system and control center of the SSD, acting as a communication bridge between hardware and software to ensure that the SSD can perform various operations correctly.

[0030] Chip, the chip in this embodiment refers to the chip in the solid-state drive, which is the core component of the solid-state drive and is responsible for managing all operations related to data storage and transmission. Its main work content includes I / O operation management (data communication with the host and processing read and write commands from the host) and firmware algorithm execution.

[0031] Traditional traffic control methods rely on upper-layer applications, which makes development difficult, unresponsive, and unable to effectively predict and adapt to user access needs, resulting in reduced data access efficiency and user experience in actual use. Therefore, a mechanism is needed to implement traffic control for each namespace at the hardware level to ensure effective resource utilization and performance stability. Figure 1 , Figure 1 1 is a flow chart of a multi-NS flow control method for a solid state drive provided by an embodiment of the present invention. The multi-NS flow control method for a solid state drive (SSD) is described in detail below. Figure 1 As shown, the method includes the following steps S110-S170.

[0032] S110, configuring initial token parameters for each IO path based on the token bucket algorithm;

[0033] In this embodiment, the token bucket algorithm is a flow control mechanism, which sets a "bucket" of fixed capacity and adds tokens to the bucket at a constant rate. The specific principle mechanism has been described in the previous text and will not be repeated here. The IO path, also known as iopath, is the input / output path, which is the channel for internal transmission of the solid-state hard disk SSD, responsible for transmitting the read and write requests sent by the host to the corresponding namespace and processing these requests. The initial token parameter is the default token bucket parameter used to limit the flow. The token parameter can include multiple parameters, such as bucket depth, filling cycle, and single filling number. Specifically, the initial token parameter is configured for each IO path based on the token bucket algorithm. Through the token bucket algorithm, the rate limit of each IO path can be achieved. Because the principle of the token bucket algorithm is to add tokens to the bucket at a constant rate through the system, when a request needs to be processed, a token is taken out of the bucket. When there is no token in the bucket, the request is rejected and waits for the addition of tokens until the request is processed when there is a sufficient number of tokens. Therefore, the flow limit of the IO path is achieved based on the principle of the token bucket algorithm. Exemplarily, the token bucket algorithm is implemented at the SSD chip level, a token bucket is configured for each I / O path (iopath), and the initial token parameters are set according to the default policy. These parameters can be preset according to the hardware characteristics of the SSD, and can also be changed by the firmware (FW) when needed later. For example, assuming that the SSD device has 4 IO paths, the initial token parameters of each IO path are configured as follows: bucket depth of 10,000 tokens, filling cycle of 1 second, and single filling of 1,000 tokens. In this way, each IO path can process up to 10,000 IO operations per second. By configuring the initial token parameters for each IO path, precise control of the IO path inside the SSD is achieved, which lays the foundation for subsequent multi-NS traffic control and helps to maintain performance stability and predictability in a complex multi-NS environment.

[0034] In one embodiment, the step S110 includes: S111 - S112.

[0035] S111, sending token parameter configuration instructions to the chip through firmware;

[0036] S112. Configure initial token parameters for each IO path through the chip according to the token parameter configuration instruction, wherein each IO path is configured with multiple token buckets, each of the token buckets corresponds to a different type of flow control type, and the flow control indicators configured corresponding to each token bucket include bucket depth, filling cycle and single filling number, and define the number of tokens required for each unit of data in each token bucket.

[0037] In this embodiment, the flow control types include read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, and read-write iops, where iops represents the unit of the number of input / output operations that can be completed per second. That is, an IO path is configured with six token buckets, and the six token buckets correspond to the six flow control types of read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, and read-write iops. Each IO path implements 6 types of token buckets to control the peak rates of the 6 flow control types. Iops is the performance unit that the IO random access model focuses on, which represents the unit of the number of input / output operations that can be completed per second. It reflects the ability of the storage device to process read and write requests. Among them, read bandwidth refers to limiting the read operation bandwidth of the namespace (such as MB / s); write bandwidth refers to limiting the write operation bandwidth of the namespace (such as MB / s); read-write bandwidth refers to limiting the read and write operation bandwidth of the namespace at the same time; read iops refers to limiting the number of input / output operations (iops) that can be completed per second for the read operation of the namespace; write iops refers to limiting the number of input / output operations (iops) that can be completed per second for the write operation of the namespace; read-write iops refers to limiting the number of input / output operations (iops) that can be completed per second for the read and write operations of the namespace at the same time; the number of tokens consumed per unit of data refers to defining how many tokens are consumed per unit of data (such as 1 byte or 1 iops), which is used to calculate specific flow control.

[0038] Specifically, the chip receives the token parameter configuration instructions sent by the firmware and configures six token buckets for each I / O path, each token bucket corresponding to a flow control type. For each token bucket, the chip sets the initial bucket depth, filling cycle and single filling number according to the default configuration, and defines the number of tokens consumed per unit of data, achieving precise control of various data flows (including read and write bandwidth and iops).

[0039] Exemplarily, assume that there are two IO paths in an SSD, which are used to handle data transmission requirements from different applications. According to the method of this embodiment, the chip first configures six token buckets for the two paths respectively, and each bucket corresponds to a flow control type (read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, read-write iops). For the first IO path, assume that the token bucket parameters configured are as follows: Read bandwidth bucket: bucket depth 1000, fill cycle 1 second, single fill 10 tokens; each MB or iops of data consumes 1 token. Write bandwidth bucket: bucket depth 800, fill cycle 1.5 seconds, single fill 8 tokens; each MB or iops of data consumes 1.2 tokens; other bucket parameters are similar. For the second IO path, read iops: bucket depth = 7000, fill cycle = 0.5 seconds, single fill number = 3500, 1 token is consumed per MB or iops; write iops: bucket depth = 5000, fill cycle = 0.5 seconds, single fill number = 2500, 1 token is consumed per MB or iops; other bucket parameters are similar.

[0040] By configuring six independent token buckets for each IO path, corresponding to six different flow control types, refined management and optimization of internal data flows are achieved, thereby improving resource utilization.

[0041] S120, associating the plurality of NSs with the plurality of IO paths one by one to determine an association relationship between each NS and each IO path;

[0042] In this embodiment, NS (namespace) refers to a logical storage unit in an SSD, similar to a partition in a traditional hard disk. Each namespace can have its own size, configuration, and attributes, and can be physically or logically isolated from other namespaces. In a multi-namespace (NS) environment, I / O requests of different namespaces need to be managed independently to ensure performance isolation and fair allocation of resources. However, in the traditional SSD design, multiple namespaces share the same I / O path, resulting in performance competition and resource waste. Therefore, a mechanism is needed to associate each namespace with an independent I / O path to ensure that the I / O requests of each namespace can be processed through a dedicated path. Specifically, the association relationship between NS and IO path is established through firmware, and each NS corresponds to each IO path one by one. The establishment of the association relationship can be, for example, in the form of mapping association, foreign key association, and index association, which is not limited here. By associating multiple namespaces with multiple I / O paths one by one, SSD can realize independent processing of I / O requests of each namespace, avoiding performance interference between different namespaces. This design not only improves the flexibility and security of the SSD, but also makes resource allocation between different namespaces more reasonable, ensuring performance balance and consistency of user experience.

[0043] In one embodiment, the step S120 includes: S121-S122.

[0044] S121, obtaining, through firmware, an NS identifier corresponding to each NS and a path identifier corresponding to each IO path;

[0045] S122. Map the NS identifier and the path identifier one by one through firmware to determine a mapping relationship between the NS and the IO path.

[0046] In this embodiment, the one-to-one mapping relationship between NS and I / O path is implemented by firmware (FW). Specifically, FW will assign a unique NS identifier, i.e., NSID, to each namespace, and bind it to the path identifier of the corresponding I / O path, i.e., iopath ID. This binding relationship can be implemented through a configuration table or a mapping table to ensure that the I / O request of each namespace can be processed through a dedicated I / O path. Specifically, multiple NSs are associated with multiple IO paths one by one, and the IO path corresponding to each NS can be determined through the mapping relationship between NSID (namespace identifier) ​​and iopath ID of the IO path. Assume that the SSD device has 3 NSs, which are mapped to 3 IO paths respectively. NS1 is mapped to IO path 1, NS2 is mapped to IO path 2, and NS3 is mapped to IO path 3. In this way, each NS has an independent IO path for processing. When a user initiates an I / O request, the firmware will find the corresponding I / O path ID according to the requested NSID, and forward the request to the corresponding I / O path for processing. For example, if a user initiates a read request to NS1, the firmware will forward the request to I / O path 1 for processing; if a user initiates a write request to NS2, the firmware will forward the request to I / O path 2 for processing. Through the mapping relationship between NS and IO path, independent control of each NS is achieved, providing a basis for the subsequent configuration of specific flow control parameters. This helps to achieve performance isolation and resource optimization in a multi-NS environment. S130, receiving the target NS input from the host and the target flow control parameters corresponding to the target NS;

[0047] In this embodiment, the target NS refers to the namespace specified by the user for which flow control configuration is required. The target flow control parameters refer to the bandwidth and iops limit values ​​specified by the user, which are used to control the performance of the namespace. These parameters can be configured through the Vendor command in the NVMe standard. In actual use, different users and applications may have different performance requirements for SSDs. In order to meet these diverse needs, the SSD needs to provide a mechanism that allows users to flexibly configure the bandwidth and iops limits of each namespace according to actual conditions. Traditional flow control methods rely on upper-layer applications, resulting in complex configuration and untimely response. Therefore, a simple and easy-to-use interface is required to enable users to directly configure the flow control parameters of each namespace. Specifically, a general NVMe command delivery interface is implemented through firmware (FW), allowing users to configure specific flow control parameters by sending Vendor commands through the host. Vendor commands, also known as vendor-specific commands, refer to commands that are defined by hardware manufacturers for specific devices or product lines and are beyond standard specifications. These commands are usually used to provide additional functions, optimize performance, debug problems, or perform certain special operations that may not be covered in the standard command set. The user can pass in NSID, flow control type (such as read bandwidth, write bandwidth, read iops, write iops, etc.) and flow control value (such as 10K iops, 500MB / s, etc.). After receiving these commands, the firmware will parse the target NS and the corresponding flow control parameters, and pass them to the chip for processing. For example, suppose the user wants to configure the read iops limit for NS1 to 10K iops and the write iops limit to 5K iops. The user can send the following configuration to the SSD through the NVMe Vendor command: NSID: 1; flow control type: read iops; flow control value: 10K iops; flow control type: write iops; flow control value: 5K iops. After receiving these commands, the firmware will parse the target NS (NS1) and its corresponding flow control parameters, and pass these parameters to the chip for processing. By providing a simple vendor command interface, users can easily configure the flow control parameters of each namespace without modifying the upper-layer application code. This design not only reduces the development difficulty, but also improves the flexibility and scalability of the system, allowing SSD to better adapt to different application scenarios and user needs.

[0048] S140, searching for a target IO path corresponding to the target NS according to the association relationship;

[0049] In this embodiment, the target IO path refers to the I / O path corresponding to the target namespace, which is responsible for processing all I / O requests in the namespace. After receiving the flow control parameters configured by the user, the SSD needs to be able to quickly find the I / O path corresponding to the target namespace so that the flow control parameters can be applied to the correct path. Traditional flow control methods rely on upper-layer applications, resulting in a complex and inefficient search process. Therefore, an efficient mechanism is needed to quickly locate the target I / O path at the firmware level to ensure that the flow control configuration takes effect in a timely manner. Specifically, the firmware (FW) searches for the target I / O path corresponding to the target NS based on the established mapping relationship between the NSID and the iopath ID of the I / O path. Specifically, the firmware will maintain a mapping table from NSID to I / O path ID internally. When receiving the flow control configuration command issued by the user, the firmware will search for the corresponding I / O path ID based on the NSID in the command, and pass the flow control parameters to the chip for processing. For example, suppose the user configures the read iops limit for NS1 to be 10K iops. After receiving the command, the firmware will search the mapping table according to NSID = 1 and find the corresponding I / O path ID = 1. Then, the firmware will pass the configuration of the read iops limit to 10K iops to the chip and apply it to I / O path 1. By implementing an efficient search mechanism at the firmware level, the SSD can quickly locate the target I / O path and ensure that the flow control configuration takes effect in a timely manner. This design not only improves the system's response speed, but also simplifies the process of flow control configuration, allowing users to more conveniently manage the performance of each namespace.

[0050] S150, configuring the target flow control parameters into the target IO path, and updating the initial token parameters according to the target flow control parameters to determine the target token parameters;

[0051] In this embodiment, the target flow control parameters refer to the bandwidth and iops limit values ​​specified by the user, which are used to control the performance of the target namespace. The target token parameters refer to the token bucket parameters updated according to the flow control parameters configured by the user, ensuring the accuracy and effectiveness of the flow control configuration. After receiving the flow control parameters configured by the user, the SSD needs to be able to adjust the token bucket parameters of the target I / O path according to these parameters to ensure the accuracy and effectiveness of the flow control configuration. However, the fixed token parameters make it impossible to flexibly respond to different user needs. Therefore, a mechanism is required to update the token bucket parameters at runtime to ensure the accuracy and customization of the flow control configuration. After the chip receives the target flow control parameters passed by the firmware, it adjusts the token bucket parameters of the target I / O path according to these parameters. Specifically, the chip converts the flow control value into parameters such as the bucket depth, filling cycle, and single filling number of the token bucket. For example, if the user configures the read iops limit to 10Kiops, the chip can configure the bucket depth of the token bucket to 10000, the filling cycle to 0.5 seconds, and the single filling number to 5000 to meet the maximum processing business limit of about 10Kiops. By updating the token bucket parameters, the SSD can flexibly respond to different user needs and ensure the accuracy and effectiveness of the flow control configuration. This design not only improves the flexibility of the system, but also enhances the real-time performance of the flow control mechanism, allowing the SSD to better adapt to changing usage scenarios and user needs.

[0052] In one embodiment, the step S150 includes: S151-S152.

[0053] S151, receiving, by the chip, the target flow control parameters sent by the firmware, wherein the target flow control parameters include the flow control type and the flow control peak value;

[0054] S152. Determine the target token bucket according to the target flow control type through the chip, and calculate and update the bucket depth, the filling period and the single filling number in the initial token parameters corresponding to the target token bucket according to the target flow control peak value to obtain the target token parameters.

[0055] In this embodiment, the target flow control parameters are used to configure the flow control of each I / O path, which includes the flow control type and the flow control peak value. The definition of the flow control type is the specific traffic category that needs to be controlled, such as read bandwidth, write bandwidth, read iops, write iops, etc. The definition of the flow control peak value is the limit value of the flow control type, such as the maximum bandwidth (MB / s) or the maximum iops. The target token parameter is a new parameter obtained by calculating and updating the initial token parameter according to the flow control peak value configured by the user. Specifically, the firmware receives the target flow control parameters (including flow control type and flow control peak value) issued by the user through the NVMe Vendor command, and passes these parameters to the chip. The chip finds the corresponding target token bucket in the six pre-configured token buckets according to the received target flow control type. For example, if the target flow control type is "read bandwidth", the corresponding read bandwidth token bucket is selected. According to the target flow control peak value, the chip recalculates the bucket depth, filling cycle, and single filling number of the target token bucket to ensure that it meets the new flow control requirements. The specific formula is as follows: Bucket depth = flow control peak value × number of single fills in the filling cycle = flow control peak value × number of fills per unit time. For example, assuming that the user configures a read bandwidth of 500MB / s and a filling cycle of 1 second, the bucket depth should be set to 500 (MB / s) × 1s = 500 tokens. The chip applies the updated target token parameters to the target token bucket to ensure that subsequent I / O requests can be executed according to the new flow control policy. Through this embodiment, the chip can adjust the parameters of the token bucket according to the target flow control parameters issued by the firmware to adapt to different flow control requirements, thereby improving the flexibility and response speed of the system; and by accurately calculating and updating the parameters of the token bucket, precise control of the flow can be achieved to ensure that the flow does not exceed the set peak value, thereby protecting system resources from being overloaded; in addition, through reasonable flow control, problems such as system performance degradation or resource exhaustion caused by excessive flow can be avoided, thereby optimizing the overall performance of the system.

[0056] S160, receiving the IO service sent by the host;

[0057] In this embodiment, IO services refer to I / O requests from the host, including read requests and write requests. Specifically, an interface for receiving and processing IO services is implemented in the SSD firmware, and the received IO services are distributed to the corresponding IO path for processing according to the type of IO services received. Assuming that the host sends a sequential read service to NS2, after receiving the service, the SSD firmware distributes it to IO path 2 for processing. By receiving and processing the IO services sent by the host, the normal operation of the SSD device is achieved.

[0058] S170: Process the IO service and limit the flow of the IO service according to the target token parameters.

[0059] In this embodiment, after receiving the I / O service, the SSD needs to be able to limit the flow of the I / O request according to the configured flow control parameters to ensure that the performance of each namespace meets expectations. The traditional flow control method relies on the upper-layer application, resulting in untimely response to the flow limit and inability to effectively respond to sudden I / O requests. Therefore, a mechanism is needed to monitor the flow of I / O requests in real time at the hardware level and adjust it according to the token bucket parameters to ensure the accuracy and effectiveness of the flow limit. Specifically, when the chip processes the I / O service, it will limit the flow of the I / O request according to the target token bucket parameters of the target I / O path. Specifically, when an I / O request arrives, the chip will check whether there are enough tokens in the token bucket. If there are, the request is allowed to pass and consume the corresponding number of tokens; if not, the request is rejected or delayed until there are enough tokens available. In this way, the chip can monitor the flow of I / O requests in real time at the hardware level and adjust it according to the token bucket parameters to ensure the accuracy and effectiveness of the flow limit. For example, suppose that when processing the sequential read service of NS2, there are not enough tokens in the token bucket of IO path 2. At this time, some read requests are rejected until there are enough tokens in the bucket. In this way, the bandwidth and iops of NS2 are ensured not to exceed the configured limit value. By implementing traffic restrictions on I / O services at the hardware level, the SSD can efficiently process I / O requests from the host while ensuring that the performance of each namespace meets expectations. This design not only improves the response speed of the system, but also enhances the effectiveness of the flow control mechanism, allowing the SSD to better adapt to changing usage scenarios and user needs. In addition, by monitoring the traffic of I / O requests in real time, the SSD can promptly detect and process sudden I / O requests to ensure the stability of the system and the consistency of user experience. In short, by limiting the traffic of IO services, precise control of the specified NS is achieved, malicious competition for performance resources is avoided, and the overall performance and user experience of the SSD device are improved.

[0060] In one embodiment, the step S170 includes: S171-S174.

[0061] S171, the firmware searches for the corresponding target IO path according to the target NS corresponding to the IO service and the association relationship;

[0062] S172, judging by the chip whether the number of tokens in the token bucket of the target IO path meets a release condition based on the target token parameter;

[0063] S173. If the release condition is met, the IO service is executed;

[0064] S174: If the release condition is not met, intercept the IO service, and wait until there are enough tokens in the token bucket before executing the IO service.

[0065] In this embodiment, the firmware first quickly locates the target IO path that the service should take based on the target NS to which the IO service belongs and the pre-established association relationship. After the chip receives the I / O request of the IO service, the chip checks whether there are enough tokens in the token bucket of the target I / O path to meet the release conditions based on the target token parameters. If there are enough tokens in the token bucket, the I / O request is allowed to pass, and the chip directly processes and executes the IO service and consumes a corresponding number of tokens. If there are not enough tokens in the token bucket, the chip intercepts the I / O request of the IO service and waits until there are enough tokens in the token bucket before executing the request.

[0066] In one embodiment, the S174 also includes: adding tokens to the token bucket according to the filling cycle and the single filling number; returning to the step of judging whether the number of tokens in the token bucket meets the release condition. Specifically, when the IO service is intercepted, tokens are added to the token bucket according to the filling cycle (i.e., the time interval for token generation) and the single filling number (i.e., the number of tokens generated and added to the token bucket each time). This mechanism ensures that the number of tokens in the token bucket can gradually increase at a predetermined rate. After the token is added to the token bucket, it will return to the step of judging whether the number of tokens in the token bucket meets the release condition. This cyclic judgment process will continue until the number of tokens in the token bucket reaches or exceeds the minimum number of tokens required to execute the intercepted IO service, at which time the IO service will be released for execution. Through the above steps, this embodiment can achieve precise flow control of I / O requests at the hardware level, ensuring that the performance of each namespace meets the preset bandwidth and iops limits. This design not only improves the response speed of the system, but also enhances the effectiveness of the flow control mechanism, so that the SSD can better adapt to changing usage scenarios and user needs.

[0067] For example, assume that the user configures the read iops limit of 10K iops and the write iops limit of 5K iops for the namespace NS1. After receiving these configurations, the chip sets the bucket depth of the token bucket to 10000 (read), the fill cycle to 0.5 seconds, and the number of single fills to 5000 (read). For write iops, the corresponding parameters can be set to bucket depth 5000, fill cycle 0.5 seconds, and single fill number 2500. The host sends a large number of read requests and a small number of write requests to NS1. The firmware finds the corresponding target I / O path (I / O path ID = 1) based on the target NS (NS1) of the request and the pre-established association. For a read request, the chip checks the number of tokens in the token bucket. Assume that there are 8000 tokens in the current bucket, and the read request consumes 1000 tokens. Since there are enough tokens in the bucket, the chip allows the request to pass and reduces the number of tokens in the bucket to 7000. For a write request, suppose there are 4000 tokens in the current bucket, and a write request consumes 500 tokens. Similarly, since there are enough tokens in the bucket, the chip allows the request to pass and reduces the number of tokens in the bucket to 3500. If a read request arrives later, but suppose there are only 3000 tokens left in the bucket at this time, and the request consumes 5000 tokens. Since there are not enough tokens in the bucket, the chip will intercept the request and wait for the next filling cycle to arrive (for example, 0.5 seconds later), when 5000 tokens are added to the bucket and the number reaches 8000 tokens, and then execute the request. In this way, the read iops limit of NS1 is precisely controlled at around 10K iops, and the write iops limit is controlled at around 5K iops, ensuring the stability of performance and the consistency of user experience. At the same time, this design also avoids resource contention between different namespaces and optimizes the overall resource utilization of the SSD.

[0068] For ease of understanding, further Figure 2 refer to, Figure 2 The entire flow control process includes: 1. The chip implements the iopath path of flow control through the token bucket algorithm; 2. The firmware version implements the mapping relationship between NS and iopath; 3. The vendor command configures the bandwidth and iops flow control peak of the specified NS; 4. Find the corresponding iopath according to the NS; 5. The flow control peak is configured to the iopath of the chip; 6. Send IO services; 7. Limit according to the configured flow control peak.

[0069] In other embodiments, the method of the embodiment of the present invention can also be extended to map to different NMVE structural divisions such as Subsystem / Domain / NVMSet / Endurance Group, so as to achieve different levels of traffic control capabilities. This traffic control mechanism is not only applicable to namespaces (NS), but can also be applied to other higher-level or finer-grained structures mentioned above, and can achieve more accurate traffic management and performance optimization at all levels, which can better adapt to various complex application scenarios, while improving system stability and resource utilization.

[0070] In summary, through this embodiment, the flow control size can be flexibly configured, the performance utilization of SSD disks by different users and applications can be limited, the use of storage resources can be optimized, and energy consumption can be reduced. In particular, performance isolation between NSs can be achieved, and different users and applications do not affect each other. In addition, it can also adapt to virtualized services and provide users with customized flow control experience.

[0071] Figure 3 FIG. 2 is a schematic block diagram of a multi-NS flow control device 200 for a solid state drive provided by an embodiment of the present invention. Figure 3 As shown, corresponding to the above multi-NS flow control method for a solid state drive, the present invention also provides a multi-NS flow control device 200 for a solid state drive. The multi-NS flow control device 200 for a solid state drive includes a unit for executing the multi-NS flow control method for a solid state drive, and the device can be configured in a solid state drive. Specifically, please refer to Figure 3 The multi-NS flow control device 200 of the solid state drive includes: an initial configuration unit 201, an association unit 202, a parameter input unit 203, a search unit 204, an update unit 205, an IO sending unit 206 and a flow restriction unit 207.

[0072] Among them, the initial configuration unit 201 is used to configure the initial token parameters for each IO path based on the token bucket algorithm; the association unit 202 is used to associate multiple NSs with multiple IO paths one by one to determine the association relationship between each NS and each IO path; the parameter input unit 203 is used to receive the target NS and the target flow control parameters corresponding to the target NS input from the host; the search unit 204 is used to search for the target IO path corresponding to the target NS according to the association relationship; the update unit 205 is used to configure the target flow control parameters to the target IO path, and update the initial token parameters according to the target flow control parameters to determine the target token parameters; the IO sending unit 206 is used to receive the IO service sent by the host; the flow limitation unit 207 is used to process the IO service and limit the flow of the IO service according to the target token parameters.

[0073] In one embodiment, the initial configuration unit 201 includes: an instruction issuing unit and a configuration unit.

[0074] Among them, the instruction issuing unit is used to issue token parameter configuration instructions to the chip through the firmware; the configuration unit is used to configure the initial token parameters for each IO path according to the token parameter configuration instructions through the chip. Among them, each IO path is configured with multiple token buckets, each of the token buckets corresponds to a different type of flow control type, and the flow control indicators configured corresponding to each token bucket include bucket depth, filling cycle and single filling number, and define the number of tokens consumed per unit of data in each token bucket. The flow control types include read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, and read-write iops, wherein iops represents the unit of the number of input / output operations that can be completed per second.

[0075] In one embodiment, the association unit 202 includes: an ID acquisition unit and a mapping unit.

[0076] Among them, the ID acquisition unit is used to obtain the NS identifier corresponding to each NS and the path identifier corresponding to each IO path through the firmware; the mapping unit is used to map the NS identifier and the path identifier one by one through the firmware to determine the mapping relationship between the NS and the IO path.

[0077] In one embodiment, the updating unit 205 includes: a parameter receiving unit and a calculation unit

[0078] Among them, the parameter receiving unit is used for receiving the target flow control parameters issued by the firmware by the chip, wherein the target flow control parameters include the flow control type and the flow control peak value; the calculation unit is used to determine the target token bucket according to the target flow control type through the chip, and calculate and update the bucket depth, the filling period and the single filling number in the initial token parameters corresponding to the target token bucket according to the target flow control peak value to obtain the target token parameters.

[0079] In one embodiment, the traffic limiting unit 207 includes: a service searching unit, a judging unit, a releasing unit and an intercepting unit.

[0080] Among them, the service search unit is used for the firmware to search the corresponding target IO path according to the target NS corresponding to the IO service and the association relationship; the judgment unit is used to judge whether the number of tokens in the token bucket of the target IO path meets the release condition based on the target token parameter through the chip; the release unit is used to execute the IO service if the release condition is met; the interception unit is used to intercept the IO service if the release condition is not met, and wait until there are enough tokens in the token bucket before executing the IO service. Among them, tokens are added to the token bucket according to the filling cycle and the single filling number; return to the step of judging whether the number of tokens in the token bucket meets the release condition.

[0081] The multi-NS flow control device of the solid state hard disk can be implemented in the form of a computer program. The computer program can be used in Figure 4 Runs on the computer device shown.

[0082] See also Figure 4 , Figure 4 300 is a schematic block diagram of a computer device provided by an embodiment of the present invention. The computer device 300 is a solid state hard disk.

[0083] See also Figure 4 The computer device 300 includes a processor 302 , a memory and a network interface 305 connected via a system bus 301 , wherein the memory may include a non-volatile storage medium 303 and an internal memory 304 .

[0084] The non-volatile storage medium 303 can store an operating system 3031 and a computer program 3032. When the computer program 3032 is executed, the processor 302 can execute a multi-NS flow control method for a solid state drive.

[0085] The processor 302 is used to provide computing and control capabilities to support the operation of the entire computer device 300 .

[0086] The internal memory 304 provides an environment for the operation of the computer program 3032 in the non-volatile storage medium 303. When the computer program 3032 is executed by the processor 302, the processor 302 can execute a multi-NS flow control method for a solid state drive.

[0087] The network interface 305 is used to communicate with other devices over the network. Figure 4The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present invention, and does not constitute a limitation on the computer device 300 to which the solution of the present invention is applied. The specific computer device 300 may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0088] The processor 302 is used to run a computer program 3032 stored in the memory to implement any embodiment of the multi-NS flow control method for the solid state drive.

[0089] It should be understood that in the embodiment of the present invention, the processor 302 may be a central processing unit (CPU), and the processor 302 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0090] It is understood by those skilled in the art that all or part of the processes in the method for implementing the above embodiment can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiment of the above method.

[0091] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program. When the computer program is executed by a processor, the processor executes any embodiment of the multi-NS flow control method of the solid state drive.

[0092] The storage medium may be a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk, etc., which are computer-readable storage media that can store program codes.

[0093] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0094] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of each unit is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0095] The steps in the method of the embodiment of the present invention can be adjusted in order, combined and deleted according to actual needs. The units in the device of the embodiment of the present invention can be combined, divided and deleted according to actual needs. In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0096] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions for a computer device to execute all or part of the steps of the method described in each embodiment of the present invention.

[0097] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0098] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

[0099] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A multi-NS flow control method for a solid state drive, characterized in that: The method comprises: Configure initial token parameters for each IO path based on the token bucket algorithm; Associating the multiple NSs with the multiple IO paths one by one to determine the association relationship between each NS and each IO path; Receiving a target NS and a target flow control parameter corresponding to the target NS inputted from a host; Find the target IO path corresponding to the target NS according to the association relationship; configuring the target flow control parameters into the target IO path, and updating the initial token parameters according to the target flow control parameters to determine the target token parameters; Receive IO services sent by the host; The IO service is processed and flow control is performed on the IO service according to the target token parameter.

2. The method according to claim 1, characterized in that The step of configuring initial token parameters for each IO path based on the token bucket algorithm includes: Send token parameter configuration instructions to the chip through firmware; The chip configures initial token parameters for each IO path according to the token parameter configuration instruction, wherein each IO path is configured with multiple token buckets, each of the token buckets corresponds to a different type of flow control type, and the flow control indicators configured corresponding to each token bucket include bucket depth, filling cycle and single filling number, and define the number of tokens required for each unit of data in each token bucket.

3. The method according to claim 2, characterized in that The flow control types include read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, and read-write iops, where iops represents the unit of the number of input / output operations that can be completed per second.

4. The method according to claim 2, characterized in that: The step of configuring the target flow control parameters into the target IO path and updating the initial token parameters according to the target flow control parameters to determine the target token parameters includes: The chip receives the target flow control parameters sent by the firmware, wherein the target flow control parameters include the flow control type and the flow control peak value; The chip determines the target token bucket according to the target flow control type, and calculates and updates the bucket depth, the filling period and the single filling number in the initial token parameters corresponding to the target token bucket according to the target flow control peak value to obtain the target token parameters.

5. The method according to claim 2, characterized in that: The step of processing the IO service and limiting the flow of the IO service according to the target token parameter includes: The firmware searches for the corresponding target IO path according to the target NS corresponding to the IO service and the association relationship; Determining, by the chip based on the target token parameter, whether the number of tokens in the token bucket of the target IO path meets a release condition; If the release condition is met, the IO service is executed; If the release condition is not met, the IO service is intercepted, and the IO service is executed when there is a sufficient number of tokens in the token bucket.

6. The method according to claim 5, characterized in that The step of intercepting the IO service and waiting for the token bucket to have enough tokens before executing the IO service comprises: Add tokens to the token bucket according to the filling cycle and the single filling number; Return to the step of determining whether the number of tokens in the token bucket meets the release condition.

7. The method according to any one of claims 1 to 6, characterized in that: The step of associating the plurality of NSs with the plurality of IO paths one by one to determine the association relationship between each NS and each IO path comprises: Obtain the NS identifier corresponding to each NS and the path identifier corresponding to each IO path through the firmware; The NS identifier and the path identifier are mapped one by one through firmware to determine a mapping relationship between the NS and the IO path.

8. A multi-NS flow control device for a solid state drive, characterized in that: The method comprises a unit for executing the method according to any one of claims 1 to 7.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 can be implemented.

Images