Task abort processing method, command processor, and task abort processing system

Abstract

The application discloses a task abort processing method, a command processor and a task abort processing system. The method sets a local counter for each task queue and a state entry containing a flag for each task packet in the command processor. When the task packet is queued, the counter is increased by 1, and when the task packet is issued to an execution unit, the sent flag is set. After receiving an abort command, the sent task packet is set with an abort flag, and after receiving a normal execution completion reply, the reply and submission permission flag are set and the counter is decreased by 1. The task packet not sent is directly set with the submission permission flag and the counter is decreased by 1. When the local counter of the target queue is zero, a resource release confirmation signal is output. The application takes the counter zero as the basis for judging the resource release, does not depend on the unreliable abort reply signal, considers the fast response and the resource safety, sinks the abort judgment to the command processor side, reduces the firmware overhead, provides extreme exception protection through the timeout reset mechanism, and improves the system availability.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design, and more specifically to a task abort processing method, a command processor, and a task abort processing system. Background Technology

[0002] In a system-on-a-chip (SoC) that includes a Command Processor (CP) and multiple task execution units, the CP is responsible for dispatching tasks issued by the firmware to the various task execution units. When the software needs to terminate a process, the firmware sends a kill command to the command processor targeting a queue.

[0003] In existing technologies, the process controller (CP) typically passes the kill command to the task execution unit and waits for the task execution unit to complete its local task and return a kill_done signal. The CP then submits this signal as evidence that the task has been terminated to the firmware, which then releases the resources occupied by the software. This design has the following drawbacks: 1. The system relies entirely on the downstream execution unit to correctly execute the `kill` command and return `kill_done`. If the execution unit is poorly designed, its `kill` function may not work correctly, or the execution unit itself may not even support the `kill` function, potentially returning a false `kill_done`. In this case, the firmware will incorrectly assume the task has been terminated and storage space has been released, but the execution unit may still be accessing this reallocated storage space in the background, leading to data corruption in the new process. 2. If the internal logic of the task execution unit is abnormal, causing the kill_done signal to fail to return, the firmware will wait for the signal indefinitely, which may cause the system to freeze and become unresponsive to subsequent tasks.

[0004] In the prior art related to this application, US2013 / 067143A1 discloses a memory device and its control method. When the device server receives an abort command (ABORT task), it checks all commands in the queue, performs an abort operation on abortable commands, and returns an abort completion response to the host after processing. However, this method still needs to wait for the task execution unit to complete the abort operation and return a response, failing to avoid the dependence on the completion response of the downstream execution unit. US2013 / 067143A1 involves the host controller's abort processing of storage devices. This method considers three scenarios: the command has been completed, the command has not yet been retrieved, and the command has been sent but not completed, and performs a cleanup process for each. However, it still needs to send an abort request to the storage device and wait for feedback from the device side. Its resource reclamation depends on the kill_done signal on the device side, failing to solve the problem of accidental resource release or permanent system freeze caused by relying on unreliable responses.

[0005] Furthermore, the design of the xHCI host controller driver and qla2xxx SCSI driver in the Linux kernel, as well as the NVMe driver, all contain logic for aborting commands in response to command timeouts or task management requests. However, these solutions generally rely on feedback from downstream modules or lack an independent and precise full lifecycle management mechanism on the command processor itself. As a result, there is still a risk of system crashes when the execution unit becomes unresponsive.

[0006] Therefore, there is an urgent need for a more robust task termination handling method that can reduce the dependence on the correctness of the kill_done signal of the downstream execution unit. Summary of the Invention

