Method, device and storage medium for multi-namespace flow control of solid state drive

Abstract

The application discloses a kind of solid state disk's multiple NS flow control method, equipment and storage medium.Therein, the method includes: based on token bucket algorithm is configured initial token parameter for each IO path;Multiple NS and multiple IO paths are respectively associated one by one to determine the association between each NS and each IO path;Receiving target NS from host input and the target flow control parameter corresponding to the target NS;According to the association, find the target IO path corresponding to the target NS;The target flow control parameter is configured to the target IO path, and the initial token parameter is updated according to the target flow control parameter to determine target token parameter;Receive the IO service issued by the host;Processing the IO service and according to the target token parameter, the IO service is limited in flow. Through the application, the resource efficiency, performance balance and performance stability of solid state disk in multiple NS scenarios are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of solid state disks, and particularly relates to a multi-namespace traffic control method, device and storage medium of a solid state disk. BACKGROUND

[0002] In the field of modern storage technology, solid state disks (SSDs) are widely used in various data-intensive application scenarios due to their high read-write performance and low latency characteristics. However, with the development of technology and the diversification of application requirements, the use of multi-namespace (NS) scenarios has become more and more common. Under this background, the existing SSDs face a series of challenges. First, the performance imbalance between multiple NSs is a significant problem. Under the same business model, different namespaces will have a huge performance fluctuation due to resource contention, which not only affects the performance of a single namespace, but also seriously affects the overall performance of the entire SSD. Second, low resource efficiency is also a problem. Due to the lack of effective resource constraint mechanisms, each namespace cannot fully utilize the resources under different business models, resulting in a decrease in the overall performance of the SSD. Finally, inconsistent user experience is also a problem that cannot be ignored. Due to the competition for performance resources between different namespaces, the existing SSDs may not be able to provide consistent user experience, and users may perceive performance fluctuations during use, especially in variable use scenarios, where this experience is particularly evident. Therefore, the existing SSD storage devices have deficiencies in handling multi-NS scenarios and user data access behavior. SUMMARY

[0003] The embodiments of the present application provide a multi-namespace traffic control method, device and storage medium of a solid state disk, aiming to solve the problems of performance imbalance, low resource efficiency and inconsistent user experience of the existing SSD storage devices in handling multi-NS scenarios and user data access behavior.

[0004] In a first aspect, the embodiments of the present application provide a multi-namespace traffic control method of a solid state disk, which comprises:

[0005] configuring initial token parameters for each IO path based on a token bucket algorithm;

[0006] associating a plurality of NSs with a plurality of 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 input from a host;

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

[0009] 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;

[0010] receiving IO service issued by the host;

[0011] processing the IO service and performing flow control on the IO service according to the target token parameter.

[0012] In a second aspect, an embodiment of the present application further provides a multi-NS flow control device of a solid state disk, which comprises a unit for executing the method as described above.

[0013] In a third aspect, an embodiment of the present application further provides a computer device, which comprises a memory and a processor, the memory has a computer program stored thereon, and the processor implements the method as described above when executing the computer program.

[0014] In a fourth aspect, an embodiment of the present application further provides a computer readable storage medium, which has a computer program stored thereon, and the computer program can implement the method as described above when executed by a processor.

[0015] The embodiment of the present application provides a multi-NS flow control method, device and storage medium of a solid state disk. The method comprises the following steps: configuring initial token parameters for each IO path based on a token bucket algorithm; associating a plurality of NSs with a plurality of IO paths respectively to determine an 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 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 IO service issued by the host; processing the IO service and performing flow control on the IO service according to the target token parameter. The application configures flow control parameters for each NS through the token bucket algorithm, so that the performance peak of each NS can be limited in a reasonable range, and the performance of a plurality of NSs is relatively balanced. Moreover, since each NS is subjected to flow control, there is no malicious performance resource contention between the NSs, and the resources are fully utilized, thereby improving the overall performance of the solid state disk. In addition, performance isolation is achieved between the NSs, and a NS cannot preempt the bandwidth of other NSs, so that the user can obviously perceive the stability of the performance, avoid the performance perception being unstable, improve the consistency of the performance, and improve the user experience. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort.

