A method, device, equipment and storage medium for dynamically configuring waiting time based on disk array accelerator card

Abstract

The present invention provides a method, device, equipment and storage medium for dynamically configuring the waiting time based on a disk array acceleration card, which belongs to the technical field of RAID IO acceleration cards. The host obtains the waiting time after the control instruction is executed under multiple control instruction execution states, and trains a linear programming model; obtains the performance parameters and instruction execution state under the current control instruction execution state; inputs the obtained performance parameters and instruction execution state under the current control instruction execution state into the trained linear programming model, and predicts the waiting time after the control instruction is executed; sends the predicted waiting time after the control instruction is executed to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing a reset or shutdown operation. The present invention can avoid the problem of setting the waiting time of RAID card IO clean too large or too small, and improve the system operation efficiency.

Description

Technical Field

[0001] The present invention belongs to the technical field of RAID IO acceleration cards, and in particular relates to a method, device, equipment and storage medium for dynamically configuring waiting time based on a disk array acceleration card. Background Art

[0002] With the continuous development of information technology, the storage bandwidth requirements for data center servers are getting higher and higher. In order to improve the hard disk IO performance, an acceleration device is generally configured for the hard disk IO process, and a RAID IO acceleration card is commonly used. Generally speaking, the IO command execution process of the RAID IO acceleration card includes the IO command transmission process of the upstream and downstream NVMe interfaces, and the acceleration of the RAID algorithm execution process. When the upstream device, such as the host, performs a reset or shutdown operation on the RAID IO acceleration card, it is necessary to wait for IO clean, that is, all IO commands are executed, and then perform a real hardware reset or hard disk shutdown operation, so as to ensure that data is not lost during the reset or shutdown.

[0003] In the prior art, the RAID IO accelerator card can take out IO commands one by one from the host IO queue memory and execute them. Here, the RAID IO accelerator card can execute the IO commands, and after all IO commands have been executed, reply to the host with the execution completion information. At this time, the host can perform a reset or shutdown operation on the RAID IO accelerator card, and execute the reset or shutdown process through hardware interrupt signals and the like. However, in the prior art, due to the unreasonable setting of the IO clean waiting time, such as the waiting time may be set too small or too large, the IO commands in the IO queue have not been executed, and the reset or shutdown operation is performed, resulting in the IO engine after the reset not being in the initial state and unable to work normally. Of course, if the waiting time may be set too large, the reset or shutdown process time will be lengthened, and the host may think that the device has been hung, affecting the subsequent normal operation of the system. Summary of the invention

[0004] The present invention provides a method for dynamically configuring the waiting time based on a disk array accelerator card. The method can dynamically and accurately configure the IO clean waiting time of the disk array accelerator card, thereby ensuring a smooth transition when the system is reset or shut down, and reducing the risk of data loss and damage.

[0005] Methods include:

[0006] S101: The host sends a sample acquisition signal to the test firmware to obtain the waiting time after the control instruction is executed, the performance parameters and the instruction execution status under various control instruction execution states, and uses the waiting time after the control instruction is executed under the control instruction execution state, the performance parameters and the instruction execution status as samples to train the linear programming model;

[0007] S102: The host sends a status acquisition signal to the firmware to obtain performance parameters and instruction execution status under the current control instruction execution state;

[0008] S103: The host inputs the acquired performance parameters and instruction execution status of the current control instruction execution status into the trained linear programming model to predict the waiting time after the control instruction is executed;

[0009] S104: The host sends the predicted waiting time after the control instruction is executed to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing the reset or shutdown operation.

[0010] It should be further explained that, before step S101, the steps also include: defining host read and write performance parameters;

[0011] Configure the control instructions to the host instruction execution queue;

[0012] The firmware polls and executes control commands from the host command execution queue according to the defined host read and write performance parameters.

[0013] It should be further explained that the host read and write performance parameters include: the upper limit of the amount of data transmitted by the host interface and the upper limit of the amount of data processed by the host interface for read requests.

[0014] It should be further explained that the definition of host read and write performance parameters also includes:

[0015] An upper limit on the amount of data transmitted by the communication interface between the host and the firmware is defined, as well as an upper limit on the amount of data read requests processed by the communication interface between the host and the firmware.

[0016] It should be further explained that the method also defines an upper limit on the number of control instructions that can be transferred at one time from the host instruction execution queue; when the number of control instructions in a certain host instruction execution queue exceeds the upper limit of control instructions that can be transferred at one time, the firmware only transfers the corresponding number of control instructions, and the arbitrator controls and switches the firmware to the next host instruction execution queue to execute the transfer process.

[0017] It should be further explained that the method also defines a lower limit on the number of queue transport control instructions that can be executed from the host instruction at a single time;

[0018] When the number of control instructions in a host instruction execution queue is lower than the lower limit of a single transport control instruction, the firmware does not perform the transport operation, and the arbitrator controls and switches the firmware to the next host instruction execution queue to execute the transport process.

[0019] It is further necessary to explain that the method also defines an upper limit on the number of cache control instructions;

[0020] When the control instructions are transferred, and the number of control instructions that have not been transferred to the hardware module reaches the upper limit of the cache control instructions, the transfer of control instructions from the host is stopped.

[0021] It should be further explained that the method further includes: converting the control instruction transferred from the host into a task control block including control instruction parameters;

[0022] Transfer the task control block to the disk array.

[0023] It is further necessary to explain that the number of task control block caches is configured; the transfer from the host to the firmware memory linked list is performed based on the control instruction parameters;

[0024] Based on a preset algorithm, the linked list is converted into a sub-linked list representing the disk array control instructions and the number of data blocks under the disk array according to the disk array information;

[0025] Based on the preset algorithm and control instruction parameters, the check value of the data corresponding to the control instruction is calculated.

[0026] It should be further explained that the method further includes: the disk array algorithm engine sends the sub-link list, the number of data blocks and the check value to the disk engine;

[0027] The disk engine configures the sub-list, the number of data blocks, and the checksum value to the control queue memory corresponding to the hard disk;

[0028] Each hard disk retrieves the control instruction from the control queue memory and executes the operation from the disk array to the preset address of the hard disk according to the control instruction parameters.

[0029] It should be further explained that the method also defines an upper limit on the amount of data transmitted by the communication interface between the firmware and the hard disk, and defines an upper limit on the amount of data processed by the communication interface between the firmware and the hard disk for reading requests.

[0030] It should be further explained that step S103 also includes:

[0031] Configure different control instruction performance parameters to the test firmware;

[0032] Set a preset number of control commands and assign them to the host command execution queue;

[0033] Obtaining, from the test firmware, different performance parameters and the waiting time after the control instruction is executed under the instruction execution state;

[0034] The waiting time after all the acquired control instructions are executed is used as a training sample, and the linear programming model is trained using all the acquired training samples;

[0035] Define the actual value function based on the linear programming model: ;

[0036] Among them, x1, x2, x3, and x4 represent different performance parameters and instruction execution states respectively;

[0037] Define the hypothesis function: ;

[0038] Among them, the vector dimension k represents the slope, b represents the intercept, and h represents the predicted value;

[0039] The initial values ​​of k1, k2, k3, k4 and b are all 1;

[0040] Define the loss function: ;

[0041] Defining the optimization function , the optimization function means adjusting the values ​​of k and b so that the loss function Minimum, the optimization function implements gradient descent based on the following method,

[0042] ;

[0043] ;

[0044] in, Represents the loss function Find the partial derivative of slope k, Represents the loss function Find the partial derivative of slope b;

