> On Mon, Oct 23, 2000 at 07:41:20PM +0200, Manuel Bouyer wrote:
> > > 
> > > Your typical disk drive will manage at least 64 tags these days w/o sending
> > > back QFULL.
> > 
> > Ok, I'll keep this in mind.
> 
> BTW, how do you manage QFULL ? wait for one command to end to start
> queuing commands again, or a more intelligent algorithm ?

'It depends'.

Mostly the QLogic f/w just plain handles this and I don't have to see a
QFULL. Actually, if I see a QFULL, it's usually because I overflowed some
resource in the QLogic - and it generates a QFull status (kind of bogus).

But the correct answer is, yes, wait for a command to complete. QFull is
stating that the device cannot take any more commands because it has reached
the limit of the number of commands it can take. This is unlike BUSY which
says, "I'm busy- come back later" (at some undefined time 'later').

The algorithm that FreeBSD/CAM uses is:

1. Queue the maximum you can until you start getting QUEUE FULL
2. Back off the local limit to this value minus one.
3. Repeat #1-#2 as necessary.


What this tends to do is to put a high initial load on a disk, and then you
start backing off. What this doesn't take into account is that the QFULL
condition is not a fixed/static condition- some drives trade off transfer size
and number of active jobs, so depending on what you're doing, and old QFULL
limit may not longer be required.

I tend to think the algorithm should be:


1. Queue the maximum you can until you start getting QUEUE FULL
2. Back off the local limit to this value minus one.
3. Wait until the next idle period, where idle period is 'no commands running
for at least 100 ms.' and increment the QUEUE FULL limit by one.
4. Repeat #3 until you get a QUEUE FULL and go back to #1.


Note that it is properly the midlayer that should be evaluating this- not the
HBA.

-matt