[0007] To overcome the problem of excessive dependence of task termination logic on downstream execution units in existing technologies, a task termination processing method, command processor, and task termination processing system are proposed.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: A task abort handling method, executed in a command processor, the method comprising: A local counter is set for each task queue. The local counter is initially set to 0, incremented by 1 in response to receiving a task packet for the corresponding task queue, and decremented by 1 in response to the submission of a task packet for the corresponding task queue. Set a corresponding status entry for each task package. The status entry shall at least include a sent flag, a reply flag, an aborted flag, and a submission permission flag. In response to receiving a task packet, increment the local counter of the task queue to which the task packet belongs by 1; In response to sending the task package to the task execution unit, the sent flag of the corresponding status entry is set; In response to an abort command targeting the queue: For a status entry where the sent flag is set, set its abort flag, and after receiving a normal execution completion reply from the task execution unit, set the reply flag and submission permission flag of the status entry, and decrement the local counter of the target queue by 1. For status entries where the sent flag is not set, directly set the submission permission flag of the status entry and decrement the local counter of the target queue by 1; When the local counter of the target queue reaches zero, a resource release confirmation signal is output.

[0009] Furthermore, the resource release confirmation signal is used to instruct the firmware to release the software resources occupied by the target queue, and the submission license flag indicates that the command processor resources occupied by the corresponding task package can be released.

[0010] Furthermore, the task abort handling method is independent of the abort completion reply of the task queue returned by the task execution unit.

[0011] Furthermore, in response to the abort command, a timer is started, and if the timer times out and the local counter of the target queue has not yet returned to zero, a system reset is triggered.

[0012] Furthermore, each of the status entries also records the queue flag of the queue to which the task package belongs; in response to an abort command for the target queue, a status entry matching the target queue is found by using the queue flag.

[0013] A command processor, comprising: An interface for communicating with the task execution unit; One or more local buffers, each local buffer containing multiple status entries, the status entries including at least a sent flag, a reply flag, an abort flag, and a submit permission flag; Multiple local counters correspond one-to-one with multiple task queues. The initial value of a local counter is 0. It is incremented by 1 in response to receiving a task packet from the corresponding task queue and decremented by 1 in response to the submission of a task packet from the corresponding task queue. The abort processing unit, in response to an abort command for the target queue, iterates through the status entries of all local buffers: For status entries where the sent flag is set, set the abort flag; For status entries where the sent flag is not set, set the submission permission flag. The submission control unit, in response to a status entry with the sent flag set receiving a normal execution completion reply from the task execution unit through the interface, sets the reply flag and submission permission flag of the status entry, and decrements the local counter of the target queue by 1; and in response to a status entry with the sent flag not set being set by the abort processing unit setting the submission permission flag, decrements the local counter of the target queue by 1, and outputs a resource release confirmation signal when the local counter of the target queue reaches zero.

[0014] Furthermore, each status entry also records the queue flag of the queue to which the task package belongs, and the abort processing unit uses the queue flag to find a status entry that matches the target queue.

[0015] Furthermore, the abort processing unit is also configured to start a timer in response to the abort command, and trigger a system reset when the timer expires and the local counter of the target queue has not yet returned to zero.

[0016] Furthermore, the resource release confirmation signal is used to instruct the firmware to release the software resources occupied by the target queue; the submission license flag indicates that the command processor resources occupied by the corresponding task package can be released.

[0017] A task abort handling system, comprising: Firmware, used to issue task packages and abort commands for target queues; One or more task execution units are used to execute the received task package and return a normal execution completion response; The command processor, as described above, is electrically connected to both the firmware and the task execution unit.

[0018] Compared with the prior art, the present invention has the following significant advantages: 1. This invention uses the local counter returning to zero as the criterion for resource release, which is completely independent of the kill_done response returned by the task execution unit. This solves the problem of erroneous resource release or permanent system freeze caused by the reliance on the unreliable kill_done signal in traditional solutions, and fundamentally avoids the impact of abnormal task execution unit termination logic on system reliability. 2. Process tasks according to their sent status: unsent task packages are released directly and the counter is deducted for a fast response; sent task packages are released only after a normal completion response is received, ensuring that hardware resources are released. This shortens the interruption response time, ensures the security of resource reclamation, and avoids data corruption caused by resource conflicts. 3. By tracking the lifecycle of each task package through status entries and indicating the release of the entire queue by resetting the counter to zero, the decision logic for aborting completion is pushed down to the command processor side for execution. The firmware only needs to perform software resource reclamation when the counter is zero, without actively polling or intervening in the hardware decision process, which greatly reduces the complexity of firmware design and operating overhead. 4. This invention starts a timer when the abort command arrives. If the timeout occurs and the counter has not yet returned to zero, the system is reset. As the final guarantee for the counter zeroing mechanism, this invention solves the problem of permanent system freeze under extreme abnormalities such as complete unresponsiveness of the task execution unit, and further improves the availability and security of the system. Attached Figure Description