[0017] Figure 1 A flowchart of a multi-namespace traffic control method of a solid state disk according to an embodiment of the present application is shown in FIG. 3.

[0018] Figure 2 A logic diagram of a multi-namespace traffic control method of a solid state disk according to an embodiment of the present application is shown in FIG. 4.

[0019] Figure 3 A schematic block diagram of a multi-namespace traffic control device of a solid state disk according to an embodiment of the present application is shown in FIG. 5.

[0020] Figure 4 A schematic block diagram of a computer device according to an embodiment of the present application is shown in FIG. 6. DETAILED DESCRIPTION

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

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

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

[0024] It should be further understood that the term "and / or" as used in the present application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations thereof.

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

[0026] In order to facilitate the understanding of the embodiments of the present application, the terms appearing in the following will be explained first.

[0027] Token Bucket Algorithm (TBA) is a flow control and rate limiting algorithm. Token Bucket Algorithm controls the sending rate of data through a "bucket", which stores a certain number of "tokens" that represent the sending authority of a data packet. Tokens are generated at a fixed rate, and the sending of a data packet requires the consumption of tokens. If there are no tokens in the bucket, the data packet needs to wait until there are tokens available. The basic working principle of Token Bucket Algorithm includes token generation, consumption, and data packet judgment and processing. 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, and when the bucket is full, the newly added tokens will be discarded or ignored. Token consumption: every time a data packet is sent, the corresponding number of tokens are removed from the bucket. The number of tokens is related to the size of the data packet, for example, an n-byte data packet may consume n tokens. Data packet judgment and processing: if the number of tokens in the bucket can meet the demand of the data packet for tokens, the data packet will be output; otherwise, it will be discarded or processed (such as queuing).

[0028] NS refers to Name space, namespace. In solid state drive SSD technology, especially those SSDs that comply with the NVMe standard, 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 space for different tenants, avoiding data conflicts and interference, and each namespace can be independently encrypted, 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), ensuring that the device can retain its content after power failure. The main role of firmware is to provide the most basic instruction set for hardware, so that the device can start and communicate with other system components. Firmware is mainly used for initializing hardware, underlying control, providing interface and updating maintenance. Among them, initializing hardware: firmware is responsible for executing initialization program when the device starts, setting hardware parameters, checking hardware status, and preparing running environment for operating system or other high-level software. Underlying control: firmware directly interacts with hardware, manages hardware operations such as reading and writing data, handling interrupts, controlling peripheral devices, etc., which is the bridge between hardware and operating system. Provide interface: firmware usually provides a set of API (application programming interface) for operating system or application to call, to realize the control and management of hardware. Update and maintenance: firmware can be updated to fix vulnerabilities, improve performance, add new functions or solve compatibility problems, manufacturers usually release firmware updates, users can update through the device's own tools or management interface. In summary, firmware is the operating system and control center of SSD, as the communication bridge between hardware and software, to ensure that SSD can correctly perform various operations.

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

[0031] The traditional traffic control method relies on the upper application, which leads to large development difficulty, unresponsive, and cannot effectively predict and adapt to the access demand of users, resulting in reduced data access efficiency and user experience in actual use. Therefore, a mechanism is needed to realize traffic control for each namespace at the hardware level, to ensure the effective use of resources and the stability of performance. Please refer to Figure 1 , Figure 1 is the flowchart of the multi-namespace traffic control method of the solid state disk provided by the embodiment of the application. The multi-NS traffic control method of the solid state disk (SSD) will be described in detail below. As Figure 1 shown, the method comprises the following steps S110-S170.

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

[0033] In the embodiment, the token bucket algorithm is a flow control mechanism that sets a fixed capacity "bucket" and adds tokens to the bucket at a constant rate. The specific principle mechanism has been described in the foregoing and will not be described again here. The IO path, also known as iopath, is an internal transmission channel of the solid state disk (SSD), which is 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 a parameter for limiting the flow of the default token bucket. The token parameter can include various parameters, such as bucket depth, filling period, and number of single filling, etc. Specifically, the initial token parameter is configured for each IO path based on the token bucket algorithm. Through the token bucket algorithm, the rate limitation 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 by the system, when a request needs to be processed, a token is taken out from the bucket, when there is no token in the bucket, the request is rejected, and the request is processed until there is enough number of tokens. Therefore, the flow limitation 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 parameter is set according to the default strategy. These parameters can be preset according to the hardware characteristics of the SSD, or can be changed and configured by the firmware (FW) as needed later. For example, assuming that the SSD device has 4 IO paths, the initial token parameter of each IO path is configured as: bucket depth 10000 tokens, filling period 1 second, and single filling 1000 tokens. In this way, each IO path can process up to 10000 IO operations per second. By configuring the initial token parameter for each IO path, accurate control of the internal IO path of the SSD is achieved, which lays a foundation for subsequent multi-NS flow control and helps to maintain the stability and predictability of performance in a complex multi-NS environment.

