> Since your drive cannot handle 253 tags, when saturated with commands,
> a new command is never submitted to the drive directly. Instead the
> command waits in the aic7xxx driver's queue until space is available
> on the device. In FreeBSD, this never happens as tag depth is known
> to, and adjusted by, the mid-layer. In Linux I must report the queue
> depth without having sufficient load or history with the device to
> know anything about its capabilities so I have no choice but to
> throttle internally should the device support fewer tags than
> initially reported to the OS. You can determine the actual device
> queue depth from "cat /proc/scsi/aic7xxx/#". Run a bunch of I/O first
> so that the tag depth gets locked first.
Linux is perfectly happy just to have you return 1 in queuecommand if the
device won't accept the tag. The can_queue parameter represents the maximum
number of outstanding commands the mid-layer will ever send. The mid-layer is
happy to re-queue I/O below this limit if it cannot be accepted by the drive.
In fact, that's more or less what queue plugging is about.
The only problem occurs if you return 1 from queuecommand with no other
outstanding I/O for the device.
There should be no reason in 2.5 for a driver to have to implement an internal
queue.
James
>
> Linux is perfectly happy just to have you return 1 in queuecommand if the
> device won't accept the tag. The can_queue parameter represents the maximum
> number of outstanding commands the mid-layer will ever send. The mid-layer is
> happy to re-queue I/O below this limit if it cannot be accepted by the drive.
> In fact, that's more or less what queue plugging is about.
>
> The only problem occurs if you return 1 from queuecommand with no other
> outstanding I/O for the device.
Duh. There had been race conditions in the past which caused all of us
HBA writers to in fact start swalloing things like QFULL and maintaining
internal queues.
>
> There should be no reason in 2.5 for a driver to have to implement an internal
> queue.
That'd be swell.
> Linux is perfectly happy just to have you return 1 in queuecommand if the
> device won't accept the tag. The can_queue parameter represents the
> maximum number of outstanding commands the mid-layer will ever send.
> The mid-layer is happy to re-queue I/O below this limit if it cannot be
> accepted by the drive. In fact, that's more or less what queue plugging
> is about.
>
> The only problem occurs if you return 1 from queuecommand with no other
> outstanding I/O for the device.
>
> There should be no reason in 2.5 for a driver to have to implement an
> internal queue.
Did this really get fixed in 2.5? The internal queuing was completely
broken in 2.4. Some of the known breakages were:
1) Device returns queue full with no outstanding commands from us
(usually occurs in multi-initiator environments).
2) No delay after busy status so devices that will continually
report BUSY if you hammer them with commands never come ready.
3) Queue is restarted as soon as any command completes even if
you really need to throttle down the number of tags supported
by the device.
4) No tag throttling. If tag throttling is in 2.5, does it ever
increment the tag depth to handle devices that report temporary
resource shortages (Atlas II and III do this all the time, other
devices usually do this only in multi-initiator environments).
5) Proper transaction ordering across a queue full. The aic7xxx
driver "requeues" all transactions that have not yet been sent
to the device replacing the transaction that experienced the queue
full back at the head so that ordering is maintained.
No thought was put into any of these issues in 2.4, so I decided not
to even think about trusting the mid-layer for this functionality.
--
Justin
On Fri, Sep 27, 2002 at 03:28:47PM -0600, Justin T. Gibbs wrote:
> > Linux is perfectly happy just to have you return 1 in queuecommand if the
> > device won't accept the tag. The can_queue parameter represents the
> > maximum number of outstanding commands the mid-layer will ever send.
> > The mid-layer is happy to re-queue I/O below this limit if it cannot be
> > accepted by the drive. In fact, that's more or less what queue plugging
> > is about.
> >
> > The only problem occurs if you return 1 from queuecommand with no other
> > outstanding I/O for the device.
> >
> > There should be no reason in 2.5 for a driver to have to implement an
> > internal queue.
>
> Did this really get fixed in 2.5? The internal queuing was completely
> broken in 2.4. Some of the known breakages were:
>
> 1) Device returns queue full with no outstanding commands from us
> (usually occurs in multi-initiator environments).
This may be fixed.
> 2) No delay after busy status so devices that will continually
> report BUSY if you hammer them with commands never come ready.
This is still broken. Plus, it has a limited number of retries before it
simply returns an I/O error, so it basically hammers the device (so it
can't get unbusy) until a set number of retries have completed then it
returns an I/O error, giving all sorts of false I/O errors on devices that
use BUSY status.
> 3) Queue is restarted as soon as any command completes even if
> you really need to throttle down the number of tags supported
> by the device.
>
> 4) No tag throttling. If tag throttling is in 2.5, does it ever
> increment the tag depth to handle devices that report temporary
> resource shortages (Atlas II and III do this all the time, other
> devices usually do this only in multi-initiator environments).
The current 2.5 mid layer is still tag stupid. It has no concept of tag
depth adjustment (although I have a patch here that implements this bit,
it really needs updating to the current kernels).
> 5) Proper transaction ordering across a queue full. The aic7xxx
> driver "requeues" all transactions that have not yet been sent
> to the device replacing the transaction that experienced the queue
> full back at the head so that ordering is maintained.
>
> No thought was put into any of these issues in 2.4, so I decided not
> to even think about trusting the mid-layer for this functionality.
No, you still can't yet, but we hope to have that fixed before the next
stable kernel series.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606