[0019] Figure 1 This is a flowchart of the task termination processing method of the present invention;

[0020] Figure 2 This is a structural diagram of the task termination processing system of the present invention. Detailed Implementation

[0021] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0022] Example 1

[0023] Example 1 illustrates the task abort handling method executed by the Command Processor (CP) as an example. Figure 1 This is the main flow of the method.

[0024] In one example, the CP corresponds to two task execution units (hereinafter referred to as C2C execution units), C2C execution unit 0 and C2C execution unit 1. The CP contains a local buffer, which contains multiple state entries. Each state entry corresponds to a task packet and is used to record the state information of the task packet throughout its complete lifecycle from receipt to release. The CP achieves fine-grained tracking of the state of each task packet through the local buffer.

[0025] The number of local buffers is the same as the number of task execution units, which is two in this embodiment. Each local buffer is dedicated to recording the status information of all task packets dispatched to a corresponding C2C execution unit. When a task packet is received by the CP, the CP stores the task packet in the local buffer corresponding to the C2C execution unit specified by the firmware.

[0026] Each C2C can execute 256 task packets in parallel, meaning there are 256 status entries. The task packets sent by the software come from five different task queues, from queue 0 to queue 4. A local counter is set for each task queue, resulting in a total of five local counters. A corresponding status entry is set for each task packet, containing a valid flag, a sent flag, a reply flag, a kill flag, and a commit permission flag. The valid flag indicates whether the status entry contains valid task packet information; it is set to 1 upon receiving a task packet from the firmware and set to 0 after the task packet is committed or the system restarts.

[0027] Each status entry also records the queue flag of the queue to which the task package belongs. Task packages from different task queues are stored together in various local buffers and distinguished by the queue flags recorded in the status entries. When the CP receives an abort command for the target queue, it iterates through the status entries in each local buffer to find the status entry whose queue flag matches that of the target queue, thus achieving precise location of all task packages in the target queue.

[0028] The local counter is initially set to 0, incremented by 1 upon receiving a task packet from the corresponding task queue, and decremented by 1 upon submission of a task packet from the corresponding task queue. Assume queue 0 has received 5 task packets from the firmware, its local counter currently counts as 5, and the validity flag for each task packet's status entry is set (valid=1). Task packets A, B, and C have been sent to the task execution unit, and their sent flag is set (sent=1); task packets D and E have not yet been sent, and their sent flag is not set (sent=0).

[0029] When the CP receives the abort command (kill_queue id=0) sent by the firmware for queue 0, queue 0 becomes the target queue. The CP traverses all status entries and searches for the status entry whose queue flag matches that of queue 0, i.e., the status entry corresponding to task packages A, B, C, D, and E.

[0030] For status entries with send=1 (task packages A, B, and C), the CP sets its abort flag (kill=1) and waits for the task execution unit to return a normal completion response (resp=1). Assuming task package B completes execution and the task execution unit returns a normal completion response, upon receiving this response, the CP sets the response flag and commit permission flag for the corresponding status entry of task package B (resp=1, commit_en=1), and decrements Counter_queue0 by 1 (from 5 to 4). Here, setting the commit permission flag and decrementing the counter are performed synchronously. Setting the commit permission flag indicates that the command processor has completed all the judgment work for the task package, while decrementing the counter indicates that the command processor has removed the task package from the "not yet released" statistics. Through this implicit correspondence, the command processor does not need to perform an additional "release action"; it only needs to decrement the counter to complete the release record of the task package resources on the command processor side. Similarly, after task packages A and C complete execution, Counter_queue0 is decremented by 1 (from 4 to 3, then from 3 to 2).

