Thread (68 messages) 68 messages, 8 authors, 2005-05-31

Re: Playing with SATA NCQ

From: Jens Axboe <hidden>
Date: 2005-05-27 07:18:12
Also in: lkml

On Fri, May 27 2005, Jeff Garzik wrote:
Jens Axboe wrote:
quoted
Yeah, I'm not a huge fan of the need for the above code... If every qc
was tied to a SCSI command, we could just ask for a later requeue of the
request as is currently done with NCQ commands. Alternatively, we could
add an internal libata qc queue for postponing these commands. That
would take a little effort, as the sync errors reported by
ata_qc_issue() would then be need to signalled async through the
completion callback instead.

Jeff, what do you think?
Just use the SCSI layer for requeueing.  That's what I intended.
Yep, that is what I'm doing for SCSI originated commands.
Every qc that matters can be requeued.  Just don't worry about
non-queued, non-fast-path commands.  They are typically used in
functions that will immediately notice a failure, and handle it
accordingly.
So the current wait-around stuff is ok with you?

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help