[0034] In an embodiment, the step S110 comprises S111-S112.

[0035] S111, issuing a token parameter configuration instruction to the chip through firmware;

[0036] S112, configuring an initial token parameter for each IO path according to the token parameter configuration instruction through the chip, wherein each IO path is configured with a plurality of token buckets, each token bucket corresponds to a different type of flow control type, and the flow control indicators corresponding to each token bucket are configured to include bucket depth, filling period, and number of single filling, and the number of tokens consumed per unit data in each token bucket is defined.

[0037] In the embodiment, the flow control types include read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, and read-write iops, where iops represents a unit of the number of input / output operations that can be completed per second. That is, the 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 six types of token buckets to control the peak rate of the six flow control types. Iops is a performance unit of an IO random access model, represents a unit of the number of input / output operations that can be completed per second, and reflects the ability of a storage device to process read and write requests. The read bandwidth refers to the read operation bandwidth (such as MB / s) of the namespace; the write bandwidth refers to the write operation bandwidth (such as MB / s) of the namespace; the read-write bandwidth refers to the read and write operation bandwidth of the namespace; the read iops refers to the number of input / output operations (iops) that can be completed per second for the read operation of the namespace; the write iops refers to the number of input / output operations (iops) that can be completed per second for the write operation of the namespace; the read-write iops refers to the number of input / output operations (iops) that can be completed per second for the read and write operations of the namespace; and the number of tokens consumed per unit of data refers to the number of tokens consumed per unit of data (such as 1 byte or 1 iops), which is used to calculate the specific flow control.

[0038] Specifically, the chip receives the token parameter configuration instruction issued by the firmware, configures six token buckets for each I / O path, and each token bucket corresponds to a flow control type. For each token bucket, the chip sets the initial bucket depth, filling period, and number of single filling according to the default configuration, and defines the number of tokens consumed per unit of data, thereby achieving accurate control of various data streams (including read-write bandwidth and iops).

[0039] For example, assume that there are two IO paths in an SSD, which are used to process data transmission requirements from different applications respectively. According to the method of the embodiment, the chip first configures six token buckets for the two paths respectively, and each bucket corresponds to one 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 configured token bucket parameters are as follows: read bandwidth bucket: bucket depth 1000, filling period 1 second, single filling 10 tokens; consume 1 token per MB or iops of data. Write bandwidth bucket: bucket depth 800, filling period 1.5 seconds, single filling 8 tokens; consume 1.2 tokens per MB or iops of data; other bucket parameters are similar. For the second IO path, read iops: bucket depth = 7000, filling period = 0.5 seconds, single filling number = 3500, consume 1 token per MB or iops; write iops: bucket depth = 5000, filling period = 0.5 seconds, single filling number = 2500, consume 1 token per MB or iops; other bucket parameters are similar.

[0040] By configuring six independent token buckets for each IO path, respectively corresponding to six different flow control types, fine management and optimization of internal data flow are achieved, and resource utilization is improved.

[0041] S120, respectively associate a plurality of NSs with a plurality of IO paths to determine the association relationship between each NS and each IO path;

[0042] In the embodiment, NS (namespace) refers to a logical storage unit in the SSD, similar to the partition in the 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, the 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 contention 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 by firmware, and each NS corresponds to one IO path, and the establishment of the association relationship can be in the form of mapping association, foreign key association, index association, which is not limited herein. By respectively associating a plurality of namespaces with a plurality of IO paths, the SSD can implement independent processing of the I / O requests of each namespace, avoiding performance interference between different namespaces. This design not only improves the flexibility and security of the solid state disk, but also makes the resource allocation between different namespaces more reasonable, ensuring the balance of performance and consistency of user experience.

