Lockless NVMe IO Abort via Register Abort Bit
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional approaches to aborting NVMe IO commands in storage systems require computationally heavy 'lock' and 'unlock' operations for every IO command, even if not being aborted, which hinders performance and is undesirable during the aborting process.
Innovation Solution
A method that generates an IO command-specific entry in a register with parameters like NVMe Subsystem, controller, and submission queue identifiers, using a compare-and-swap operation to determine and modify the IO command state without locking, allowing for state consistency and efficient aborting of IO commands.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional lock and unlock operations are used for every IO command, then command state consistency is maintained, but performance is degraded due to computationally heavy operations
Solution Approach 1:
The patent extracts the locking mechanism from the IO command processing path by using a dedicated abort bit in the command register. This allows the completion flow to proceed without acquiring locks, while only the abort path needs to modify the abort bit, thereby eliminating the performance penalty of lock/unlock operations for normal command completion while maintaining state consistency through the abort bit mechanism
Solution Approach 2:
The patent introduces an intermediary abort bit in the command register that mediates between the completion flow and abort flow. The completion flow checks this abort bit without needing locks, and the abort flow sets this bit to signal cancellation. This intermediary mechanism enables both flows to operate concurrently without requiring computationally heavy lock operations, thus resolving the contradiction between reliability and performance
2Reliability
If lock operations are performed for every IO command including non-aborted commands, then state consistency is ensured, but the number of memory operations increases from one to four
Solution Approach 1:
The patent removes the locking mechanism from the general IO command processing path and extracts only the essential abort signaling function. By placing an abort bit directly in the command register, the system eliminates the need for separate lock/unlock memory operations for each command, reducing the memory operation count from four (lock, check, process, unlock) to one (abort bit check or set), while maintaining state consistency through the abort bit
3Speed
If spinning in the completion flow during abort is implemented, then abort responsiveness is improved, but system resources are wasted and performance is degraded
Solution Approach 1:
The patent introduces an abort bit as an intermediary signal between the abort initiation and the actual command termination. When an abort is requested, the abort bit is set in the command register, and the completion flow checks this bit to determine whether to terminate the command. This intermediary mechanism provides immediate abort responsiveness without requiring the completion flow to spin, as the abort bit serves as a clear signal that can be checked efficiently without continuous polling or spinning
Solution Approach 2:
The completion flow is designed to self-check the abort bit status without external intervention or spinning. Each time the completion flow processes a command, it automatically checks the abort bit and acts accordingly. This self-service approach eliminates the need for active spinning or continuous resource allocation, providing responsive abort handling while minimizing computational resource waste
Data Source
AI summary
A method, computer program product, and computing system for receiving an input/output (IO) command for processing data within a storage system. An IO command-specific entry may be generated in a register based upon, at least in part, the IO command. An compare-and-swap operation may be performed on the IO command-specific entry to determine an IO command state associated with the IO command. The IO command may be processed based upon, at least in part, the IO command state associated with the IO command.