QUEUE FULL discussion, continued.

Bill Galloway BillG at breatech.com
Wed Oct 27 19:13:59 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill Galloway" <BillG at breatech.com>
*
Bob,

I think option 2 is the right one for the standard.  It is something that
everyone should be able to implement.  I actually prefer option 1 but I think
that could be handled in a purchase spec. This would mean that initiators would
implement option 2 just in case, but in a well behaved system they would never
see this busy.


Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at breatech.com

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Bob
Snively
Sent: Thursday, October 21, 1999 3:18 PM
To: T10 at t10.org
Subject: QUEUE FULL discussion, continued.


* From the T10 Reflector (t10 at t10.org), posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>
*
I believe that the returned status should more properly indicate what the
recovery/retry algorithm should be for the rejected command.  Since this
can be done at a low level, well below the levels that actually have a list
of the active commands on a logical unit, then the status should be
interpretable without that knowledge.  The target/logical unit combination
has a clear knowledge of whether a rapid retry will be useful, or whether
tasks must first be cleared for the ITL nexus before a retry is useful.

In the case where a rapid retry is likely to be successful, BUSY should
be used.  The recovery mechanism is to retransmit the rejected command
according to an appropriate back-off algorithm.

In the case where it is unlikely that a retry will be successful until
some commands have been cleared for the ITL nexus, QUEUE FULL should
be used.  The recovery mechanism is to wait until a command is completed for
the ITL nexus, then to retry the rejected command.  The completion serves as
a "device is probably ready" interrupt.

There are two mechanisms that could provide this capability.

Bob's mechanism 1)

The mechanism we have recommended to all our suppliers is to be sure that
there is always at least one command resource available for each
identified initiator.  That way, a QUEUE FULL status will never occur
on a first command (since it will always be accepted)
and, if QUEUE FULL status is ever presented, then the
initiator can be certain that a command will come back to serve as
a timing signal for the retry of the rejected command.  Note that this
entirely ducks the issue by making the "tagged" X "None, TST=000b" case
never rejected.

Bob's mechanism 2)

The second mechanism would be to disallow the presentation of a QUEUE FULL
indication if no command is outstanding and no implicit timing signal would
be available to indicate that the rejected command should be retried.  That
would require the first command outstanding to be rejected with BUSY status
if no resources were available.  Untimed retries with an appropriate
back-off mechanism would then be attempted until the command was accepted.
If a command had already been accepted for the ITL nexus, only then could
QUEUE FULL be generated.  This would require the "tagged" X "None, TST=000b"
case to become a BUSY case, not a TASK SET FULL case.



   Old text:

   	TASK SET FULL. This status shall be implemented if the logical unit
   	supports the creation of tagged tasks (see 4.9). This status shall be
   	returned when the logical unit receives a command and does not have
   	enough resources to enter the associated task in the task set.

   New text minus strikeouts:

   	TASK SET FULL. This status shall be implemented if the logical unit
   	supports the creation of tagged tasks (see 4.9). This status shall not
   	be implemented if the logical unit does not support the creation of
   	tagged tasks. When the logical unit has at least one task in the task
   	set and lack of task set resources prevents entering a newly received
   	tagged task in the task, TASK SET FULL shall be returned. When the
   	logical unit has at least one task in the task set and lack of task set
   	resources prevents entering a newly received untagged task in the task,
   	BUSY should be returned.


   Bob's suggested text using the first proposed mechanism:

   	TASK SET FULL. This status shall be implemented if the logical unit
   	supports the creation of tagged tasks (see 4.9). This status shall not
   	be implemented if the logical unit does not support the creation of
   	tagged tasks. When the logical unit has at least one task in the task
   	set and lack of task set resources prevents entering a newly received
   	tagged task in the task, TASK SET FULL shall be returned. When the
   	logical unit has at least one task in the task set and lack of task set
   	resources prevents entering a newly received untagged task in the task,
   	BUSY should be returned. >> The logical unit shall always allow at least
   	one queued command for each initiator that has identified itself to the
   	target by a protocol specific logon procedure or by the execution of
   	a command. <<

   Bob's suggested text using the second proposed mechanism:

	TASK SET FULL. This status shall be implemented if the logical
	unit supports the creation of tagged tasks (see 4.9). This
	status shall not be implemented if the logical unit does not
	support the creation of tagged tasks. When the logical unit has
	at least one task in the task set >>for that initiator<< and
	lack of task set resources prevents entering a newly received
	tagged task in the task, TASK SET FULL shall be returned.
	>>When the logical unit has no task in the task set for that
	initiator and lack of task set resources prevents entering a
	newly received tagged task in the task set, BUSY shall be returned.<<
	When the logical unit has at least one task in the task set and
	lack of task set resources prevents entering a newly received
	untagged task in the task, BUSY should be returned.

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

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






More information about the T10 mailing list