[1506] in linux-scsi channel archive
Re: elevator sorting for the scsi subsystem.
daemon@ATHENA.MIT.EDU (Dario_Ballabio@milano.europe.dg.co)
Mon Mar 3 16:31:07 1997
Date: Mon, 3 Mar 1997 22:14:18 +0100
From: Dario_Ballabio@milano.europe.dg.com
To: linux-scsi@vger.rutgers.edu, groudier@club-internet.fr
%UATTACH
>I wrote, about six months ago, that we should allow low-level driver to
>tune at any time the credit of commands they can accept for a device.
>I'am not sure that's possible with the current scsi code.
>
>Such an improvement, would allow to manage intelligently QUEUE FULL
>status, without having to queue too much commands inside
>low-level drivers.
>
>The same way, such an improvement, would allow low-level drivers to give
>some feedback at any time to the upper drivers in order to try to minimize
>the number of scsi commands that are not actually queued to the
>controller and/or the device when it is possible to control that.
>That's feedback technics, that's simple and that should work great, in
>my opinion.
>
>Gerard.
>
All you wrote is reasonable, you have realized (probably before I did)
that a problem does exist. I would suggest a much simpler solution
to the problem: the upper scsi layer can calculate how many commands
are queued to a specific scsi device and already sent to the driver.
The sd (and why not the sr for cdrom?) should release a new batch of
(elevator sorted) commands only when the queue to the specific device
is below an agreed "low water mark". This requires no modifications
to the existing drivers and it seems to me relatively simple to implement.
BTW the above is basically what I implemented between the EATA low level
driver and the controller and it seem to work pretty well.
I suggest to implement the same idea between sd and the low level drivers.
db