[0045] Weight represents the learning rate;

[0046] By continuously adjusting k and b until the loss value reaches the preset loss threshold, the linear regression function used for prediction is obtained.

[0047] It should be further explained that, in the method, a command for testing user performance parameters is defined;

[0048] Among them, the control instruction execution completion status register is polled in an endless loop with a preset sleep interval, and the total sleep waiting time is accumulated;

[0049] Send the accumulated total sleep time to the host.

[0050] It should be further explained that, in the method, the format of the performance parameter is configured, and the number of bits of the performance parameter is defined, as well as the byte information contained in each bit.

[0051] It should be further explained that, in the method, a control instruction execution completion time sample acquisition command is defined, and the command format is set.

[0052] It should be further explained that the method also defines a command format for obtaining the current instruction execution status.

[0053] It should be further explained that the method also defines a command format for waiting time after the control instruction is executed.

[0054] The present application also provides a device, the device comprising: a host, a test firmware and a firmware;

[0055] The host is used to send a sample acquisition signal to the test firmware to obtain the waiting time after the control instruction is executed in multiple control instruction execution states, and use the waiting time after the control instruction is executed as a sample to train the linear programming model;

[0056] Send a status acquisition signal to the firmware to obtain the performance parameters and instruction execution status of the current control instruction execution state;

[0057] Input the acquired performance parameters and instruction execution status of the current control instruction execution state into the trained linear programming model to predict the waiting time after the control instruction is executed;

[0058] The predicted waiting time after the control instruction is executed is sent to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing the reset or shutdown operation.

[0059] According to another embodiment of the present application, a device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method for dynamically configuring waiting time based on a disk array accelerator card when executing the program.

[0060] According to another embodiment of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method for dynamically configuring the waiting time based on the disk array accelerator card are implemented.

[0061] It can be seen from the above technical solutions that the present invention has the following advantages:

[0062] The dynamic configuration method of waiting time based on disk array accelerator card involved in this application can receive IO performance parameters and IO status under the current NVMe admin command in real time. And input data into the trained linear programming model in real time, dynamically adjust the current IO clean waiting time, and then issue configuration commands to the RAID IO accelerator card through the NVMe admin command interface to dynamically adjust the waiting time setting. In this way, combined with IO performance parameters and IO state adjustment waiting time and other indicators, it is ensured that the IO clean waiting time is reasonably configured, which can avoid the host thinking that the device is hung when the waiting time is too long and the device abnormal IO cannot be cleaned. The waiting time can be set dynamically. Since the developer can predict the IO clean waiting time under different clock frequencies, different IO performance parameters, and different IO states through the prediction model, and send it to the firmware, the firmware no longer uses a single static IO clean waiting time, and can dynamically adapt to all hardware platforms and IO states.

[0063] This application can evaluate in real time and dynamically configure the IO clean waiting time to improve system operation efficiency and system resource utilization. According to monitoring results and actual needs, the model parameters can be adjusted in a timely manner to further optimize system performance. It can avoid the RAID IO accelerator card IO clean waiting time being set too large or too small, causing unstable system operation, and avoid the disadvantage that the host thinks the RAID IO accelerator card is hung when the waiting time is too long and the device abnormal IO cannot be cleaned. In addition, the IO clean waiting time of the disk array accelerator card can be dynamically and accurately configured to ensure a smooth transition when the system is reset or shut down, reducing the risk of data loss and damage. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the technical solution of the present invention, the accompanying drawings required for use in the description will be briefly introduced below. Obviously, the accompanying drawings in the following description are only 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 creative work.

[0065] Figure 1 A flow chart of a method for dynamically configuring the waiting time based on a disk array accelerator card;

[0066] Figure 2 The data interaction flow chart of this application;

[0067] Figure 3 The present invention is a flow chart of an embodiment of a method for dynamically configuring the waiting time based on a disk array accelerator card;

[0068] Figure 4Define schematic diagrams for IO status and performance parameters;

[0069] Figure 5 A schematic diagram for defining IO performance parameter configuration commands;

[0070] Figure 6 Get command definition diagram for IO clean time sample;

[0071] Figure 7 Get command definition diagram for current IO status;

[0072] Figure 8 Schematic diagram for IO clean wait time configuration command definition;

[0073] Fig. 9 The figure is a schematic diagram of the hardware structure of the device. DETAILED DESCRIPTION

[0074] The following is a detailed description of the steps of the method for dynamically configuring the waiting time based on the disk array accelerator card of the present application. For the purpose of explanation rather than limitation, specific details such as specific system structures and technologies are proposed to facilitate a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details.

[0075] It should be understood that when used in the present specification, the term "includes" indicates the presence of the described features, integral bodies, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integral bodies, steps, operations, elements, components and / or their collections. The terms "include", "comprise", "have" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0076] It should be understood that the "one or more" mentioned in this application refers to one, two or more than two, and the "multiple" mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B. The "and / or" in this article is just a way to describe the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0077] The phrases such as "one embodiment" or "some embodiments" described in the present application mean that the specific features, structures or characteristics described in the embodiment are included in one or more embodiments of the present application. Therefore, the phrases such as "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments" etc. that appear in different places in the present application do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways.

[0078] The waiting time dynamic configuration method of the present application is based on a device that accelerates the IO process of the disk array, such as a RAID IO acceleration card. The IO command execution process of the RAID acceleration card includes the IO command transmission process of the upstream and downstream NVMe interfaces, and the RAID algorithm execution process. When the host performs a reset or shutdown operation on the RAID IO acceleration card, it is necessary to wait for IO clean, that is, all IO commands are executed, and then perform a hardware reset or hard disk shutdown operation, so as to ensure that data is not lost during the reset or shutdown.

[0079] It should be noted that the meaning of IO clean is that all IO commands on the device have been executed and no IO commands are being executed. The device here can be a RAID IO accelerator card. The following control instructions of this application are executed and completed, which is IOclean. In conjunction with the purpose of this application, the IO clean waiting time is the waiting time for the control instruction to be executed.

[0080] Among them, RAID is a disk array controller. This application refers to a multi-disk management technology that improves IO read and write performance by hanging multiple disks on the host and reading and writing multiple disks in parallel. Although there are multiple disks physically, only one drive letter is presented to the host.

[0081] For RAID IO accelerator cards, which are hardware devices that can accelerate the RAID algorithm of disk IO, such as RAID IO accelerator cards with NVMe interfaces on both the upstream (host interface) and downstream (hard disk interface), the IO commands and RAID algorithms on the upstream and downstream NVMe interfaces can be processed through hardware pipelines to achieve faster execution speeds than software NVMe IO and RAID algorithms.

[0082] In this application, the host, RAID acceleration card and disk array can be connected based on the PCIe interface communication. Here, PCIe is the hardware interface between the host and the peripheral. The PCIe bus protocol implemented through the PCIe hardware link enables the host and the peripheral to exchange data based on the PCIe interface, and has the characteristics of high-speed transmission, abnormal recovery, power consumption management, etc.

[0083] In order to achieve high concurrency and asynchronous submission of IO request commands to the device and processing of IO response needs on the host side, the NVMe protocol can be configured so that the communication data information runs on the application layer protocol based on the PCIe protocol. The NVMe protocol can also define management and IO request / response queues. And use the admin command, combined with the commands in the NVMe protocol management system, the commands in the system can include creating queues, deleting queues, configuring features, etc.