[0043] In an embodiment, the step S120 comprises: S121-S122.

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

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

[0046] In the present embodiment, the one-to-one mapping relationship between the NS and the I / O path is realized by the firmware (FW). Specifically, the FW allocates a unique NS identifier, i.e., NSID, to each namespace and binds it with the path identifier of the corresponding I / O path, i.e., iopath ID. This binding relationship can be realized by a configuration table or a mapping table, ensuring that the I / O request of each namespace can be processed through the exclusive I / O path. Specifically, a plurality of NSs and a plurality of IO paths are respectively associated one by one, and through the mapping relationship between the NSID (namespace identifier) and the iopath ID of the IO path, the IO path corresponding to each NS can be determined. Assuming that the SSD device has 3 NSs, which are respectively mapped to 3 IO paths. 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 the user initiates an I / O request, the firmware will look up 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 the user initiates a read request to NS1, the firmware will forward the request to I / O path 1 for processing; if the 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 the NS and the IO path, independent control of each NS is realized, which provides a basis for subsequent configuration of specific flow control parameters. This helps to realize performance isolation and resource optimization in a multi-NS environment.

[0047] S130, receiving the target NS and the target flow control parameter corresponding to the target NS input from the host;

[0048] In this embodiment, the target NS refers to a user-specified namespace that requires flow control configuration. The target flow control parameters refer to user-specified bandwidth and iops limit values for controlling the performance of the namespace, which can be configured through Vendor commands 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, SSDs need to provide a mechanism to allow users to flexibly configure the bandwidth and iops limits of each namespace according to actual conditions. Traditional traffic control methods rely on upper-layer applications, resulting in complex configuration and delayed response. Therefore, a simple and easy-to-use interface is needed to allow users to directly configure the flow control parameters of each namespace. Specifically, a general NVMe command issuing interface is implemented through firmware (FW), allowing users to issue Vendor commands through the host to configure specific flow control parameters. Vendor commands, also known as Vendor-Specific Commands, refer to commands defined by hardware manufacturers for specific devices or product lines, beyond the standard specifications. These commands are usually used to provide additional functionality, optimize performance, debug problems, or perform certain special operations that may not be covered in the standard command set. Users can input 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 parses the target NS and corresponding flow control parameters and passes them to the chip for processing. For example, assume that the user wants to configure NS1 with a read iops limit of 10K iops and a write iops limit of 5K iops. The user can issue 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 parses the target NS (NS1) and its corresponding flow control parameters and passes 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 development difficulty but also improves system flexibility and scalability, enabling SSDs to better adapt to different application scenarios and user needs.

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

[0050] 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 of 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 in order to apply the flow control parameters to the correct path. The traditional flow control method relies on the upper application, 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 timely effectiveness of the flow control configuration. Specifically, the firmware (FW) finds the target I / O path corresponding to the target NS according to the established mapping relationship between the NSID and the iopath ID of the I / O path. Specifically, the firmware will maintain a mapping table of NSID to I / O path ID internally. When receiving the flow control configuration command issued by the user, the firmware will find the corresponding I / O path ID according to the NSID in the command, and pass the flow control parameters to the chip for processing. Illustratively, assuming that the user configures the read iops limit of NS1 to be 10K iops, after receiving the command, the firmware will find the corresponding I / O path ID=1 according to NSID=1 in the mapping table. Then, the firmware will pass the configuration of the read iops limit of 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 to ensure timely effectiveness of the flow control configuration. This design not only improves the response speed of the system, but also simplifies the process of flow control configuration, making it easier for users to manage the performance of each namespace.

[0051] S150, configure the target flow control parameter into the target IO path, and update the initial token parameter according to the target flow control parameter to determine a target token parameter;

