[197] in linux-scsi channel archive
Re: SCSI Reset Functions.
daemon@ATHENA.MIT.EDU (Michael Neuffer)
Mon May 22 17:38:28 1995
From: Michael Neuffer <neuffer@goofy.zdv.Uni-Mainz.de>
To: eric@aib.com (Eric Youngdale)
Date: Mon, 22 May 95 23:06:48 GMT-1:00
Cc: lnz@dandelion.com, linux-scsi@vger.rutgers.edu, drew@boulder.openware.com
In-Reply-To: <9505221027.ZM25047@aib.com>; from "Eric Youngdale" at May 22, 95 10:27 am
X-Confirm-Reading-To: neuffer@goofy.zdv.uni-mainz.de
> > Who knows whether the higher level parts of the SCSI Subsystem are able to
> take
> > full advantage of tag queuing, though, as they've never been tuned for it.
> > Once I'm happy with the robustness of the driver, I plan to investigate
> further
> > the pattern of commands the driver is being handed, issues of
> scatter/gather
> > limits, etc. For example, the current strategy of a single cmd_per_lun
> value
> > seems to be a limitation, I would think. A fast disk could reasonably
> have
> > many commands queued whereas ther's not much point in that for a slow
> CD-ROM.
>
> The basic idea that I had was that to take advantage of tagged
> queueing, you merely increase the number of outstanding commands per lun
> that the driver supports. The upper level code just keeps feeding commands
> to the board, and the board itself is responsible for tagging the actual
> commands. For DPT boards this strategy seems to work, since Michael said
> that he had to increase the number of commands per lun to 64 to get optimal
> performance.
Yes, you get optimal perfomance in a one or two drive system with this.
Unfortunately the current command_per_lun concept has severe limitations.
Due to a tendency of the disk driver to flood the lowlevel drivers queue
with commands, you won't see a continous operation of a tape drive if you
are heavily accessing the disk drives and have can_queue==command_per_lun.
However, if you can make sure that the tape driver will find at least 2
free command slots you won't see this stop and go behaviour. The cdrom
driver does not seem to be affected by this.
> You have to be aware of memory usage problems in this case -
> if the board emulates a 1542, you would not want this that high if you had
> more than 16 Mb, for example.
The memory footprint of the eata_dma driver is not that big. With the
current firmware it is ~30k (the upcoming firmware might increase
this to ~150k) for code + data.
> This is sort of what some of the SCSI_RESET_* options are for. For
> example, SCSI_RESET_SUCCESS indicates that all of the outstanding commands
> for the bus have automatically been restarted, so that we do not need to
> do anything. SCSI_RESET_PENDING indicates that the outstanding commands
> have not been restarted, and the mid level code should restart all commands
> that were on the bus. Even then, I think the meaning of the various
> options needs to be spelled out a bit more so that each one has a very
> precise meaning.
>
> For the sake of argument let us say that the interface to the
> reset() function were changed to take an additional parameter which
> would indicate how severe a reset we are asking for.
I think we should leave the choice of weapons to the lowlevel driver
and only give hints what we think might be a good thing to do, since the
lowlevel driver will always have better knowledge of what the controller
is able to do or not to do.
> BUS DEVICE RESET:
> -----------------
> SCSI_RESET_PENDING: Device reset, command not restarted. We expect an
> interrupt to tell us that the reset took place.
> BUS RESET:
> -----------------
> SCSI_RESET_PENDING: Bus reset, command not restarted. We expect an
> interrupt for each outstanding command to tell us that the
> reset took place. Use this option if the host
> adapter
> keeps track of outstanding requests and sends a message
> indicating a reset took place for each one.
> My question is, are there other things that need to be reported, and are the
> above descriptions sufficiently descriptive?
Jup, the descriptions are much better than the ones we have right now.
We just have to keep im mind that we have to react differently after
a bus or device reset if we get a SCSI_RESET_PENDING back from the
device driver.
BTW: I will probably put the 'merged' SCSI patch on tsx-11
/pub/linux/ALPHA/scsi/upcoming or something like that, as soon
as Ted finds the time to set up my ftp account. It would be good
if everyone would orient themselves on that a little with their new
patches. We can save Linus and us a lot of work that way.
Mike
___ () /|/|
\ / || ^ / / (
__|__|__|__ _o..O \ <-- Prehistoric
------------------ \__________(_u___ |> Gopher Server! --------------
\``-'---WW | |>
Michael Neuffer ==---/:::::::| |> ////
neuffer@goofy.zdv.uni-mainz.de|::::::::|.,,|\/_/_/_/-/-' /
__\ _______\ \ :
/ / )__-----'
--------------------------- "---"--------------' -------------------------