[0031] For status entries where the sent flag is not set (sent=0) (task packets D, E), the command processor sets the commit permission flag of these status entries (commit_en=1) directly when the abort command arrives, and decrements Counter_queue0 by 1 for each task packet processed (from 2 to 1, and then from 1 to 0).

[0032] When Counter_queue0 reaches zero, it indicates that all 5 task packets in the target queue have been released, and the command processor outputs a resource release confirmation signal to the firmware.

[0033] After receiving the abort command, the CP will still complete the execution of a single task packet at the task execution unit and return a normal completion response. However, for task queues, the execution unit will return an abort completion response (kill_done). Throughout the abort process, the command processor's determination of whether the target queue can be released is entirely based on whether the local counter reaches zero. This determination process does not depend on the abort completion response (kill_done) returned by the task execution unit at the target queue level. Even if the task execution unit does not return kill_done, returns an error kill_done, or does not respond to the abort command, as long as the normal completion responses of all issued task packets have been received and all unissued task packets have been directly released, the local counter will reach zero, and the command processor will output a resource release confirmation signal to the firmware. The resource release confirmation signal is used to instruct the firmware to release the software resources occupied by the target queue.

[0034] To improve reliability, a timeout timer (Kill_timer) can also be configured in the command processor. This timer provides a timeout protection mechanism during abort command processing, preventing permanent system freezes due to abnormal unresponsiveness of task execution units. Specifically, when the abort processing unit responds to an abort command for the target queue, the timer starts counting. Under normal circumstances, the target queue's local counter reaches zero before the timer expires, the command processor outputs a resource release confirmation signal to the firmware, the abort process is completed normally, and the timer stops or resets. If the timer reaches the preset timeout threshold and the target queue's local counter has not yet reached zero, it indicates an abnormal situation—such as internal logic freeze of the task execution unit, communication link failure, or loss of normal execution completion reply. In this case, the CP triggers a system reset, forcibly clearing all task execution units and the CP's internal state to prevent the system from waiting indefinitely. This timeout protection mechanism works in conjunction with the counter zeroing determination mechanism: counter zeroing provides accurate determination under normal circumstances, while timeout reset provides a fallback guarantee under abnormal circumstances. The preset timeout threshold of the timer can be set according to the system's maximum normal task execution time. In one example, the timer's count value ranges from 0 to 65535, with the preset threshold configured by the firmware.

[0035] Example 2

[0036] This embodiment provides a command processor (CP) and a task abort processing system containing the CP.

[0037] like Figure 2 As shown, the task abort processing system includes firmware, CP, and two C2C execution units, 0 and 1. The signal flow relationships between the components are shown in [reference needed]. Figure 2 As shown.

[0038] The firmware is used to convert the software requirements into task packages and send them to the CP. The firmware is also used to receive the software's process termination command and convert it into a termination command (kill_queue id) for the target queue and send it to the CP. It also receives the resource release confirmation signal output by the CP and releases the software resources (including task descriptors, data buffers, etc.) occupied by the target queue accordingly.

[0039] C2C is used to execute task packets dispatched by CP and return a "done" response to CP after the task packet has been executed normally. C2C can be a hardware module in the storage controller, such as an LDPC decoder, NAND Flash interface controller, or DMA controller.

[0040] The CP is electrically connected to both the firmware and the C2C execution unit. It is used to receive task packets issued by the firmware and dispatch them to the corresponding C2C execution unit, as well as to perform abort processing in response to abort commands sent by the firmware.

[0041] The CP includes a local buffer, multiple local counters, an abort processing unit, a commit control unit, and a timeout timer.