[0084] The IO commands in this application are commands for reading and writing device memory based on the NVMe protocol. IO commands may include reading, writing, formatting, and verifying.

[0085] The purpose of the method for dynamically configuring the waiting time based on the disk array acceleration card involved in this application is to solve the problem that the user may set the waiting time too small because he is not sure how to reasonably set the IO clean waiting time, resulting in the firmware reaching the maximum waiting time of IO clean even though the RAID card has not yet completed the execution of the IO commands in the IO queue, so that the IO clean process exits abnormally, that is, the IO cannot be cleaned, resulting in the IO engine not being in the initial state after reset and thus failing to work normally. Of course, it is also to solve the problem that the waiting time may be set too large, the firmware has completed the IO clean, but is still executing the waiting time, affecting the execution efficiency of the system.

[0086] 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 only 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.

[0087] See also Figure 1 FIG. 1 is a flowchart of a method for dynamically configuring the waiting time based on a disk array accelerator card in a specific embodiment. Figure 2 The data interaction flow chart of the present application is shown.

[0088] The specific method includes the following steps:

[0089] S101: The host sends a sample acquisition signal to the test firmware to obtain the waiting time, performance parameters and instruction execution status after the control instruction is executed under various control instruction execution states, and uses the waiting time, performance parameters and instruction execution status after the control instruction is executed under the control instruction execution state as samples to train the linear programming model.

[0090] In some embodiments, the test firmware can be used to test the IO clean waiting time in different IO states, that is, in various control instruction execution states. Here, the IO clean waiting time is used as a sample to train a linear programming model for predicting the IOclean waiting time.

[0091] In some specific embodiments, a test firmware including multiple control instructions is prepared, which should cover various operation scenarios that the RAID IO accelerator card may encounter, such as read and write operations, data transmission, cache management, etc.

[0092] Furthermore, the host sends a sample collection signal to the test firmware through the PCIe interface and NVMe protocol based on the admin command and IO command. After receiving the signal, the test firmware starts to execute the predefined control instruction sequence and records the waiting time after each instruction is executed.

[0093] Exemplarily, the waiting time includes the time it takes for the instruction to execute the application, the system response time, and any possible delays.

[0094] In some embodiments, the test firmware sends the collected IO clean waiting time data back to the host. The IO clean waiting time collected by the host is used as a sample for training the linear programming model.

[0095] The host of this embodiment uses the collected sample data and runs a linear programming algorithm or other suitable machine learning algorithm to train a linear programming model. The goal of the linear programming model is to predict the waiting time after the IO command is executed based on the IO performance parameters and IO status of various states.

[0096] S102: The host sends a status acquisition signal to the firmware to obtain performance parameters and instruction execution status under the current control instruction execution status.

[0097] In some embodiments, the host sends a status collection signal to the RAID IO acceleration card according to system load changes, user requests, etc.

[0098] In this embodiment, after receiving the status acquisition signal, the RAID IO accelerator card collects the current performance parameters and instruction execution status. The performance parameters may include but are not limited to CPU usage, memory occupancy, disk I / O speed, etc. The instruction execution status includes but is not limited to the currently executed instruction type, execution progress, etc.

[0099] In this embodiment, the RAID IO accelerator card sends the acquired IO performance parameters and IO status data back to the host for subsequent analysis and prediction.

[0100] S103: The host inputs the acquired performance parameters and instruction execution status under the current control instruction execution status into the trained linear programming model to predict the waiting time after the control instruction is executed.

[0101] In some embodiments, the host inputs the received performance parameters and instruction execution status data into a trained linear programming model.

[0102] The linear programming model calculates and analyzes the input data to predict the possible waiting time after the command is executed under the current control command execution state. The linear programming model outputs the prediction results to the host for subsequent decision-making and processing.

[0103] S104: The host sends the predicted waiting time after the control instruction is executed to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing the reset or shutdown operation.

[0104] In some embodiments, the host sends the predicted IO clean wait time to the RAID IO acceleration card through the NVMe admin command interface and the NVMe protocol.

[0105] After receiving the predicted time, the RAID IO accelerator card stores it in the internal cache or register. Before a reset or shutdown operation is required, the RAID IO accelerator card checks the internally stored IO clean wait time. The RAID IO accelerator card performs reset or critical processes based on the IO clean wait time to ensure that the system can transition smoothly and reduce unnecessary waiting and delays.

[0106] According to an embodiment of the present application, for the construction method of the linear programming model of the present application, the following method can be used to determine the IO clean waiting time that needs to be dynamically configured. Obtain and enter the model, specification, version and supported functions of the disk array accelerator card. In this way, it can be learned that the waiting time that supports dynamic configuration can be obtained.

[0107] The data required for the construction and training of the linear programming model can be based on the PCIe interface and NVMe protocol, and combined with admin commands and IO commands to send sample collection signals to the test firmware.

[0108] In this embodiment, different IO test scenarios are configured according to the usage scenarios of the RAID IO accelerator card, including high load, low load, mixed load, etc. The IO clean time sample acquisition related command is sent to the RAID IO accelerator card through the NVMe admin command interface to collect waiting time samples under different IO states.

[0109] This embodiment sends the collected sample data to the host, where the sample data includes waiting time under different IO states, IO performance parameters, etc.

[0110] In this embodiment, the host performs preprocessing such as cleaning, normalization and feature extraction on the collected sample data to improve the prediction accuracy of the model.

[0111] In some embodiments, the host selects a suitable machine learning algorithm to train the model based on the characteristics of the sample data and the prediction requirements, for example, it can be based on linear regression, random forest, neural network and other algorithms.

[0112] Optionally, the host uses the preprocessed sample data to train the model. During the training process, the model parameters are continuously adjusted to optimize the prediction effect. Of course, a portion of the sample data that is not involved in the training can also be used to verify the model to ensure that the prediction accuracy of the model meets the requirements.

[0113] The host of this embodiment saves the trained linear programming model for real-time calling.

[0114] In this embodiment, when the linear programming model is used, the current IO performance parameters and IO status can be collected in real time through a performance monitoring tool, and the real-time collected data is input into the trained linear programming model to predict the current IO clean waiting time.

[0115] It should be noted that this application can also receive the IO performance parameters and IO status under the current NVMe admin command in real time. And input the data into the trained linear programming model in real time, dynamically adjust the current IO clean waiting time, and then send configuration commands to the RAID IO acceleration card through the NVMe admin command interface to dynamically adjust the waiting time setting.

[0116] In this way, the system's IO performance and waiting time and other indicators are continuously monitored to ensure the effectiveness of the configuration. In addition, real-time evaluation and dynamic configuration of IO clean waiting time can improve system operation efficiency and improve system resource utilization. According to monitoring results and actual needs, model parameters can be adjusted in a timely manner to further optimize system performance. This can avoid the RAID IO accelerator card IOclean waiting time being set too large or too small, causing unstable system operation, and avoid the disadvantage that the host thinks the RAID IO accelerator card is hung when the waiting time is too long and the device abnormal IO cannot be cleaned.

[0117] In one embodiment, Figure 3This is a flowchart of another method for dynamically configuring waiting time based on a disk array accelerator card provided according to an embodiment of the present invention. Based on the above embodiments, this embodiment further optimizes and expands the process of linear programming model training, performance parameters under the current control instruction execution state, and acquisition and prediction of instruction execution status.

[0118] Another method for dynamically configuring the waiting time based on a disk array accelerator card provided in this embodiment may include the following specific steps:

[0119] S201: The host obtains the IO clean waiting time under different IO states by sending an NVMe admin command to the test firmware to obtain the IO clean time sample, and uses the IO clean waiting time as a sample to train a linear programming model.

[0120] In some embodiments, the host sends an instruction for obtaining an IO clean time sample to the test firmware through the NVMe admin command interface.

[0121] After receiving the command, the test firmware will generate or collect IO clean waiting time samples under different IO states based on internal records or real-time simulation.

[0122] Optionally, the IO clean waiting time sample may include data in various scenarios such as high load, low load, and pre-trial type IO operations.

[0123] In this embodiment, after the host collects a preset amount of sample data, the sample data is used to train the linear programming model.

[0124] The linear programming model of this embodiment can be a mathematical method to find the optimal solution under given constraints. In the embodiment scenario of this application, it can be used to predict the IO clean waiting time based on IO performance and state parameters.

[0125] In this embodiment, after the training is completed, the model can be verified to ensure the accuracy of its prediction. Of course, a portion of sample data that has not participated in the training can also be used for testing, and the difference between the predicted results and the actual results can be compared.

[0126] S202: Before initiating a reset or shutdown operation, the host obtains the current IO performance parameters and IO status by sending an NVMe admin command to the RAID IO accelerator card.

[0127] In this embodiment, Figure 4 As shown, before initiating a reset or shutdown operation, the host sends a current IO status acquisition command to the RAID IO acceleration card through the NVMe admin command interface.

[0128] After receiving the command, the RAID IO accelerator card obtains the current IO performance parameters (such as read and write speed, IO queue depth, latency, etc.) and IO status (such as the number of active IOs, IO type distribution, etc.), and returns this data to the host.

[0129] In some specific embodiments, during the initialization phase of the RAID IO accelerator card, the IO performance parameters of the host NVMe engine are configured, which may specifically include the max payload size of the PCIe interface and the max read requestsize of the PCIe interface.

[0130] It should be noted that the maximum payload size of the PCIe interface is the maximum data payload that a single TLP (Transaction Layer Packet) can carry in the PCIe application layer.

[0131] The setting of the max payload size in this embodiment can be determined according to the specific requirements of the system and the hardware support. In the configuration of the RAID IO accelerator card, according to the performance parameters of the NVMe SSD and the PCIe controller, a suitable payload size is selected to achieve the best performance.

[0132] The max read request size of this embodiment is the maximum amount of data that can be requested by a single request during a read operation of the PCIe interface. The max read request size takes into account the efficiency and response time of data transmission of the PCIe interface.

[0133] Optionally, you can set a larger read request size to reduce the number of read requests, reduce the host's overhead, and improve the efficiency of IO operations. Of course, the setting of the read request size can be determined based on the specific needs of the system and hardware support. In the configuration of the RAID IO accelerator card, it is necessary to consider the read performance of the NVMe SSD, the processing power of the PCIe controller, and the system's requirements for response time, and select the setting parameters of the read request size.

[0134] In some specific embodiments, after configuring the IO performance parameters of the RAID IO acceleration card, the IO command is submitted to the IO queue memory.

[0135] The IO queue memory is a buffer for storing IO commands. This embodiment allows the system to process IO requests asynchronously, thereby improving the responsiveness and throughput of the system.

[0136] This embodiment enables the system to process multiple IO operations more efficiently by buffering IO requests based on the IO queue.

[0137] Of course, in this embodiment, while the hardware is processing an IO request, it continues to receive and process other IO requests, thereby improving the parallel processing capability of the system.

[0138] For the IO command execution of this embodiment, the RAID IO accelerator card polls and executes the IO command from the host IO queue according to the IO performance parameters. During the execution process, the RAID IO accelerator card optimizes the data transmission and processing process according to the max payload size and max read request size to achieve the best IO performance.

[0139] It can be seen that in this embodiment, during the initialization phase of the RAID IO accelerator card, the IO performance parameters of the host NVMe engine are configured, which can reasonably configure the parameters such as the PCIe interface max payload size and the PCIe interface max read request size, optimize the data transmission and processing process, and improve the system's IO performance and efficiency. At the same time, submitting IO commands to the IO queue memory can achieve asynchronous processing and parallel processing, further improving the system's responsiveness and throughput.

[0140] Furthermore, the IO command is submitted to the IO queue memory, and the RAID IO accelerator card polls and executes the IO command from the host IO queue according to the IO performance parameters. The definition of each IO performance parameter may include the following methods:

[0141] Defines the maximum payload size of the PCIe interface between the host and the RAID IO accelerator card.

[0142] In this embodiment, in the PCIe protocol, the maximum data length of a single message determines the amount of data that can be carried in one transmission. In this embodiment, the maximum data length is not fixed, but is affected by many factors, including the PCIe version, device configuration, and specific transmission type.

[0143] Specifically, in the PCIe protocol, the data length is usually expressed in double words (DW, ie, Double Word, 32 bits).

[0144] In the TLP header, the Length field is defined to indicate the length of the data payload. The minimum unit of the field is DW, and its value range determines the maximum length of the data payload. When the value of the Length field is 0, it means that the data length is 1024 DW (i.e. 4096 bytes) in the PCIe protocol. Of course, the specific data can refer to the PCIe protocol specification.

[0145] The maximum read request size of the PCIe interface between the host and the RAID IO accelerator card. The maximum length of data that can be read from the host memory in a single PCIe read request.

[0146] In this embodiment, the PCIe read request and write request may be expressed slightly differently in TLP, and then the host responds with a data completion TLP containing the requested data. The maximum data length of a single read request is limited by the data payload length in the read request TLP and the data completion TLP.

[0147] The PCIe protocol does not directly specify the maximum data length of a single read request. The maximum data length read from the host memory can be configured by the data payload length of the TLP, the device's Max_Payload_Size configuration, and possibly other factors. Alternatively, you can refer to the PCIe protocol specification.

[0148] In some embodiments, the maximum number of IOs that can be transferred from a host queue at a time. Related to NVMe multi-queue arbitration, when the number of IO commands in a host IO queue exceeds this number, the device will only transfer the number of IO commands corresponding to this configuration in one DMA request, and then the arbitrator will force a switch to the next IO queue.

[0149] In some specific embodiments, the maximum number of IOs that can be transferred from the host queue at a single time is actually closely related to the multi-queue technology and arbitration mechanism in the NVMe protocol.

[0150] In the NVMe protocol, illustratively, up to 65,535 IO queues can be supported, and each queue can have 64K outstanding commands.

[0151] In this embodiment, the maximum number of IOs that can be transferred from the host queue at a time is not fixed, but is affected by many factors, including device implementation, configuration, and current system load.

[0152] For multiple queues, NVMe can use multi-queue technology to allocate different queues according to tasks, scheduling priorities and CPU cores, thereby improving storage performance. Each queue is a first-in-first-out FIFO pipeline used to connect the host side and the device side.

[0153] Of course, the arbitration mechanism involved in this embodiment is based on NVMe defining an arbitration mechanism to select the command to be executed next time. The arbitration mechanism may include strategies such as round-robin scheduling and weighted round-robin scheduling to balance resource allocation between different queues.

[0154] This embodiment takes into account that the NVMe protocol cannot directly specify the maximum number of IOs transferred at a time, but it can be determined by the hardware implementation of the device, the design of the firmware / driver, and the current state of the system. When the number of IO commands in a host IO queue exceeds a certain configuration or threshold, the device may transfer the number of IO commands corresponding to the configuration through a DMA request, and then the arbitrator will switch to the next IO queue to ensure fair allocation and efficient use of system resources.

[0155] In this way, by allowing multiple queues to process IO requests simultaneously, NVMe can significantly improve the concurrency of the system. It can also maintain low latency and high throughput. Moreover, the arbitration mechanism of this embodiment ensures that resources between different queues are fairly distributed. When the load of a queue is high, the system can automatically switch to other queues to avoid resource bottlenecks and overloads.

[0156] It can be seen that the maximum number of IOs that can be transferred from the host queue at a time in this embodiment is a dynamically changing value, and by utilizing NVMe's multi-queue technology and arbitration mechanism, IO requests can be efficiently processed and resource utilization can be optimized, thereby improving overall performance and concurrency.

[0157] In some embodiments, the minimum number of IOs that can be transferred from a host queue at a time. Related to NVMe multi-queue arbitration, when the number of IO commands in a host IO queue is lower than this number, the device will not transfer IO commands from this IO queue, and the arbitrator will force a switch to the next IO queue.

[0158] In this embodiment, when a host IO queue has very few IO commands, or even only one or no IO commands, the device will not immediately transfer IO commands from the queue. This is based on the design goal of NVMe to improve the overall performance and efficiency of the system and optimize resource utilization by processing multiple queues in parallel. If a queue is idle for a long time or has only a few commands, allocating resources to the queue may cause other busier queues to not be processed in a timely manner.

[0159] In this embodiment, although the NVMe protocol does not explicitly specify the minimum number of IOs, the firmware / driver of the device may dynamically adjust the scheduling policy of the queue according to the actual hardware capabilities and system load. For example, when it is detected that the number of commands in a queue is lower than a certain internally set threshold, the device may temporarily place the queue at a lower priority so that more resources can be allocated to other queues that are more needed. In this way, the overall performance and efficiency are improved by avoiding processing a small number of commands in idle or low-load queues. In addition, dynamically adjusting the priority and scheduling policy of the queue can ensure that system resources are used fairly and efficiently, avoiding resource waste and bottlenecks. Thereby enhancing the stability and reliability of the system.

[0160] In some embodiments, the maximum number of IO commands that can be cached is also defined.

[0161] It should be noted that when the number of IO commands that have been transferred from the host to the host NVMe engine of the RAID IO accelerator card but have not yet been passed to the subsequent hardware modules (such as the RAID algorithm engine) reaches this number, the IO commands will no longer be transferred from the host.

[0162] It can be seen that when describing the IO command caching mechanism between the host NVMe engine of the RAID IO accelerator card and the subsequent hardware modules, this embodiment does not have a fixed or universal standard for the maximum number of IO commands that can be cached. This value depends on multiple factors, including but not limited to the hardware specifications of the accelerator card, firmware design, system configuration, and expected load and performance requirements.

[0163] Regarding the maximum number of IO commands that can be cached in this embodiment, considering that the cache size of the RAID IO accelerator card is limited, the number of IO commands that can be cached simultaneously is determined. The cache size may be determined by the memory of the onboard dynamic random access memory DRAM.

[0164] In this embodiment, by caching IO commands transferred from the host, the RAID IO acceleration card can reduce the number of accesses to the host memory, thereby reducing latency and improving overall performance.

[0165] It should be noted that when the RAID algorithm engine is temporarily unable to process all commands immediately, the cache mechanism can smoothly absorb these commands to avoid putting pressure on the host. The cache mechanism also enables the accelerator card to more efficiently utilize internal resources such as processor time and memory bandwidth. By storing commands waiting to be processed in the cache, the accelerator card can reduce idle time and improve overall efficiency.

[0166] Of course, when the system of the present application is under high load, the cache mechanism helps to reduce the impact on the host and subsequent processing modules, thereby enhancing the stability and reliability of the entire system. Even in the face of a large number of sudden IO requests, the system can smoothly process these requests through the cache to avoid the risk of overload and crash.

[0167] In some embodiments, the host NVMe engine can convert the IO commands carried by the host into a task control block containing IO command parameters, and then pass the task control block to subsequent RAID algorithm engines, each of which contains different IO states.

[0168] In some specific embodiments, the IO status is defined as follows:

[0169] The number of task control block caches of the PRP transport engine.

[0170] In this embodiment, each task control block is used to include the first address of the physical area page PRP list, the number of data blocks, etc. according to the NVMe IO command parameters.

[0171] The execution of this embodiment is a PRP linked list DMA operation from the host to the RAID card memory, that is, the content transferred is the PRP linked list, and the number of task control block caches determines the number of "DMA" that can be executed in parallel.

[0172] In some embodiments, the task control block cache number of the RAID deformation engine. Each task control block is used to convert the PRP chain list according to the RAID information into a sub-PRP chain list and a data block number representing the IO commands of each hanging plate under the RAID card according to the RAID algorithm. The number of task control block caches determines the number of conversions that can be executed in parallel.

[0173] The RAID information here includes RAID level, stripe size, stripe unit, etc.

[0174] In some embodiments, the number of task control blocks cached by the RAID calculation engine. Each task control block is used to calculate the check value of the data corresponding to the IO command according to the RAID algorithm and IO command parameters including RAID level, PRP linked list, etc. The number of task control block caches determines the number of calculations that can be performed in parallel.

[0175] In this embodiment, by increasing the number of task control block caches, more DMA operations can be performed in parallel, that is, the process of transferring data from the host to the RAID card memory. It can be seen that this embodiment improves the efficiency and speed of data transmission, reduces the waiting time, and enables the system to process more IO requests at the same time.

[0176] This embodiment is based on the increase in the number of task control block caches, so that more sub-IO commands can be converted and distributed to each disk attached to the RAID card at the same time. This improves the parallel processing capability of the RAID system.

[0177] In addition, by increasing the number of task control block caches, more checksum calculation tasks can be executed in parallel. This is crucial to improving data integrity and reliability, especially in high-load and high-speed IO scenarios, to ensure the timeliness and accuracy of data verification.

[0178] For this embodiment, by reasonably allocating task control block cache resources, it can be ensured that each engine can fully utilize system resources when processing IO requests. At the same time, due to the enhanced parallel processing capability, the system can more efficiently handle sudden high load conditions and avoid performance bottlenecks caused by insufficient resources.

[0179] In some specific embodiments, the RAID algorithm engine passes information such as the sub-PRP linked list, the number of data blocks, and verification information to the hard disk NVMe engine.

[0180] The hard disk NVMe engine of this embodiment combines these IO parameters into sub-IO commands, and then writes the sub-IO commands into the IO queue memory corresponding to each downstream hard disk. Each hard disk moves the IO commands from the IO queue memory, and then performs DMA operations from the RAID card to the hard disk flash address according to the IO command parameters.

[0181] It should be noted that the IO performance parameters related to hard disk IO command handling are defined as follows:

[0182] Defines the maximum payload size of the PCIe interface between the RAID card and the hard disk.

[0183] Defines the maximum read request size of the PCIe interface between the RAID card and the hard disk. The maximum length of data that can be read from the host memory in a single read request of the device PCIe.

[0184] In this embodiment, by increasing the number of task control block caches, IO requests can be responded to and processed more quickly, reducing system delays and instability factors caused by long waiting times. In addition, by performing checksum calculations in parallel in the RAID calculation engine, the integrity and consistency of data during transmission and storage can be ensured.

[0185] This embodiment is based on the parallel processing mechanism of the number of task control block caches, so that the system can be flexibly configured and expanded according to actual needs. In actual storage system design and application, the system performance is optimized by adjusting the number of task control block caches, and the effect of increasing the number of task control block caches on improving system performance can also be intuitively seen.

