[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220620090543.GA13643@lst.de>
Date: Mon, 20 Jun 2022 11:05:43 +0200
From: Christoph Hellwig <hch@....de>
To: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
Cc: Hannes Reinecke <hare@...e.de>, John Garry <john.garry@...wei.com>,
Bart Van Assche <bvanassche@....org>, axboe@...nel.dk,
jejb@...ux.ibm.com, martin.petersen@...cle.com, brking@...ibm.com,
hch@....de, linux-block@...r.kernel.org, linux-ide@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
chenxiang66@...ilicon.com
Subject: Re: [PATCH RFC v2 03/18] scsi: core: Implement reserved command
handling
On Mon, Jun 20, 2022 at 06:02:30PM +0900, Damien Le Moal wrote:
> So reserving a tag/req to be able to do NCQ at the cost of max qd being 31
> works for that. We could keep max qd at 32 by creating one more "fake" tag
> and having a request for it, that is, having the fake tag visible to the
> block layer as a reserved tag, as John's series is doing, but for the
> reserved tags, we actually need to use an effective tag (qc->hw_tag) when
> issuing the commands. And for that, we can reuse the tag of one of the
> failed commands.
Take a look at the magic flush request in blk-flush.c, which is
preallocated but borrows a tag from the request that wants a pre- or
post-flush. The logic is rather ugly, but maybe it might actually
become cleaner by generalizing it a bit.
Powered by blists - more mailing lists