Date: Fri, 27 May 2005 09:15:52 +0200
From: Jens Axboe <axboe@suse.de>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Mark Lord <liml@rtr.ca>, linux-ide@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: Playing with SATA NCQ
Message-ID: <20050527071551.GM1435@suse.de>
References: <20050526140058.GR1419@suse.de> <42964498.9080909@rtr.ca> <20050527062802.GH1435@suse.de> <4296C505.2030806@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4296C505.2030806@pobox.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1203
Lines: 31

On Fri, May 27 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/