[0042] The number of local buffers is the same as the number of task execution units. In one example, a CP corresponds to two C2Cs (C2C execution unit 0 and C2C execution unit 1), therefore there are two local buffers, buffer0 and buffer1, used to record the status information of task packages dispatched to C2C execution unit 0 and C2C execution unit 1, respectively. Each local buffer contains 256 status entries, the same as the maximum number of task packages that each C2C execution unit can execute simultaneously.

[0043] Each status entry corresponds to a task packet and records its status information. This information includes a valid flag (valid), a sent flag (sent), a reply flag (resp), a killed flag (killed), and a commit permission flag (commit_en). The valid flag indicates whether the status entry contains valid task packet information. Each status entry also records the queue flag of the queue to which the task packet belongs. Task packets from five different task queues are stored together in two local buffers and distinguished by the queue flags recorded in the status entries.

[0044] The change logic for status entries is shown in Table 1: Table 1

[0045] Multiple local counters correspond one-to-one with multiple task queues. In one example, the task packets sent by the software come from 5 different task queues, so there are 5 local counters, corresponding to queues 0 to 4 respectively. The initial value of each counter is 0, and the counting range is 0 to 255. Taking Counter_queue0 corresponding to queue 0 as an example, Counter_queue0 is incremented by 1 every time the CP receives a task packet belonging to queue 0 from the firmware; Counter_queue0 is decremented by 1 every time a task packet belonging to queue 0 is submitted. Therefore, the current count value of Counter_queue0 always represents the number of task packets in queue 0 that have been received by the CP but have not yet been released.

[0046] The abort processing unit responds to the abort command (kill_queue id) sent by the firmware for the target queue. It iterates through all status entries in all local buffers and searches for a status entry that matches the target queue by checking the queue flag recorded in each status entry. For status entries where the sent flag is set (sent=1), the abort processing unit sets its abort flag (killed=1) and waits for the C2C to return a normal execution completion reply (resp=1). For status entries where the sent flag is not set (sent=0), the abort processing unit directly sets its commit permission flag (commit_en=1).

[0047] The submission control unit is used to respond to a normal execution completion reply from C2C ​​when a status entry with the sent flag set (sent=1) receives a reply from C2C, setting the reply flag and submission permission flag of the status entry (resp=1, commit_en=1), and decrementing the count value of the local counter corresponding to the target queue by 1; and to respond to a status entry with the sent flag not set (sent=0) when the abort processing unit sets the submission permission flag (commit_en=1), and decrements the count value of the local counter corresponding to the target queue by 1.

[0048] In this embodiment, the setting of the commit permission flag and the decrementing of the local counter are performed simultaneously. Setting the commit permission flag indicates that the CP resources occupied by the corresponding task package can be released, while decrementing the counter indicates that the CP has removed the task package from the "not yet released" statistics. The CP does not need to perform any additional, independent "release action"; the combined action of "setting the commit permission flag + decrementing the counter" itself is a complete manifestation of the release of the task package on the CP side.

[0049] When the local counter corresponding to the target queue reaches zero, the submission control unit outputs a resource release confirmation signal to the firmware. The basis for this signal output is the local counter reaching zero, not the abort completion response (kill_done) returned by the C2C side. Even if the C2C does not return kill_done or returns an incorrect kill_done, as long as the local counter of the target queue reaches zero, the submission control unit will still output the resource release confirmation signal.

[0050] The CP also includes a timeout timer (Kill_timer), electrically connected to the abort processing unit. This timer starts counting when the abort processing unit responds to an abort command for the target queue. Under normal circumstances, the target queue's local counter reaches zero before the timer expires, submitting a resource release confirmation signal to the control unit, the abort process is completed normally, and the timer stops counting.

[0051] If the target queue's local counter has not yet reached zero when the timer reaches the preset timeout threshold, it indicates an abnormal situation—such as a dead logic within the C2C execution unit, a communication link failure, or loss of a normal execution completion reply. In this case, the CP triggers a system reset, forcibly clearing all local counters, clearing all status entries, and resetting the system to prevent indefinite waiting. The preset timeout threshold for the timer can be configured by the firmware; in one example, the timer's count value ranges from 0 to 65535.

