Re: [PATCH] fix 2.5 scsi queue depth setting

J.E.J. Bottomley
2002-11-06T21:19:19Z

dledford@redhat.com said:
> Actually, I've been planning a slight API change to the slave_attach()
> lldd stuff. Basically, if a host implements slave_attach(), then it
> *must* call adjust_queue_depth() on all devices passed to it, whether
> they are going to use tagged queueing or not.

I agree.

dledford@redhat.com said:
> I would rather we did this:
> if(host->hostt->slave_attach)
> blah; else
> scsi_adjust_queue_depth(sdev, 0, cmd_per_lun);

I agree. (That's what patrick just put in the patch for me).

> I want to make the queuecommand() interface optional, with the ability
> to replace it with a combo of prepare_command() and send_command()
> instead. A driver can only define queuecommand() or the
> prepare,send_command() pair. The obvious benefit is that a prepare
> then send routine is needed to make sequential untagged commands fast
> without having to implement a driver internal queue, and this is
> necessary for streaming devices that can't tolerate long delays
> between commands without falling out of their current stream (tapes,
> early CD-Rs and current very cheap CD-Rs, etc). Obviously, this new
> interface would require that driver authors actually think about
> things like sendable commands vs. just prepped commands, etc. Making
> them always call adjust queue depth is one way of forcing them to
> think about these issues, hence why I like requiring it in all
> slave_attach calls. Thoughts?

Quite like the idea. It should be possible to make it complement the
request_prep_fn I'm doing for SCSI (this will force the upper level drivers to
do early prepares on commands, so we can have the whole thing just waiting to
shoot off as the completed command returns).

James