[0186] S203: Input the IO performance parameter and the IO status into the linear programming model to predict the current IO clean waiting time.

[0187] In some embodiments, the host passes the acquired IO performance parameters and IO status as input to the linear programming model trained in step one.

[0188] The linear programming model calculates based on the input parameters and predicts the possible waiting time for the IOclean operation under the current IO performance and status. After the host receives the prediction results, it can further analyze and evaluate them to determine whether the IO clean waiting time in the firmware needs to be adjusted.

[0189] S204: The host sends the IO clean wait time configuration NVMe admin command to the RAID IO accelerator card to send the IO clean wait time to the RAID IO accelerator card. The RAID IO accelerator card waits for the IO clean register to become 1 before performing a reset or shutdown operation according to the new IO clean wait time, otherwise the register is set to 0.

[0190] In some embodiments, if the prediction result shows that the IO clean wait time needs to be adjusted, the host sends an IO clean wait time configuration command to the firmware through the NVMeadmin command interface, along with the new wait time value.

[0191] After receiving the command and the new wait time value, the RAID IO accelerator card will update its internal IO clean wait time setting. Before performing a reset or shutdown operation, the firmware will wait for the IO clean register to become 1 according to the new wait time value, that is, wait for all pending IO operations to complete. Once the IO clean register becomes 1, it means that all pending IO operations have been completed, and the firmware can continue to perform a reset or shutdown operation.

[0192] It can be seen that through the above four steps, the IO clean waiting time of the disk array accelerator card can be dynamically and accurately configured, thereby ensuring a smooth transition when the system is reset or shut down, reducing the risk of data loss and damage.

[0193] In an exemplary embodiment, IO performance parameters are defined and configured in a unified manner.

[0194] Specifically, if Figure 5 As shown, multiple dwords are set in the field meaning method related to the IO performance parameters and the command format.

[0195] It should be noted that dword stands for Double Word, which refers to the number of digits of a value in a system. In this embodiment, each dword contains 4 bytes.

[0196] Specifically, the first byte represents the first byte in the dword from low address to high address, the second byte represents the second byte in the dword from low address to high address, the third byte represents the third byte of the dword, and the fourth byte represents the fourth byte of the dword.

[0197] In this embodiment, the specific meaning of the command valid data field is as follows:

[0198] The first byte can be represented as an operation code = 0xdb. Specifically, it can represent the command type, which is used to distinguish other types of NVMe commands.

[0199] This embodiment can also represent the MAXpayload size parameter of the host PCle interface and the maximum number of IO commands that can be cached based on the first byte.

[0200] The second byte is a reserved field, which can specifically represent a field not used by the NVMe protocol and is used for future protocol expansion.

[0201] In this embodiment, the host PCle interface MAX ReadRequest size parameter and the hard disk PCle interface MAX payload size parameter are configured in the second byte.

[0202] In this embodiment, the third byte is a command identifier, which may specifically represent a command sequence number in the same admin command queue, and is used to distinguish other commands in the same admin command queue.

[0203] For example, it can represent multiple commands of the same type. Of course, the third byte can also represent the maximum number of IOs that can be transferred from the host queue at a time and the hard disk PCle interface MAXpayload size parameter.

[0204] The fourth byte in this embodiment may represent the minimum number of IOs that can be transferred from the host queue at a single time.

[0205] The above-described definition of the meanings of the IO performance parameters and command format related fields is provided as an example and is not specifically limited and can be adjusted accordingly according to actual needs.

[0206] In an exemplary embodiment, the IO clean time sample acquisition command format is defined and configured in a unified manner.

[0207] In this embodiment, the command format of the IO clean time sample is defined as follows: Figure 6 As shown, the command valid data field is similar to the IO performance parameter configuration method and has four bytes.

[0208] The first byte of the IO clean time sample command format indicates the operation code 0xdc, and the third and fourth bytes indicate the command identifier.

[0209] In this embodiment, a command for obtaining the current IO status is also defined.

[0210] Specific as Figure 7 As shown in the command format for obtaining the current IO status, the meaning of the valid data field is as follows:

[0211] The first byte of the command format for obtaining the current IO status is represented by an operation code = 0xdd, which can indicate that the current command is the current IO status obtaining status.

[0212] The second byte indicates the DMA address format, which can specifically indicate the memory block address organization format when the command uses multiple memory blocks of the host.

[0213] It should be noted that the NVMe protocol has multiple address formats. This command uses the PRP list type address format.

[0214] The third byte of this embodiment represents the command identifier. Figure 6 The IO performance parameter configuration is the same as in .

[0215] The fourth byte represents the host DMA address. The fourth byte of this embodiment is used to save the host memory address of the IO state and IO performance parameter configuration data. The host memory address format is the PRP list format. The format definition refers to the NVMe protocol specification document.

[0216] The fifth byte of this embodiment represents the data length, which may be the length of the host DMA address in units of a memory block size (eg, 4KB).

[0217] This embodiment also defines the command format for configuring the IO clean waiting time. Figure 8As shown, the command format of the IOclean wait time is defined, which can be used to configure a new IO clean wait time for the firmware.

[0218] Specifically, the first byte indicates the operation code = 0xdb. The second byte indicates the DMA address format, which can be represented based on 0x00.

[0219] This embodiment combines the parameter definition process of the above-mentioned waiting time dynamic configuration method based on the disk array accelerator card to define a clear operation code (such as 0xdb, 0xdc, 0xdd, etc.) for each IO-related command to distinguish different types of commands.

[0220] In this embodiment, the meaning of each command byte that can be defined includes operation code, reserved field, command identifier, DMA address, data length, etc.

[0221] Embed the parameters that need to be configured in the command, such as MAXpayload size, MAX ReadRequest size, etc., and set the corresponding parameter values ​​by sending the corresponding command.

[0222] For parameters that need to be obtained, such as IO status, corresponding commands and response formats can be defined so that the system can return the required data.

[0223] After receiving the command, the command receiver in this embodiment identifies the command type according to the operation code and parses each parameter in the command.

[0224] Perform corresponding operations based on the parsing results, such as setting parameter values, obtaining current status, etc.

[0225] In this embodiment, the result after execution is returned to the command sender.

[0226] In this embodiment, the current IO status acquisition command is sent periodically or on demand to monitor the IO performance parameters and status of the system.

[0227] In this embodiment, the IO clean waiting time is adjusted according to the performance parameters and the instruction execution status, and the DMA address format and the like may also be optimized to optimize the system performance.

[0228] It can be seen that this embodiment defines IO performance parameters and commands in a unified format, making the management and maintenance of the system more standardized and simplified. In addition, by defining the opcode, command identifier, DMA address, etc. of the command, the execution efficiency of the command and the accuracy of data transmission are improved. It can also allow flexible configuration of IO performance parameters such as MAXpayload size, MAX ReadRequest size, etc. according to different application scenarios and requirements, thereby optimizing system performance.

[0229] On the basis of the above embodiments, in order to further improve the reliability of the disk array accelerator card waiting time dynamic configuration method provided in the above embodiments, as an implementable method, in one embodiment, a linear programming model is trained to improve the accuracy of the IO clean waiting time prediction time.

[0230] The specific training process includes the following steps:

[0231] The host sends a configuration command based on the IO performance parameters defined above to the RAID IO accelerator card, and configures different IO performance parameters to the RAID IO accelerator card.

