From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Hannes Reinecke <hare@suse.de>,
John Garry <john.g.garry@oracle.com>,
John Garry <john.garry@huawei.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
bvanassche@acm.org, hch@lst.de, ming.lei@redhat.com,
niklas.cassel@wdc.com
Cc: axboe@kernel.dk, jinpu.wang@cloud.ionos.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
linuxarm@huawei.com, john.garry2@mail.dcu.ie
Subject: Re: [PATCH RFC v3 2/7] ata: libata-scsi: Add ata_internal_queuecommand()
Date: Mon, 7 Nov 2022 22:29:11 +0900 [thread overview]
Message-ID: <cfb89169-77e5-b208-62e7-4cf1c660ac7a@opensource.wdc.com> (raw)
In-Reply-To: <75aea0e8-4fa4-593c-0024-3c39ac3882f3@suse.de>
On 11/7/22 19:12, Hannes Reinecke wrote:
> On 11/2/22 12:25, Damien Le Moal wrote:
>> On 11/2/22 20:12, Hannes Reinecke wrote:
>>> On 11/2/22 11:07, Damien Le Moal wrote:
>>>> On 11/2/22 18:52, John Garry wrote:
>>>>> Hi Damien,
>>>>>
>>> [ .. ] >> So we only need to find a way of 're-using' that tag, then we won't have
>>> to set aside a reserved tag and everything would be dandy...
>>
>> I tried that. It is very ugly... Problem is that integration with EH in
>> case a real NCQ error happens when all that read-log-complete dance is
>> happening is hard. And don't get me started with the need to save/restore
>> the scsi command context of the command we are reusing the tag from.
>>
>> And given that the code is changing to use regular submission path for
>> internal commands, right now, we need a reserved tag. Or a way to "borrow"
>> the tag from a request that we need to check. Which means we need some
>> additional api to not always try to allocate a tag.
>>
>>>
>>> Maybe we can stop processing when we receive an error (should be doing
>>> that anyway as otherwise the log might be overwritten), then we should
>>> be having a pretty good chance of getting that tag.
>>
>> Hmmm.... that would be no better than using EH which does stop processing
>> until the internal house keeping is done.
>>
>>> Or, precisely, getting _any_ tag as at least one tag is free at that point.
>>> Hmm?
>>
>> See above. Not free, but usable as far as the device is concerned since we
>> have at least on command we need to check completed at the device level
>> (but not yet completed from scsi/block layer point of view).
>>
> So, having had an entire weekend pondering this issue why don't we
> allocate an _additional_ set of requests?
> After all, we had been very generous with allocating queues and requests
> (what with us doing a full provisioning of the requests for all queues
> already for the non-shared tag case).
>
> Idea would be to keep the single tag bitmap, but add eg a new rq state
> MQ_RQ_ERROR. Once that flag is set we'll fetch the error request instead
> of the normal one:
>
> @@ -761,6 +763,8 @@ static inline struct request
> *blk_mq_tag_to_rq(struct blk_mq_tags *tags,
> {
> if (tag < tags->nr_tags) {
> prefetch(tags->rqs[tag]);
> + if (unlikely(blk_mq_request_error(tags->rqs[tag])))
> + return tags->error_rqs[tag];
> return tags->rqs[tag];
> }
>
> and, of course, we would need to provision the error request first.
>
> Rationale here is that this will be primarily for devices with a low
> number of tags, so doubling the number of request isn't much of an
> overhead (as we'll be doing it essentially anyway in the error case as
> we'll have to save the original request _somewhere_), and that it would
> remove quite some cruft from the subsystem; look at SCSI EH trying to
> store the original request contents and then after EH restoring them again.
Interesting idea. I like it. It is essentially a set of reserved requests
without reserved tags: the tag to use for these requests would be provided
"manually" by the user. Right ?
That should allow simplifying any processing that needs to reuse a tag,
and currently its request. That is, CDL, but also usb-scsi, scsi EH and
the few scsi LLDs using scsi_eh_prep_cmnd()+scsi_eh_restore_cmnd().
Ideally, these 2 functions could go away too.
>
> Hmm?
>
> Cheers,
>
> Hannes
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2022-11-07 13:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 10:32 [PATCH RFC v3 0/7] blk-mq/libata/scsi: SCSI driver tagging improvements Part II John Garry
2022-10-25 10:32 ` [PATCH RFC v3 1/7] ata: libata-scsi: Add ata_scsi_queue_internal() John Garry
2022-10-27 1:42 ` Damien Le Moal
2022-10-27 10:45 ` John Garry
2022-10-27 22:24 ` Damien Le Moal
2022-10-25 10:32 ` [PATCH RFC v3 2/7] ata: libata-scsi: Add ata_internal_queuecommand() John Garry
2022-10-27 1:45 ` Damien Le Moal
2022-10-27 9:56 ` John Garry
2022-10-27 13:02 ` Hannes Reinecke
2022-10-27 17:23 ` John Garry
2022-10-27 22:35 ` Damien Le Moal
2022-10-28 8:14 ` John Garry
2022-10-28 8:26 ` Damien Le Moal
2022-10-27 22:25 ` Damien Le Moal
2022-10-28 8:01 ` John Garry
2022-10-28 8:07 ` Damien Le Moal
2022-10-28 8:33 ` John Garry
2022-10-31 5:59 ` Damien Le Moal
2022-11-02 9:52 ` John Garry
2022-11-02 10:07 ` Damien Le Moal
2022-11-02 11:12 ` Hannes Reinecke
2022-11-02 11:25 ` Damien Le Moal
2022-11-07 10:12 ` Hannes Reinecke
2022-11-07 13:29 ` Damien Le Moal [this message]
2022-11-07 14:34 ` Hannes Reinecke
2022-10-25 10:32 ` [PATCH RFC v3 3/7] ata: libata: Make space for ATA queue command in scmd payload John Garry
2022-10-25 10:32 ` [PATCH RFC v3 4/7] ata: libata: Add ata_internal_timeout() John Garry
2022-10-25 10:32 ` [PATCH RFC v3 5/7] ata: libata: Queue ATA internal commands as requests John Garry
2022-10-25 10:32 ` [PATCH RFC v3 6/7] scsi: mvsas: Remove internal tag handling John Garry
2022-10-25 10:32 ` [PATCH RFC v3 7/7] scsi: hisi_sas: Remove internal tag handling for reserved commands John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cfb89169-77e5-b208-62e7-4cf1c660ac7a@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=john.g.garry@oracle.com \
--cc=john.garry2@mail.dcu.ie \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=niklas.cassel@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox