QUEUE FULL discussion, continued.

[Ericson, George]

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

The reason folks are looking to "clarify" the standard is to promote
interoperability.  Currently, the standard allows both devices and driver
writers to pick from a number of ways to handle "out of resource" scenarios.
Unfortunately, some legal ways are not very friendly to high end devices
that support many initiators and many Logical Units.

Since this primarily affects Fibre Channel devices, the solution could be
narrowed in scope and moved from SAM to FCP-SCSI.  However I'd rather solve
it at the ULP level across all LLPs rather than individually for each LLP.

George

-----Original Message-----
From: Stephen Byan [mailto:Stephen.Byan at quantum.com]
Sent: Friday, October 29, 1999 2:35 PM
To: T10 at t10.org
Subject: RE: QUEUE FULL discussion, continued.


* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen Byan <Stephen.Byan at quantum.com>
*
Bob Snively [mailto:Bob.Snively at EBay.Sun.COM] 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.

It seems to me that the current wording allows returning QUEUE FULL, even if
the initiator doesn't have any queued commands at the device. I think that's
the right thing to do. The higher level device driver in the initiator
certainly knows if it has outstanding I/O to the device. If it does have
outstanding I/O, then it can wait for a completion a la Bob's mechanism #1,
otherwise it can retry after a timed interval (possibly zero) a la Bob's
mechanism #2.

I don't understand the need for the change in the specification; it seems
easy enough to handle the slightly perverse case of "QUEUE FULL with no
outstanding I/O" in the higher level device driver in the initiator. Why
does the spec need to prevent this case? Is it just to remove the need to
code duplicate timed-retry routines, one in the lower-level software (CAM)
and one in the higher-level software (device driver)?

What have I missed?

Regards,
-Steve
---
Steve Byan <stephen.byan at quantum.com>
Design Engineer 
Quantum Corporation <http://www.quantum.com>
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
voice: (508) 770-3414 
fax: (508) 770-2604
*
* 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