public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	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 11:12:52 +0100	[thread overview]
Message-ID: <75aea0e8-4fa4-593c-0024-3c39ac3882f3@suse.de> (raw)
In-Reply-To: <0de1c3fd-4be7-1690-0780-720505c3692b@opensource.wdc.com>

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.

Hmm?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer


  reply	other threads:[~2022-11-07 10:12 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 [this message]
2022-11-07 13:29                           ` Damien Le Moal
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=75aea0e8-4fa4-593c-0024-3c39ac3882f3@suse.de \
    --to=hare@suse.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --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