From: Nilay Shroff <nilay@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
kbusch@kernel.org, hare@suse.de, sagi@grimberg.me,
jmeneghi@redhat.com, axboe@kernel.dk, gjoyce@ibm.com
Subject: Re: [RFC PATCH 1/2] nvme-multipath: introduce delayed removal of the multipath head node
Date: Tue, 8 Apr 2025 19:37:48 +0530 [thread overview]
Message-ID: <5db5ab7b-fdf2-4b40-86fc-3ab4ccff9a41@linux.ibm.com> (raw)
In-Reply-To: <20250407144413.GA12216@lst.de>
On 4/7/25 8:14 PM, Christoph Hellwig wrote:
>> @@ -3690,6 +3690,10 @@ static struct nvme_ns_head *nvme_alloc_ns_head(struct nvme_ctrl *ctrl,
>> ratelimit_state_init(&head->rs_nuse, 5 * HZ, 1);
>> ratelimit_set_flags(&head->rs_nuse, RATELIMIT_MSG_ON_RELEASE);
>> kref_init(&head->ref);
>> +#ifdef CONFIG_NVME_MULTIPATH
>> + if (ctrl->ops->flags & NVME_F_FABRICS)
>> + set_bit(NVME_NSHEAD_FABRICS, &head->flags);
>> +#endif
>
> We might want to make the flags unconditional or move this into a helper
> to avoid the ifdef'ery if we keep the flag (see below).
Yes okay, this could be moved into a helper so that we can avoid ifdef'ery.
>
>> - if (last_path)
>> - nvme_mpath_shutdown_disk(ns->head);
>> + nvme_mpath_shutdown_disk(ns->head);
>
> I guess this function is where the shutdown naming came from, and it
> probably was a bad idea even back then..
>
> Maybe throw in an extra patch to rename it as well.
>
Sure will do.
>> + /*
>> + * For non-fabric controllers we support delayed removal of head disk
>> + * node. If we reached up to here then it means that head disk is still
>> + * alive and so we assume here that even if there's no path available
>> + * maybe due to the transient link failure, we could queue up the IO
>> + * and later when path becomes ready we re-submit queued IO.
>> + */
>> + if (!(test_bit(NVME_NSHEAD_FABRICS, &head->flags)))
>> + return true;
>
> Why is this conditional on fabrics or not? The same rationale should
> apply as much if not more for fabrics controllers.
>
For fabrics we already have options like "reconnect_delay" and
"max_reconnects". So in case of fabric link failures, we delay
the removal of the head disk node based on those options.
> Also no need for the set of braces around the test_bit() call.
>
Yeah agreed!
>> }
>>
>> +static void nvme_remove_head(struct nvme_ns_head *head)
>> +{
>> + if (test_and_clear_bit(NVME_NSHEAD_DISK_LIVE, &head->flags)) {
>> + /*
>> + * requeue I/O after NVME_NSHEAD_DISK_LIVE has been cleared
>> + * to allow multipath to fail all I/O.
>> + */
>
> Full sentence are supposed to start with a capitalized word.
>
> (yes, I saw this just move, but it's a good chance to fix it)
>
Yes, I will fix it in the next patch.
Thanks,
--Nilay
next prev parent reply other threads:[~2025-04-08 14:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 6:37 [RFC PATCH 0/2] improve NVMe multipath handling Nilay Shroff
2025-03-21 6:37 ` [RFC PATCH 1/2] nvme-multipath: introduce delayed removal of the multipath head node Nilay Shroff
2025-03-22 1:48 ` Martin K. Petersen
2025-03-22 22:08 ` Nilay Shroff
2025-03-25 15:21 ` John Meneghini
2025-04-07 14:44 ` Christoph Hellwig
2025-04-08 14:07 ` Nilay Shroff [this message]
2025-04-09 10:43 ` Christoph Hellwig
2025-04-18 10:45 ` Nilay Shroff
2025-04-22 7:36 ` Christoph Hellwig
2025-04-22 9:52 ` Nilay Shroff
2025-03-21 6:37 ` [RFC PATCH 2/2] nvme-multipath: remove multipath module param Nilay Shroff
2025-03-25 15:09 ` John Meneghini
2025-04-07 14:45 ` Christoph Hellwig
2025-04-08 14:35 ` Nilay Shroff
2025-04-09 10:45 ` Christoph Hellwig
2025-04-18 14:22 ` Nilay Shroff
2025-04-22 7:36 ` 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=5db5ab7b-fdf2-4b40-86fc-3ab4ccff9a41@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=gjoyce@ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jmeneghi@redhat.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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;
as well as URLs for NNTP newsgroup(s).