Re: [PATCH + RFC] Beginning of some updates to scsi mid layer

Patrick Mansfield
2002-06-19T21:15:32Z

On Tue, Jun 18, 2002 at 08:47:53PM -0400, Doug Ledford wrote:

Doug -

> As mentioned, this adds a new scsi_adjust_queue_depth routine that lets
> the low level driver update the queue depth on a device at any point in
> time. So, when Justin Gibbs' driver allocates a queue depth of 253
> commands on drive X, then finds out that drive X has a hard limit of 64,
> then we aren't continuing to waste 189 commands worth of allocated kernel
> memory that can never be effectively used. Future plans here include
> linking this into the bio queueing so that adjusting the mid layer queue
> depth does the "right thing" in regards to the bio layer (for all I know
> it does already, I haven't gotten into the bio->scsi interface yet).

> Once this stuff is in place, then my next goal is to get the queueing code
> in the mid layer up to useable standards (the goal is to be able to rip
> the buts of the QUEUE_FULL and BUSY handling out of my driver and still
> have the system do the "right thing" instead of my driver having it's own
> complete internal queue mechanism including timers and such like it does
> now).

The Scsi_Cmnd initialization should have its own function (maybe
including allocation), called from scsi_adjust_queue_depth and your
new code.

So do you think the current select_queue_depths should (eventually)
be removed?

Not a comment on your patch, but why isn't the queue depth setting
handled completely in the mid-layer?

The cmd_per_lun and can_queue fields are in Scsi_Host, and the mid-layer
already checks for tagged queueing. I don't see what adavantage there
is to having the low level adapters each set the queue depth in their
own way. Plus, a lot of common (and not so common) code would go away.

And then scsi_adjust_queue_depth() could be called when not in interrupt
context.

-- Patrick Mansfield