[0232] In this embodiment, in order to obtain the IO clean waiting time under different numbers of host IO commands, the host fills a preset number of IO commands into the host IO queue memory.

[0233] In this embodiment, the RAID IO accelerator card can be used as test firmware. The host obtains the IO clean time under different IO states and IO performance parameters from the RAID IO accelerator card by sending an IOclean time sample acquisition command to the RAID IO accelerator card. Considering that the RAID IO accelerator card is used as a test firmware and does not need to be used formally, the code can be written here to poll the IO clean status register in an infinite loop with a very small sleep interval (such as 1ms), and accumulate the total sleep waiting time, and finally reply the accumulated total sleep time to the host in the form of an NVMe admin command response.

[0234] In this embodiment, after obtaining enough IO clean time samples, all the obtained samples are used to train the linear programming model. The specific process of training the model is as follows:

[0235] Define the actual value function based on the linear programming model: .

[0236] Among them, x1, x2, x3, and x4 represent different performance parameters and instruction execution states respectively.

[0237] In this embodiment, a hypothesis function is defined: .

[0238] The vector dimension k represents the slope, b represents the intercept, and h represents the predicted value. The initial values ​​of k1, k2, k3, k4, and b are all 1.

[0239] Define the loss function: .

[0240] Defining the optimization function , the optimization function means adjusting the values ​​of k and b so that the loss function Minimum, the optimization function implements gradient descent based on the following method,

[0241] ;

[0242] ;

[0243] in, Represents the loss function Find the partial derivative of slope k, Represents the loss function Find the partial derivative of slope b; weight represents the learning rate.

[0244] In this embodiment, k and b are continuously adjusted until the loss value reaches a preset loss threshold value, thereby obtaining a linear regression function for prediction.

[0245] This embodiment can more accurately predict the waiting time of control instructions under different performance parameters and instruction execution states by training a linear regression model, thereby optimizing the IO clean time and meeting system usage requirements. Moreover, based on the prediction results, the configuration of the disk array accelerator card can be dynamically adjusted to optimize resource allocation and utilization efficiency, reduce waiting time and improve overall system performance.

[0246] This embodiment can also monitor and predict waiting time in real time, timely discover and solve potential performance bottlenecks and failure points, thereby enhancing the stability and reliability of the system. By reducing waiting time and improving system response speed,

[0247] In an exemplary embodiment, the prediction process of the linear programming model specifically includes the following steps:

[0248] In this embodiment, when the host is preparing to reset or shut down the RAID IO acceleration card, the current IO state and IO performance parameter configuration data can be obtained from the RAID IO acceleration card by sending a current IO state acquisition command to the RAID IO acceleration card.

[0249] Afterwards, the host obtains the current IO status from the RAID IO accelerator card and inputs the IO status into the linear programming model, which predicts the IO clean waiting time.

[0250] After predicting the IO clean wait time, the host sends an IO clean wait time configuration command to the RAID IO accelerator card to configure a new IO clean wait time for the RAID IO accelerator card. The RAID IO accelerator card saves the new IO clean wait time and then executes subsequent reset or shutdown processes according to the new IO clean wait time.

[0251] The purpose of the method for dynamically configuring the waiting time based on the disk array acceleration card involved in this application is to solve the problem that the user may set the waiting time too small because he is not sure how to reasonably set the IO clean waiting time, resulting in the firmware reaching the maximum waiting time of IO clean even though the RAID card has not yet completed the execution of the IO commands in the IO queue, so that the IO clean process exits abnormally, that is, the IO cannot be cleaned, resulting in the IO engine not being in the initial state after reset and thus failing to work normally. Of course, it is also to solve the problem that the waiting time may be set too large, the firmware has completed the IO clean, but is still executing the waiting time, affecting the execution efficiency of the system.

[0252] The following is an embodiment of the device provided in the embodiments of the present disclosure. The device and the method for dynamically configuring the waiting time based on the disk array accelerator card in the above-mentioned embodiments belong to the same inventive concept. For details not fully described in the embodiment of the device, reference can be made to the embodiment of the method for dynamically configuring the waiting time based on the disk array accelerator card in the above-mentioned embodiments.

[0253] The device includes: a host, a test firmware and a firmware;

[0254] The host is used to send a sample acquisition signal to the test firmware to obtain the waiting time after the control instruction is executed in multiple control instruction execution states, and use the waiting time after the control instruction is executed as a sample to train the linear programming model;

[0255] Send a status acquisition signal to the firmware to obtain the performance parameters and instruction execution status of the current control instruction execution state;

[0256] Input the acquired performance parameters and instruction execution status of the current control instruction execution state into the trained linear programming model to predict the waiting time after the control instruction is executed;

[0257] The predicted waiting time after the control instruction is executed is sent to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing the reset or shutdown operation.

[0258] In the device of the present application, the host sends the predicted IO clean waiting time to the RAID IO accelerator card through the NVMe admin command interface and the NVMe protocol. After receiving the predicted time, the RAID IO accelerator card stores it in an internal cache or register. Before a reset or shutdown operation is required, the RAID IO accelerator card checks the internally stored IO clean waiting time. The RAID IO accelerator card performs a reset or critical process based on the IO clean waiting time to ensure that the system can transition smoothly and reduce unnecessary waiting and delays.

[0259] This embodiment also provides a device for executing the method for dynamically configuring the waiting time based on a disk array accelerator card of the present application. The device here can be a host, or a terminal that executes the method for dynamically configuring the waiting time based on a disk array accelerator card of the present application, etc.

[0260] like Fig. 9 The figure is a schematic diagram of the hardware structure of a device for implementing various embodiments of the present invention. The device 500 includes, but is not limited to, components such as a communication module 502, an audio output unit 503, an input unit 504, a display unit 506, a user input unit 507, an interface unit 508, a memory 509, a processor 510, and a power supply 501. Those skilled in the art will appreciate that the device structure involved in the embodiments of the present invention does not constitute a limitation on the device, and the device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0261] It should be understood that, in the embodiment of the present invention, the communication module 502 can enable the host to communicate with the test firmware and the firmware respectively.

[0262] The audio output unit 503 may convert audio data received by the RF unit 501 or the communication module 502 or stored in the memory 509 into an audio signal and output it as sound.

[0263] The input unit 504 is used to receive audio or video signals. The display unit 506 is used to display information input by the user or information provided to the user. The display unit 506 may include a display panel, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc.

[0264] The user input unit 507 can be used to receive input digital or character information and generate key signal input related to user settings and function control of the device. Specifically, the user input unit 507 includes a touch screen and other input devices.

[0265] The interface unit 508 is an interface for connecting an external device to the apparatus 500. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, etc. The interface unit 508 may be used to receive input (e.g., data information, power, etc.) from an external device and transmit the received input to one or more elements within the apparatus 500 or may be used to transmit data between the apparatus 500 and an external device.

[0266] The memory 509 can be used to store software programs and various data. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system and a method for dynamically configuring the waiting time based on a disk array accelerator card, etc. In addition, the memory 509 can include a high-speed random access memory and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0267] The processor 510 can be implemented by using at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a processor, a controller, a microcontroller, a microprocessor, and an electronic unit designed to perform the functions described herein. In some cases, such an implementation can be implemented in a controller. For software implementation, implementations such as processes or functions can be implemented with separate software modules that allow execution of at least one function or operation. The software code can be implemented by a software application (or program) written in any appropriate programming language, and the software code can be stored in a memory and executed by a controller.