[0052] In this embodiment, the target flow control parameter refers to the bandwidth and iops limit value specified by the user for controlling the performance of the target namespace. The target token parameter refers to the token bucket parameter updated according to the user-configured flow control parameter, ensuring the accuracy and effectiveness of the flow control configuration. After receiving the user-configured flow control parameter, the SSD needs to be able to adjust the token bucket parameter of the target I / O path according to these parameters to ensure the accuracy and effectiveness of the flow control configuration. However, fixed token parameters cannot flexibly respond to different user needs. Therefore, a mechanism is needed to update the token bucket parameter at runtime to ensure the accuracy and customization of the flow control configuration. After receiving the target flow control parameter delivered by the firmware, the chip adjusts the token bucket parameter 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 period, and single filling number of the token bucket. For example, if the user configures the read iops limit to be 10K iops, the chip can configure the bucket depth of the token bucket to be 10,000, the filling period to be 0.5 seconds, and the single filling number to be 5,000 to meet the maximum processing service limit of about 10K iops. By updating the token bucket parameter, the SSD can flexibly respond to different user needs, ensuring 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, making the SSD better adapt to changing usage scenarios and user needs.

[0053] In an embodiment, the step S150 comprises S151-S152.

[0054] S151, receiving the target flow control parameter delivered by the firmware by the chip, wherein the target flow control parameter comprises the flow control type and the flow control peak value;

[0055] S152, determining the target token bucket according to the target flow control type by the chip, and calculating and updating the bucket depth, filling period, and single filling number in the initial token parameter corresponding to the target token bucket according to the target flow control peak value to obtain the target token parameter.

