QErr and basic queuing

Gerry Houlder Gerry_Houlder at notes.seagate.com
Mon Feb 17 18:58:01 PST 1997

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
I'd like to address the question of what is "easiest" for the target:

>With respect to Ralph's proposal to handle potential UA deadlock as it applies
>to the basic queing model, Is it really easier for a drive to abort all tasks
>on a CHECK CONDITION rather than preserving them?
>Initially, I had assumed without question that an implied CLEAR TASK set was
>simpler. The potential multi-initiator deadlock issue has led us in Digital to
>question whether that assumption is true under the circumstances.

If the drive has to abort tasks, it is much easier to do CLEAR TASK SET that to 
do ABORT TASK SET. The basic difference is that all commands are aborted for 
CLEAR TASK SET and only commands for one initiator are aborted for ABORT TASK 

Example: CLEAR TASK SET can unconditionally clear all command staging queues 
and stop all disk activity. ABORT TASK SET must examine each disk activity, 
determine which command is it associated with, determine which initiator that 
command is associated with, then decide whether to abort that activity. If the 
target decides not to abort the activity, it still may need to be suspended 
(lost disk rev) while all of the staging queues are examined to decide which 
commands should be aborted from these queues. After all, we wouldn't want one 
command to complete, then start on another command that is supposed to get 
aborted while we are deciding which other commands to abort, would we? The 
extra conditional testing of each command queue stage and disk hardware makes 
it much more difficult to abort some commands instead of all commands.

Jim McGrath's intent for basic queuing is the simplest target activity, which 
is defined as '01' in Ralph's new QErr field. The point of all this is that 
once the extra complication of aborting some commands (instead of all) is added 
to the drive firmware, you are only 2 or 3 lines of code away from FULL queuing 
support. We don't need another gradient of queuing functionality between full 
support (which already is supported by all the disc vendors if you want it) and 
ATA equivalent single initiator support (which is what the basic queue model 
was originally intended for).

I keep hearing that system companies want to buy the "basic queuing" drive and 
use it in a multi-initiator system so they can make use of "cheaper drives". 
This is the equivalent of asking for an extension to "arbitration without 
attention" so you don't have to use the identify message to get multiple 
initiator support. This is a bad idea -- it is better to use the already 
defined extensions to full functionality instead of a crippled in-between 
implementation that will end up costing just as much as the full implementation.

In Summary, keep this fact in mind: basic queuing was intended to describe a 
particular simple target implementation. Let's not redefine basic queuing as 
something else that doesn't match what the drive has implemented!
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list