QUEUE FULL discussion, continued.

Ericson, George gericson at clariion.com
Thu Oct 28 13:30:06 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "Ericson, George" <gericson at clariion.com>
*
Works for me.
Thanks 
George

-----Original Message-----
From: Bob Snively [mailto:Bob.Snively at EBay.Sun.COM]
Sent: Thursday, October 28, 1999 1:26 PM
To: T10 at t10.org; BillG at breatech.com
Subject: RE: QUEUE FULL discussion, continued.


* From the T10 Reflector (t10 at t10.org), posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>
*

Bill,

I too would put option 1 in my purchase spec.  In the case of a device that
supports n initiators (where n better be greater than 16 on Fibre Channel),
the command from the n+1th initiator should behave according to option 2,
making it the standard, as you indicate.  However, I believe a very strongly
worded statement in the standard favoring the implementation of option 1
for some appropriate number of initiators is very desirable.  Thus the
"optimal snively wording" would be:

    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.
    >> The logical unit should 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. The number of initators that can be supported before
    task resources are exhausted is vendor specific.<<

Bob



>From: "Bill Galloway" <BillG at breatech.com>
>To: <T10 at t10.org>
>Subject: RE: QUEUE FULL discussion, continued.
>Date: Wed, 27 Oct 1999 21:13:59 -0500
>*
>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

*
* 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