QUEUE FULL discussion, continued.

Gerard Roudier groudier at club-internet.fr
Thu Oct 28 15:29:24 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerard Roudier <groudier at club-internet.fr>
*


On Thu, 28 Oct 1999, Bob Snively wrote:

> The real problem is that BUSY status is often retried by a host adapter
> at a level that does not permit any logic to be applied to the recovery
> algorithm.  QUEUE FULL is often sent back to a higher level retry
> algorithm that allows more intelligent scheduling of the retry algorithm
> and is capable of associating the "fullness" with other activities that
> are going on.  This separation of functions between host adapters and
> drivers does not make the aliasing simple.  If the logical unit asks for the
> behavior it wants with the proper status, that is a much better solution.
> It either wants "blind" retry or "scheduled" retry.

The "retry problem" is not the more serious one. We also must allow the
software to recover without _disordering_ actual IOs when some order is
required. The deal with the host adapter firmware and the O/S software you
describe does not look that clean to me in this regard.

If the aim of this change of the specifications is to allow existing
flawed adapters or flawed software SCSI sub-system implementations to look
good, then I may understand, but certainly not agree. We must fix what is
broken, and for now, the current spec does not appear broken to me and the
new proposals donnot seem to me to improve anything.

I totally disagree with changing the specs by any of the propositions that 
have been posted about this topic. But, anyway, this is certainly not 
important at all, given my position.

I just wanted to let know my opinion. Thanks to people who read my
postings.

Gérard.

> Bob
> 
> >
> >
> >If I summerize the proposition:
> >
> >mechanism 1)  Ensure at least 1 command is queuable for each initiator
> >
> >mechanism 2)  Return BUSY instead of QUEUE FULL if a task cannot be 
> >              entered into the task set and the initiator has no
> >              oustanding commands for that device.
> >
> >Mechanism 1) is not always possible.
> >Mechanism 2) is always possible.
> >
> >But in my opinion, mechanism 2) is just a no-change and even may look 
> >like regression since:
> >
> >1) Aliasing QUEUE FULL to BUSY when no other command is active 
> >   is generally pretty trivial to implement from the initiator.
> >
> >2) Telling the initiator that the device is BUSY makes less relevance  
> >   than telling it that the cause of the reject was due to a lack of
> >   resource for queuing the task.
> >
> >I am sorry, but I didn't see the improvement of mechanism 2 over the
> >current specification that suggests returning QUEUE FULL regardless the 
> >actual number of commands in the task set for that initiator.
> >
> >The real problem is not the value of the status the initiator receives
> >from the device, but the fact that the initiator has to _delay_ the retry
> >of the queuing. May-be some annex that would suggest how to deal with
> >"queue full condition with the queue being actually empty as seen from the
> >initiator" would be the right thing to do, instead of changing the
> >specification.
> >
> 
> >
> >On Wed, 27 Oct 1999, George Ericson wrote:
> >
> >> * From the T10 Reflector (t10 at t10.org), posted by:
> >> * "George Ericson" <gericson at mindspring.com>
> >> *
> >> Bob,
> >> Good write-up.  Thanks.
> >> 
> >> Mechanism 1 doesn't work well for switched FibreChannel or for large
> >> DiskArrays because of a combination of a potentially large number of
> >> initiators and some interface chip implementations that have relatively
> >> tight resource restrictions.
> >> 
> >> Mechanism 2 will work fine.
> >> 
> >> Regards
> >> George Ericson
> >> 
> >> -----Original Message-----
> >> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Bob
> >> Snively
> >> Sent: Thursday, October 21, 1999 4: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






More information about the T10 mailing list