public inbox for [email protected]
 help / color / mirror / Atom feed
From: Keith Busch <[email protected]>
To: Jens Axboe <[email protected]>
Cc: [email protected], [email protected],
	Hannes Reinecke <[email protected]>
Subject: Re: [PATCH 4/4] nvme: add support for mq_ops->queue_rqs()
Date: Wed, 15 Dec 2021 09:29:47 -0800	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Wed, Dec 15, 2021 at 09:24:21AM -0700, Jens Axboe wrote:
> +static bool nvme_prep_rq_batch(struct nvme_queue *nvmeq, struct request *req)
> +{
> +	/*
> +	 * We should not need to do this, but we're still using this to
> +	 * ensure we can drain requests on a dying queue.
> +	 */
> +	if (unlikely(!test_bit(NVMEQ_ENABLED, &nvmeq->flags)))
> +		return false;

The patch looks good:

Reviewed-by: Keith Busch <[email protected]>

Now a side comment on the above snippet:

I was going to mention in v2 that you shouldn't need to do this for each
request since the queue enabling/disabling only happens while quiesced,
so the state doesn't change once you start a batch. But I realized
multiple hctx's can be in a single batch, so we have to check each of
them instead of just once. :(

I tried to remove this check entirely ("We should not need to do this",
after all), but that's not looking readily possible without just
creating an equivalent check in blk-mq: we can't end a particular
request in failure without draining whatever list it may be linked
within, and we don't know what list it's in when iterating allocated
hctx tags.

Do you happen to have any thoughts on how we could remove this check?
The API I was thinking of is something like "blk_mq_hctx_dead()" in
order to fail pending requests on that hctx without sending them to the
low-level driver so that it wouldn't need these kinds of per-IO checks.

  reply	other threads:[~2021-12-15 17:30 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 16:24 [PATCHSET v3 0/4] Add support for list issue Jens Axboe
2021-12-15 16:24 ` [PATCH 1/4] block: add mq_ops->queue_rqs hook Jens Axboe
2021-12-16  9:01   ` Christoph Hellwig
2021-12-20 20:36   ` Keith Busch
2021-12-20 20:47     ` Jens Axboe
2021-12-15 16:24 ` [PATCH 2/4] nvme: split command copy into a helper Jens Axboe
2021-12-16  9:01   ` Christoph Hellwig
2021-12-16 12:17   ` Max Gurtovoy
2021-12-15 16:24 ` [PATCH 3/4] nvme: separate command prep and issue Jens Axboe
2021-12-16  9:02   ` Christoph Hellwig
2021-12-15 16:24 ` [PATCH 4/4] nvme: add support for mq_ops->queue_rqs() Jens Axboe
2021-12-15 17:29   ` Keith Busch [this message]
2021-12-15 20:27     ` Jens Axboe
2021-12-16  9:08   ` Christoph Hellwig
2021-12-16 13:06     ` Max Gurtovoy
2021-12-16 15:48       ` Jens Axboe
2021-12-16 16:00         ` Max Gurtovoy
2021-12-16 16:05           ` Jens Axboe
2021-12-16 16:19             ` Max Gurtovoy
2021-12-16 16:25               ` Jens Axboe
2021-12-16 16:34                 ` Max Gurtovoy
2021-12-16 16:36                   ` Jens Axboe
2021-12-16 16:57                     ` Max Gurtovoy
2021-12-16 17:16                       ` Jens Axboe
2021-12-19 12:14                         ` Max Gurtovoy
2021-12-19 14:48                           ` Jens Axboe
2021-12-20 10:11                             ` Max Gurtovoy
2021-12-20 14:19                               ` Jens Axboe
2021-12-20 14:25                                 ` Jens Axboe
2021-12-20 15:29                                 ` Max Gurtovoy
2021-12-20 16:34                                   ` Jens Axboe
2021-12-20 18:48                                     ` Max Gurtovoy
2021-12-20 18:58                                       ` Jens Axboe
2021-12-21 10:20                                         ` Max Gurtovoy
2021-12-21 15:23                                           ` Jens Axboe
2021-12-21 15:29                                             ` Max Gurtovoy
2021-12-21 15:33                                               ` Jens Axboe
2021-12-21 16:08                                                 ` Max Gurtovoy
2021-12-16 15:45     ` Jens Axboe
2021-12-16 16:15       ` Christoph Hellwig
2021-12-16 16:27         ` Jens Axboe
2021-12-16 16:30           ` Christoph Hellwig
2021-12-16 16:36             ` Jens Axboe
2021-12-16 13:02   ` Max Gurtovoy
2021-12-16 15:59     ` Jens Axboe
2021-12-16 16:06       ` Max Gurtovoy
2021-12-16 16:09         ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2021-12-16 16:05 [PATCHSET v4 0/4] Add support for list issue Jens Axboe
2021-12-16 16:05 ` [PATCH 4/4] nvme: add support for mq_ops->queue_rqs() Jens Axboe
2021-12-16 16:38 [PATCHSET v5 0/4] Add support for list issue Jens Axboe
2021-12-16 16:39 ` [PATCH 4/4] nvme: add support for mq_ops->queue_rqs() Jens Axboe
2021-12-16 17:53   ` Christoph Hellwig

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=20211215172947.GB4164278@dhcp-10-100-145-180.wdc.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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