.fo off .pl 64 .tm 0 .bm 0 Date: Mar 14, 1992 X3T9.2/91-098 Rev 5 To: X3T9.2 Committee (SCSI) From: George Penokie (IBM) Subject: SCSI-3 Queuing Model Note: The following list of words are barred from SCSI-3: - execution -executing -execute - Active I/O Process - - Queued I/O Process - | 0. Queue | | A group of I/O Process contained within a device which have | not been completed. 1. Active I/O Process The concept of an Active I/O Process will not be used in SCSI-3. 2. Queued I/O Process The concept of a Queued I/O Process will not be used in SCSI-3. 3. Current I/O Process 3.1 Current I/O Process (SAM document) The Current I/O Process is an I/O Process which is in the | process of sending or receiving information on the physical | transport system. More than one Current I/O Process may exist at a time within the physical transport system. 3.2 Current I/O Process (SIP document) A Current I/O Process begins when arbitration is won and ends with the release of BUSY. 3.3 Current I/O Process (SBP document) | A Current I/O Process begins at the start of an information | packet and ends at the end of an information packet. At any given time there may be multiple packets within the physical transport system. | 4. Pending I/O Process An I/O Process which is not a Current I/O Process. 5. Simple I/O Process (Simple Tag) | When an I/O Process is tagged as a Simple I/O Process and | if only Simple I/O Processes are on the queue then the Simple | I/O Process may become a Current I/O Process at any time. 6. Ordered I/O Process (Ordered Tag) Before (Option 1): When an I/O Process is tagged as an Ordered I/O Process the target shall not: | -Send media information for the Ordered I/O Process, | -Received media information for the Ordered I/O Process, or -Complete the Ordered I/O Process until all I/O Processes received before an Ordered I/O Process have completed. Before (Option 2): When an I/O Process is tagged as an Ordered I/O Process it shall not complete until all I/O Processes received before the Ordered I/O Process have completed. | Before (Option 2 Alternate wording) | | When an I/O Process is tagged as an Ordered I/O Process it | shall complete as if the target had no Pending I/O Processes | when the Ordered I/O Process initial connection occurred and | must complete as if no other I/O Processes became current | before the Ordered I/O Process completes. | <> I/O Process have completed. After (Option 1): If Simple I/O Processes are received after an Ordered I/O Process the Target may, for any or all of the Simple I/O Processes: -Send media information for the Simple I/O Process, -Request media information for the Simple I/O Process, or -Complete a Simple I/O Process before the Ordered I/O Process completes. After (Option 2): If Simple I/O Processes are received after an Ordered I/O Process the Target shall not: -Send media information for the Simple I/O Process, -Request media information for the Simple I/O Process, or -Complete a Simple I/O Process before the Ordered I/O Process completes. After (Option 3): If Simple I/O Processes are received after an Ordered I/O Process there is no guaranteed that the ordered will complete before some or all of the Simple I/O Processes. After (Option 4): Any I/O Processes received after an Ordered I/O Process shall not complete until the Ordered I/O Process is complete. 6.1 Degree of Ordering The degree of ordering within a Logical Unit may be either on a per initiator or a per target bases and is selectable by a mode bit. When the degree of ordering is per initiator the Logical unit shall keep a separate logical queue for each initiator. The sequence of I/O Process completion is only dependent on I/O Processes within that Initiators queue. When the degree of ordering is per target the Logical unit shall keep a single queue for all initiators. The sequence of I/O Process completion is dependent of the type and sequence of I/O Processes received by the Logical Unit. 7. Head Of Queue I/O Process (Head of Queue Tag) When an I/O Process is tagged as a Head Of Queue I/O Process it shall complete before any I/O Processes received after the Head Of Queue I/O Process. Any I/O Process which was received before a Head Of Queue I/O Process may complete before the Head Of Queue I/O Process completes. 8. Priority I/O Process (Priority Queue Tag) | When an I/O Process is tagged as a Priority I/O Process the | Target should attempt to complete the Priority I/O Process | before any I/O Processes received after the Priority I/O | Process. The Target should, also, attempt to complete the | Priority I/O Process before any I/O Processes which were | received before a Priority I/O. 9. I/O Process Processing 9.1 I/O Process Processing (SAM document) A target that can accept more than one I/O Process is capable of queueing. The number of I/O Processes that may exist is dependent on the design of the target. | Note: Several commands may be linked together to form a | single I/O Process. 9.0.1 I/O Process Processing (SIP document) The target may have any number of queues up to a maximum of one queue per I_T_L nexus. If an initiator attempts to send more I/O Processes to a target than can be accepted, they are rejected. I/O Processes that are queued may be Untagged or Tagged. 9.0.2 I/O Process Processing (SBP document) <> 9.1 Untagged | Untagged queuing allows a Target to accept an I/O process | for a Logical Unit or Target routine while there are Pending | I/O Processes for other devices. Only one I/O Process for | each I_T_x Nexus shall be accepted at a time. (i.e., a queue | depth of one) 9.2 Untagged I/O Processes An I/O Process which establishes an I_T_L nexus. 9.3 Tagged The initiator can have more than one Tagged I/O Process for each Logical Unit under control of the target. The target has the freedom to optimize the sequence of I/O Process completion unless the initiator chooses to override the optimization. 8.4 Tagged I/O Processes I/O Processes which establish an I_T_L_Q nexus. 10. Exception Handling 10.1 Auto Contingent Allegiance Condition (ACA) 10.0.1 Auto Contingent Allegiance Condition (ACA) (SAM document) | When the Auto Contingent Allegiance Condition is being used a | Check Condition shall not clear the I_T_x_y nexus for the I/O | Process which caused the Check Condition. The Auto Contingent Allegiance Condition Shall exist across all Initiators following the return of a Check Condition or Command Terminated status. The Auto Contingent Allegiance Condition shall be preserved for the I_T_x_y nexus until it is cleared. An I/O Process that clears the Auto Contingent Allegiance shall not be treated any differently than if it had been received without an Auto Contingent Allegiance. 10.0.2 Clearing Auto Contingent Allegiance Condition (ACA) (SIP document) The Auto Contingent Allegiance Condition shall be cleared upon the receipt of: -a hard reset condition, -an Abort message, -a Clear Queue message, -a Bus Device Reset message, or -on the receipt of any subsequent non-Head Of Queue I/O Processes. The Auto Contingent Allegiance is not cleared upon the receipt of: -an Abort Tag message -or receipt of a Head Of Queue I/O Process. While the Auto Contingent Allegiance exists the target shall respond to any other request for access to the logical unit from any device, other than the one which has the Auto Contingent Allegiance Condition, with a Busy status. And the Target shall not allow any existing Non-Current I/O Processes to become Current I/O Processes. An initiator which has an outstanding Auto Contingent Allegiance Condition may allow other devices to use the target by sending a Release Recovery message for the affected I_T_x_y nexus. After the Target receives the Release Recovery message Non-Current I/O Processes for unaffected I_T_x_y nexuses may become Current I/O Processes. 10.0.2 Clearing Auto Contingent Allegiance Condition (ACA) (SBP document) <> 10.2 Exception Checking | The handling of transmission errors is Target specific. Untagged and tagged I/O Processes may be intermixed. The handling of the untagged I/O Processes in the queue is vender specific. There is no requirement that the untagged I/O Processes comply with the SCSI-3 queueing model. If a tagged I/O Process is received with an invalid tag the target shall create an Auto Contingent Allegiance with a key of Illegal Request, an ASC of Tagged Overlapped Commands, and an ASCQ which contains the value of the illegal tag. (Note: This requires a new ASC; 4Dh is recommended.) NEEDS RESOLUTION: Does a duplicate nexus abort only the duplicate I/O Processes and enter an ACA condition, does it abort all I/O Processes for that initiators queue, or does it abort all I/O Processes???