Queuing and ACA

James Smart USG smart at zk3.dec.com
Tue May 5 19:12:03 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* James Smart USG <smart at zk3.dec.com>
*

I concur with your reading of the standard.

In thinking about your comments on out of order delivery due to BUSY/ACA
ACTIVE, if I'm on an interlocked bus (e.g. parallel scsi) or in a single
initiator environment, this doesn't bother me too much. In these scenarios
the initiator knows exactly what has and has not been received and should be
able to manage this appropriately However, smart adapters may cloud this 
(only in a multi-initiator environment) as the hba driver may have been able
to know this, but only the class driver pays attention to the status and
that may be after the hba attempts to start another io.

Ordering does bother me with a disconnected or packetized bus in which
packets may be in flight and where multiple initiators exist. Io's from a
non-faulting initiator may have some ios accepted, some rejected, and some
later accepted depending on what's in flight and how that flight relates
to how quickly the faulting initiator clears the ACA condition.

Re: the purpose of ACA ACTIVE - this is the basic notification to the faulting
initiator to initiate recovery. If you pile the commands up - the faulting
initiator is never told to start recovery (issuing ios w/ the ACA active
indicator) followed by a CLEAR ACA to turn the condition off. BUSY only
implies the same action if there is no recovery function to perform
(which is true on the non-faulting initiators). An example of a recovery
function is one in which the initiator wants to be notified of a recovered
media error, so it can they query or change the device and/or media state,
before allowing the device to continue flushing its command quue.

-- James


-------- Begin Forwarded Message

From: "Joseph C. Nemeth" <jnemeth at concentric.net>
To: "T10 Reflector" <t10 at symbios.com>
Subject: Queuing and ACA
Date: Tue, 5 May 1998 14:39:40 -0600
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-t10 at symbios.com
Precedence: bulk
Status: R

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Joseph C. Nemeth" <jnemeth at concentric.net>
*
I'm going over the whole SCSI-3 queuing process a final time, and I want to
make sure I  understand what is supposed to happen here. The issue has to do
with a fine point of implementation of the queuing process, and how it
affects the order in which commands are completed.

As I understand this, when the NACA condition goes into effect, the command
queue for a device/LUN effectively freezes completely. Dormant tasks remain
dormant. Enabled tasks become blocked, including the current task. New
non-ACA-queue commands sent to the device are immediately bounced without
even being queued, with ACA ACTIVE status. New ACA-queue commands from the
faulting initiator are immediately entered in the enabled state, and since
everything else is dormant or blocked, they execute immediately, effectively
bypassing the queue entirely.

Therefore, the ACA ACTIVE status results (technically) in an out-of-order
completion of commands received before and after NACA goes into effect:
commands received and queued before NACA occurs remain frozen in the queue
until NACA is cleared by the faulting initiator, but commands received after
NACA occurs complete immediately with ACA ACTIVE status.

Is this correct?

The implementation issue I'm facing is that I have two places I apparently
need to reject a command: prior to queuing, and after dequeuing. As I'm
understanding the standards, there should be only two cases where an
ordinary command should be rejected prior to queuing (which has the side
effect of potentially completing these commands out-of-order) -- with BUSY
status if the
queue itself is simply full, and can't accept another command of any sort;
and with ACA STATUS if NACA is in effect, and the queue is frozen, and this
command is not an ACA-queue command from the faulting initiator.

Is this essentially correct?

I still do not quite understanding the underlying purpose of the ACA ACTIVE
status, as opposed to simply letting new commands pile up in the blocked
queue, or bouncing them with a simple BUSY status, since the initiator
recovery action for ACA ACTIVE is exactly the same as for BUSY -- try again
later.

Joseph C. Nemeth, Precision Algorithms



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com


-------- End of Forwarded Message




James Smart                                            email: smart at zk3.dec.com
Alpha UNIX Systems - Digital Equipment Corp.           Phone: 603-884-2472
110 Spit Brook Road,    Nashua, NH  03060              Fax  : 603-884-2257
Disclaimer: My statements and opinions reflect my own thinking and are not
   necessarily reflective of any employer or association.

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list