[0052] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for handling task abort, characterized in that, The method, executed in a command processor, includes: A local counter is set for each task queue. The local counter is initially set to 0, incremented by 1 in response to receiving a task packet for the corresponding task queue, and decremented by 1 in response to the submission of a task packet for the corresponding task queue. Set a corresponding status entry for each task package. The status entry shall at least include a sent flag, a reply flag, an aborted flag, and a submission permission flag. In response to receiving a task packet, increment the local counter of the task queue to which the task packet belongs by 1; In response to sending the task package to the task execution unit, the sent flag of the corresponding status entry is set; In response to an abort command targeting the queue: For a status entry where the sent flag is set, set its abort flag, and after receiving a normal execution completion reply from the task execution unit, set the reply flag and submission permission flag of the status entry, and decrement the local counter of the target queue by 1. For status entries where the sent flag is not set, directly set the submit permission flag of the status entry and decrement the local counter of the target queue by 1; When the local counter of the target queue reaches zero, a resource release confirmation signal is output.

2. The task termination processing method according to claim 1, characterized in that, The resource release confirmation signal is used to instruct the firmware to release the software resources occupied by the target queue, and the submission license flag indicates that the command processor resources occupied by the corresponding task package can be released.

3. The task termination processing method according to claim 1, characterized in that, The task abort handling method is independent of the abort completion reply of the task queue returned by the task execution unit.

4. The task termination processing method according to claim 1, characterized in that, Also includes: In response to the abort command, a timer is started. If the timer times out and the local counter of the target queue has not yet reached zero, a system reset is triggered.

5. The task termination processing method according to claim 1, characterized in that, Each of the status entries also records the queue flag of the queue to which the task package belongs; in response to an abort command for a target queue, a status entry matching the target queue is found by using the queue flag.

6. A command processor, characterized in that, include: An interface for communicating with the task execution unit; One or more local buffers, each local buffer containing multiple status entries, the status entries including at least a sent flag, a reply flag, an abort flag, and a submit permission flag; Multiple local counters correspond one-to-one with multiple task queues. The initial value of a local counter is 0. It is incremented by 1 in response to receiving a task packet from the corresponding task queue and decremented by 1 in response to the submission of a task packet from the corresponding task queue. The abort processing unit, in response to an abort command for the target queue, iterates through the status entries of all local buffers: For status entries where the sent flag is set, set the abort flag; For status entries where the sent flag is not set, set the submission permission flag; The submission control unit, in response to a status entry where the sent flag is set, receives a normal execution completion reply from the task execution unit through the interface, sets the reply flag and submission permission flag of the status entry, and decrements the local counter of the target queue by 1; In response to the state entry where the sent flag is not set being set by the abort processing unit to submit the permission flag, the local counter of the target queue is decremented by 1, and a resource release confirmation signal is output when the local counter of the target queue reaches zero.

7. The command processor according to claim 6, characterized in that, Each status entry also records the queue flag of the queue to which the task package belongs. The abort processing unit uses the queue flag to find a status entry that matches the target queue.

8. The command processor according to claim 6, characterized in that, The abort processing unit is also configured to start a timer in response to the abort command, and trigger a system reset when the timer expires and the local counter of the target queue has not yet returned to zero.

9. The command processor according to claim 6, characterized in that, The resource release confirmation signal is used to instruct the firmware to release the software resources occupied by the target queue; the submission license flag indicates that the command processor resources occupied by the corresponding task package can be released.

10. A task abort processing system, characterized in that, include: Firmware, used to issue task packages and abort commands for target queues; One or more task execution units are used to execute the received task package and return a normal execution completion response; And, the command processor as described in any one of claims 6 to 9, is electrically connected to the firmware and the task execution unit, respectively.

Images