[0056] In this embodiment, the target flow control parameter is 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 flow 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 updating the initial token parameter according to the user-configured flow control peak value. Specifically, the firmware receives the target flow control parameter (including the flow control type and the 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 period 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 x filling period single filling number = flow control peak value x filling number per unit time. For example, assuming that the user configures the read bandwidth to be 500 MB / s and the filling period to be 1 second, the bucket depth should be set to 500 (MB / s) x 1s = 500 tokens. The chip applies the updated target token parameter to the target token bucket to ensure that subsequent I / O requests can be executed according to the new flow control strategy. Through this embodiment, the chip can adjust the parameters of the token bucket according to the target flow control parameter issued by the firmware to adapt to different flow control requirements, improving the flexibility and response speed of the system; moreover, by accurately calculating and updating the parameters of the token bucket, accurate control of the flow can be achieved, ensuring 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 depletion caused by excessive flow can be avoided, thereby optimizing the overall performance of the system.

[0057] S160, receiving the IO service issued by the host;

[0058] In this embodiment, the IO service refers to the I / O request from the host, including read request and write request. Specifically, an interface for receiving and processing IO service is implemented in the SSD firmware, and according to the type of the received IO service, it is distributed to the corresponding IO path for processing. Assuming that the host issues a sequential read service to NS2, the SSD firmware receives the service and distributes it to IO path 2 for processing. By receiving and processing the IO service issued by the host, the normal operation of the SSD device is realized.

[0059] S170, processing the IO service and limiting the flow of the IO service according to the target token parameter.

[0060] In this embodiment, after receiving I / O traffic, the SSD needs to be able to limit the flow of I / O requests according to the configured flow control parameters, ensuring that the performance of each namespace meets the expectations. Traditional flow control methods rely on upper-layer applications, resulting in a delayed response to flow limitation and an inability to effectively handle sudden I / O requests. Therefore, a mechanism is needed to monitor I / O request traffic in real time at the hardware level and adjust it according to token bucket parameters to ensure the accuracy and effectiveness of flow limitation. Specifically, when processing I / O traffic, the chip limits the flow of I / O requests according to the target token bucket parameters of the target I / O path. Specifically, when an I / O request arrives, the chip checks whether there are enough tokens in the token bucket. If so, the request is allowed to pass and the corresponding number of tokens is consumed; 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 flow limitation. For example, assume that when processing sequential read traffic for NS2, there are not enough tokens in the token bucket of IO path 2. At this time, part of the read request is rejected until there are enough tokens in the bucket, ensuring that the bandwidth and iops of NS2 do not exceed the configured limit. By implementing flow limitation for I / O traffic at the hardware level, the SSD can efficiently handle I / O requests from the host while ensuring that the performance of each namespace meets expectations. This design not only improves system response speed but also enhances the effectiveness of the flow control mechanism, enabling the SSD to better adapt to changing usage scenarios and user needs. In addition, by monitoring the flow of I / O requests in real time, the SSD can promptly detect and handle sudden I / O requests, ensuring system stability and consistency of user experience. In summary, by limiting the flow of IO traffic, precise control of specified NS is achieved, avoiding malicious contention for performance resources, and improving the overall performance and user experience of the SSD device.

[0061] In an embodiment, the step S170 comprises S171-S174.

[0062] S171, finding the target IO path corresponding to the target NS and the association relationship according to the IO traffic by the firmware;

[0063] S172, determining whether the number of tokens in the token bucket of the target IO path meets the release condition based on the target token parameters by the chip;

[0064] S173, if the release condition is met, performing the IO traffic;

[0065] S174, if the release condition is not met, intercept the IO service, and wait for sufficient tokens in the token bucket before executing the IO service.

[0066] In this embodiment, the firmware first locates the target IO path according to the target NS to which the IO service belongs and the pre-established association relationship. After receiving the I / O request of the IO service, the chip checks whether there are sufficient tokens in the token bucket of the target I / O path based on the target token parameter. If there are sufficient 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 the corresponding number of tokens. If there are not sufficient tokens in the token bucket, the chip intercepts the I / O request of the IO service and waits for sufficient tokens in the token bucket before executing the request.

[0067] In an embodiment, the S174 further comprises: adding tokens to the token bucket according to the filling period and the single filling number; and 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 period (i.e., the time interval of 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 gradually increases at a predetermined rate. After the tokens are added to the token bucket, the step of judging whether the number of tokens in the token bucket meets the release condition is returned to. This loop of judgment continues 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 is released for execution. Through the above steps, this embodiment can realize accurate flow control of I / O requests at the hardware level, ensuring that the performance of each namespace meets the preset bandwidth and iops limit. This design not only improves the response speed of the system, but also enhances the effectiveness of the flow control mechanism, making the SSD better adapt to changing usage scenarios and user needs.

[0068] Exemplarily, it is assumed that the user configures the read iops limit of the namespace NS1 as 10K iops and the write iops limit as 5K iops. After receiving these configurations, the chip sets the bucket depth of the token bucket as 10000 (read), the filling period as 0.5 seconds, and the number of tokens filled at a time as 5000 (read). For the write iops, the corresponding parameters can be set as the bucket depth 5000, the filling period 0.5 seconds, and the number of tokens filled at a time 2500. The host issues 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) according to the target NS (NS1) of the request and the pre-established association relationship. For the read request, the chip checks the number of tokens in the token bucket. It is assumed that there are 8000 tokens in the bucket at present, and the read request needs to consume 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 the write request, it is assumed that there are 4000 tokens in the bucket at present, and the write request needs to consume 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 subsequently, but it is assumed that there are only 3000 tokens in the bucket at present, and the request needs to consume 5000 tokens. Since there are not enough tokens in the bucket, the chip intercepts the request and waits until the next filling period arrives (for example, after 0.5 seconds), and then adds 5000 tokens to the bucket to reach 8000 tokens, and then executes the request. In this way, the read iops limit of NS1 is accurately controlled at about 10K iops, and the write iops limit is controlled at about 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, optimizing the overall resource utilization of the SSD.

[0069] For ease of understanding, further provided are Figure 2 Reference, Figure 2 is a logical schematic diagram of the method of the embodiment. The entire flow control process includes: 1. The chip implements flow control of the iopath path 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 value of the specified NS; 4. The corresponding iopath is found according to the NS; 5. The flow control peak value is configured to the iopath of the chip; 6. The IO service is issued; 7. The configured flow control peak value is limited.

[0070] In other embodiments, the method of the embodiment of the present application can also extend to different NMVE structure divisions such as Subsystem / Domain / NVMSet / Endurance Group, etc., so as to realize traffic control capabilities at different levels. The traffic control mechanism is not only applicable to the namespace (NS), but also can be applied to other higher-level or more fine-grained structures mentioned above, and more accurate traffic management and performance optimization can be realized at each level to better adapt to various complex application scenarios, while improving the stability and resource utilization of the system.

[0071] In summary, through the embodiment, the flow control size can be flexibly configured, the performance utilization of the SSD disk by different users and applications is limited, the use of storage resources is optimized, the energy consumption is reduced, and especially the performance isolation between NSs is realized, different users and applications do not affect each other. In addition, it can also adapt to virtualization services and provide customized flow control experience for users.

[0072] Figure 3 is a schematic block diagram of a multi-NS traffic control device 200 of a solid state disk provided by the embodiment of the present application. As Figure 3 shown, corresponding to the above multi-namespace traffic control method of the solid state disk, the present application also provides a multi-NS traffic control device 200 of a solid state disk. The multi-NS traffic control device 200 of the solid state disk includes a unit for executing the above multi-namespace traffic control method of the solid state disk, and the device can be configured in the solid state disk. Specifically, please refer to Figure 3 , the multi-NS traffic control device 200 of the solid state disk includes an initial configuration unit 201, an association unit 202, a parameter input unit 203, a lookup unit 204, an update unit 205, an IO issuing unit 206 and a traffic limiting unit 207.

[0073] The initial configuration unit 201 is configured to configure initial token parameters for each IO path based on the token bucket algorithm; the association unit 202 is configured to associate a plurality of NSs with a plurality of IO paths one by one respectively to determine the association relationship between each NS and each IO path; the parameter input unit 203 is configured to receive a target NS and a target flow control parameter corresponding to the target NS input from a host; the lookup unit 204 is configured to look up a target IO path corresponding to the target NS according to the association relationship; the update unit 205 is configured to configure the target flow control parameter into the target IO path, and update the initial token parameters according to the target flow control parameter to determine target token parameters; the IO issuing unit 206 is configured to receive IO services issued by the host; and the traffic limiting unit 207 is configured to process the IO services and limit the traffic of the IO services according to the target token parameters.

[0074] In an embodiment, the initial configuration unit 201 comprises an instruction issuing unit and a configuration unit.

[0075] The instruction issuing unit is configured to issue a token parameter configuration instruction to the chip via firmware; and the configuration unit is configured to configure, by the chip, an initial token parameter for each IO path according to the token parameter configuration instruction, wherein each IO path is configured with a plurality of token buckets, each token bucket corresponds to a different type of flow control, and each flow control indicator corresponding to each token bucket includes a bucket depth, a filling period, and a number of single filling, and defines the number of tokens required to be consumed per unit of data in each token bucket. The flow control type includes read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops, and read-write iops, wherein iops represents the number of input / output operations per second.

[0076] In an embodiment, the association unit 202 comprises an ID obtaining unit and a mapping unit.

[0077] The ID obtaining unit is configured to obtain, by firmware, an NS identifier corresponding to each NS and a path identifier corresponding to each IO path; and the mapping unit is configured to map the NS identifier and the path identifier one by one by firmware to determine the mapping relationship between the NS and the IO path.

[0078] In an embodiment, the update unit 205 comprises a parameter receiving unit and a calculation unit

[0079] The parameter receiving unit is configured to receive, by the chip, the target flow control parameter issued by the firmware, wherein the target flow control parameter includes the flow control type and the flow control peak value; and the calculation unit is configured to determine, by the chip, a target token bucket according to the target flow control type, and calculate and update the bucket depth, the filling period, and the number of single filling in the initial token parameter corresponding to the target token bucket according to the target flow control peak value to obtain a target token parameter.

[0080] In an embodiment, the traffic limiting unit 207 comprises a service searching unit, a judgment unit, a release unit, and an interception unit.

[0081] The service searching unit is configured to search for the target IO path corresponding to the IO service according to the target NS corresponding to the IO service and the association relationship.

[0082] The multi-NS flow control device of the solid state disk can be implemented in the form of a computer program, which can run on a computer device as shown in the accompanying drawings. Figure 4 The computer device 300 is a solid state disk.

[0083] Please refer to Figure 4 , Figure 4 is a schematic block diagram of a computer device provided by an embodiment of the present application. The computer device 300 is a solid state disk.

[0084] Referring to Figure 4 , the computer device 300 includes a processor 302, a memory and a network interface 305 connected through a system bus 301, wherein the memory can include a non-volatile storage medium 303 and an internal memory 304.

[0085] 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-namespace flow control method of a solid state disk.

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

[0087] The internal memory 304 provides an environment for the execution of the computer program 3032 in the non-volatile storage medium 303, and when the computer program 3032 is executed by the processor 302, the processor 302 can execute a multi-namespace flow control method of a solid state disk.

[0088] The network interface 305 is configured to perform network communication with other devices. Those skilled in the art can understand that Figure 4The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device 300 to which the scheme of the present application is applied. The specific computer device 300 can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0089] The processor 302 is configured to run the computer program 3032 stored in the memory to implement any of the embodiments of the method for controlling traffic of multiple namespaces of a solid state disk.