[0268] The device for executing the method for dynamically configuring the waiting time based on the disk array accelerator card provided in this embodiment is a unit and algorithm step of each example described in combination with the embodiments disclosed herein, and can be implemented by 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 executed 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.

[0269] In the storage medium provided in the present application, a program product capable of implementing the above method of the present specification is stored. In some possible implementations, various aspects of the present disclosure may also be implemented in the form of a program product, which includes a program code, and when the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps according to various exemplary implementations of the present disclosure described in the above "Exemplary Method" section of the present specification.

[0270] The storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0271] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for dynamically configuring waiting time based on a disk array accelerator card, characterized in that: Methods include: S101: The host sends a sample acquisition signal to the test firmware to obtain the waiting time after the control instruction is executed, the performance parameters and the instruction execution status under various control instruction execution states, and uses the waiting time after the control instruction is executed under the control instruction execution state, the performance parameters and the instruction execution status as samples to train the linear programming model; S102: The host sends a status acquisition signal to the firmware to obtain performance parameters and instruction execution status under the current control instruction execution state; S103: The host inputs the acquired performance parameters and instruction execution status of the current control instruction execution status into the trained linear programming model to predict the waiting time after the control instruction is executed; S104: The host sends the predicted waiting time after the control instruction is executed to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing the reset or shutdown operation.

2. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 1, characterized in that: Before step S101, the following steps are also included: Define host read and write performance parameters; Configure the control instructions to the host instruction execution queue; The firmware polls and executes control commands from the host command execution queue according to the defined host read and write performance parameters.

3. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 2, characterized in that: The host read and write performance parameters include: the upper limit of the amount of data transmitted by the host interface and the upper limit of the amount of data processed by the host interface for read requests.

4. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 2, characterized in that: Defining host read and write performance parameters also includes: An upper limit on the amount of data transmitted by the communication interface between the host and the firmware is defined, as well as an upper limit on the amount of data read requests processed by the communication interface between the host and the firmware.

5. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 2, characterized in that: The method also defines the upper limit of the number of control instructions that can be carried out at a time from the host instruction execution queue; When the number of control instructions in a host instruction execution queue exceeds the upper limit of the control instructions transferred at a single time, the firmware only transfers the corresponding number of control instructions, and the arbitrator controls and switches the firmware to the next host instruction execution queue to execute the transfer process.

6. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 2, characterized in that: The method also defines the lower limit of the number of control instructions that can be executed from the host command queue at a time; When the number of control instructions in a host instruction execution queue is lower than the lower limit of a single transport control instruction, the firmware does not perform the transport operation, and the arbiter controls and switches the firmware to the next host instruction execution queue to execute the transport process.

7. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 2, characterized in that: The method also defines an upper limit on the number of cache control instructions; When the control instructions are transferred, and the number of control instructions that have not been transferred to the hardware module reaches the upper limit of the number of cached control instructions, the transfer of control instructions from the host is stopped.

8. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 1 or 2, characterized in that: The method further includes: converting the control instruction carried from the host into a task control block including control instruction parameters; Transfer the task control block to the disk array.

9. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 8, characterized in that: Configure the number of task control block caches; Execute the transfer of the linked list from the host to the firmware memory based on the control instruction parameters; Based on a preset algorithm, the linked list is converted into a sub-linked list representing the disk array control instructions and the number of data blocks under the disk array according to the disk array information; Based on the preset algorithm and control instruction parameters, the check value of the data corresponding to the control instruction is calculated.

10. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 9, characterized in that: The method further includes: the disk array algorithm engine sends the sub-link list, the number of data blocks and the check value to the disk engine; The disk engine configures the sub-list, the number of data blocks, and the checksum value to the control queue memory corresponding to the hard disk; Each hard disk retrieves the control instruction from the control queue memory and executes the operation from the disk array to the preset address of the hard disk according to the control instruction parameters.

11. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 10, characterized in that: The method also defines an upper limit on the amount of data transmitted by the communication interface between the firmware and the hard disk, and defines an upper limit on the amount of data processed by the communication interface between the firmware and the hard disk for reading requests.

12. The method for dynamically configuring waiting time based on a disk array accelerator card according to claim 1 or 2, characterized in that: Step S101 also includes: Configure different control instruction performance parameters to the test firmware; Set a preset number of control commands and assign them to the host command execution queue; Obtaining, from the test firmware, different performance parameters and the waiting time after the control instruction is executed under the instruction execution state; The waiting time after all the acquired control instructions are executed is used as a training sample, and the linear programming model is trained using all the acquired training samples; Define the actual value function based on the linear programming model: ; Among them, x1, x2, x3, and x4 represent different performance parameters and instruction execution states respectively; Define the hypothesis function: ; Among them, the vector dimension k represents the slope, b represents the intercept, and h represents the predicted value; The initial values ​​of k1, k2, k3, k4 and b are all 1; Define the loss function: ; Defining the optimization function , the optimization function means adjusting the values ​​of k and b so that the loss function Minimum, the optimization function implements gradient descent based on the following method, ； ； in, Represents the loss function Find the partial derivative of slope k, Represents the loss function Find the partial derivative of slope b; weight represents the learning rate; By continuously adjusting k and b until the loss value reaches the preset loss threshold, the linear regression function used for prediction is obtained.

13. The method for dynamically configuring the waiting time based on the disk array accelerator card according to claim 12, characterized in that: In the method, define the command for testing user performance parameters; Among them, the control instruction execution completion status register is polled in an endless loop with a preset sleep interval, and the total sleep waiting time is accumulated; Send the accumulated total sleep time to the host.

14. The method for dynamically configuring waiting time based on a disk array accelerator card according to claim 1 or 2, characterized in that: In the method, the format of the performance parameter is configured, and the number of bits of the performance parameter is defined, as well as the byte information contained in each bit.

15. The method for dynamically configuring waiting time based on a disk array accelerator card according to claim 1 or 2, characterized in that: In the method, define the control instruction execution completion time sample acquisition command and set the command format.

16. The method for dynamically configuring waiting time based on a disk array accelerator card according to claim 1 or 2, characterized in that: The method also defines the command format for obtaining the current instruction execution status.

17. The method for dynamically configuring waiting time based on a disk array accelerator card according to claim 1 or 2, characterized in that: The method also defines the command format for waiting time after the control instruction is executed.

18. A device for dynamically configuring waiting time based on a disk array accelerator card, characterized in that: The device is used to implement the waiting time dynamic configuration method based on the disk array accelerator card as described in any one of claims 1 to 17; The device includes: a host, a test firmware and a firmware; The host is used to send a sample acquisition signal to the test firmware to obtain the waiting time after the control instruction is executed in multiple control instruction execution states, and use the waiting time after the control instruction is executed as a sample to train the linear programming model; Send a status acquisition signal to the firmware to obtain the performance parameters and instruction execution status of the current control instruction execution state; Input the acquired performance parameters and instruction execution status of the current control instruction execution state into the trained linear programming model to predict the waiting time after the control instruction is executed; The predicted waiting time after the control instruction is executed is sent to the firmware, and the firmware executes subsequent reset or key processes according to the waiting time after the control instruction is executed before executing the reset or shutdown operation.

19. A device for dynamically configuring waiting time based on a disk array accelerator card, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the waiting time dynamic configuration method based on the disk array acceleration card as described in any one of claims 1 to 17 are implemented.

20. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for dynamically configuring waiting time based on a disk array accelerator card as described in any one of claims 1 to 17 are implemented.

Images