[0090] It should be understood that, in the embodiments of the present application, the processor 302 can be a central processing unit (CPU), and the processor 302 can 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 gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0091] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware. 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 above-mentioned embodiments.

[0092] Therefore, the present application also provides a storage medium. The storage medium can be a computer readable storage medium. The storage medium stores a computer program. The computer program is executed by a processor to make the processor execute any of the embodiments of the method for controlling traffic of multiple namespaces of a solid state disk.

[0093] The storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk, etc. Various computer readable storage media that can store program codes.

[0094] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0095] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of each unit is only a logical function division, and actual implementation can have another division manner. For example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed.

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

[0097] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device to execute all or part of the steps of the methods described in each embodiment of the present application.

[0098] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0099] Obviously, those skilled in the art can make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, these modifications and variations of the present application are intended to be included within the scope of the claims of the present application and their equivalents.

[0100] The above merely illustrates the specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any skilled person in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements shall be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for multi-namespace traffic control of a solid state drive, characterized in that, The method comprises: configuring initial token parameters for each IO path based on a token bucket algorithm, wherein each IO path is configured with multiple token buckets, each token bucket corresponds to a different type of flow control, and the flow control indicators configured for each token bucket include bucket depth, filling period and number of single filling; associating multiple namespaces with multiple IO paths respectively to determine the association between each namespace and each IO path; receiving a target namespace input from a host and a target flow control parameter corresponding to the target namespace; finding a target IO path corresponding to the target namespace according to the association; configuring the target flow control parameter into the target IO path, wherein the target flow control parameter includes a target flow control type and a target flow control peak, and updating the initial token parameter according to the target flow control parameter to determine a target token parameter, specifically including: receiving the target flow control parameter issued by the chip receiving firmware, determining a target token bucket according to the target flow control type through the chip, and calculating and updating the bucket depth, the filling period and the number of single filling in the initial token parameter corresponding to the target token bucket according to the target flow control peak to obtain the target token parameter; receiving IO services issued by the host; processing the IO services and limiting the traffic of the IO services according to the target token parameter.

2. The method of claim 1, wherein, The step of configuring initial token parameters for each IO path based on a token bucket algorithm comprises: issuing a token parameter configuration instruction to the chip through firmware; configuring initial token parameters for each IO path through the chip according to the token parameter configuration instruction, and defining the number of tokens required for each unit of data in each token bucket.

3. The method of claim 2, wherein, The flow control type includes read bandwidth, write bandwidth, read-write bandwidth, read iops, write iops and read-write iops, wherein iops represents the number of input / output operations per second.

4. The method of claim 2, wherein, The step of processing the IO services and limiting the traffic of the IO services according to the target token parameter comprises: finding the corresponding target IO path according to the target namespace corresponding to the IO service and the association by the firmware; judging 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; if the release condition is met, executing the IO service; if the release condition is not met, intercepting the IO service and waiting for enough tokens in the token bucket before executing the IO service.

5. The method of claim 4, wherein, The step of intercepting the IO service and waiting for enough tokens in the token bucket before executing the IO service comprises: adding tokens to the token bucket according to the filling period and the number of single filling; returning to the step of judging whether the number of tokens in the token bucket meets the release condition.

6. The method according to any one of claims 1 to 5, characterized in that, The step of associating multiple namespaces with multiple IO paths respectively to determine the association between each namespace and each IO path comprises: obtaining, by the firmware, a namespace identifier corresponding to each namespace and obtaining a path identifier corresponding to each IO path; mapping, by the firmware, the namespace identifiers and the path identifiers one by one to determine a mapping relationship between the namespaces and the IO paths.

7. A multi-namespace traffic control apparatus of a solid state drive, characterized by, The computer device comprises a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method according to any one of claims 1-6.

8. A computer device, comprising: The computer device comprises a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program, when executed by a processor, can implement the method according to any one of claims 1-6.

Images