From: Nilay Shroff <nilay@linux.ibm.com>
To: Daniel Wagner <dwagner@suse.de>
Cc: Hannes Reinecke <hare@suse.de>, Keith Busch <kbusch@kernel.org>,
hch@lst.de, gjoyce@linux.ibm.com, "axboe@fb.com" <axboe@fb.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCHv5 RFC 0/3] Add visibility for native NVMe multipath using sysfs
Date: Wed, 11 Dec 2024 14:59:55 +0530 [thread overview]
Message-ID: <4b1cea16-675d-4167-9ccd-f5dd4ec7045a@linux.ibm.com> (raw)
In-Reply-To: <699ab169-daed-4c83-9ae9-65f6542ba9e6@flourine.local>
On 12/10/24 15:04, Daniel Wagner wrote:
> On Tue, Dec 10, 2024 at 12:33:45PM +0530, Nilay Shroff wrote:
>>>>> As we know, NVMe native multipath supports three different io policies
>>>>> (numa, round-robin and queue-depth) for selecting I/O path, however, we
>>>>> don't have any visibility about which path is being selected by multipath
>>>>> code for forwarding I/O. This RFC helps add that visibility by adding new
>>>>> sysfs attribute files named "numa_nodes" and "queue_depth" under each
>>>>> namespace block device path /sys/block/nvmeXcYnZ/. We also create a
>>>>> "multipath" sysfs directory under head disk node and then from this
>>>>> directory add a link to each namespace path device this head disk node
>>>>> points to.
>>>>>
>>>>> Please find below output generated with this proposed RFC patch applied on
>>>>> a system with two multi-controller PCIe NVMe disks attached to it. This
>>>>> system is also an NVMf-TCP host which is connected to an NVMf-TCP target
>>>>> over two NIC cards. This system has four numa nodes online when the below
>>>>> output was captured:
>
> Looks good to me from libnvme's perspective. I just my question on the
> lifetime of the new link, but I might just miss the point.
>
When a namepsace path device is removed, we also remove the corresponding
link (if it exists) from the head disk node to the path device.Please refer
below function, from the first patch of the series, which is invoked from
the nvme_ns_remove() for removing the sysfs link:
void nvme_mpath_remove_sysfs_link(struct nvme_ns *ns)
{
struct device *target;
struct kobject *kobj;
if (!test_bit(NVME_NS_SYSFS_ATTR_LINK, &ns->flags))
return;
target = disk_to_dev(ns->disk);
kobj = &disk_to_dev(ns->head->disk)->kobj;
sysfs_remove_link_from_group(kobj, nvme_ns_mpath_attr_group.name,
dev_name(target));
clear_bit(NVME_NS_SYSFS_ATTR_LINK, &ns->flags);
}
Thanks,
--Nilay
prev parent reply other threads:[~2024-12-11 9:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 10:41 [PATCHv5 RFC 0/3] Add visibility for native NVMe multipath using sysfs Nilay Shroff
2024-10-30 10:41 ` [PATCHv5 RFC 1/3] nvme-multipah: Add visibility for round-robin io-policy Nilay Shroff
2024-12-10 9:22 ` Daniel Wagner
2024-12-10 13:02 ` Nilay Shroff
2024-12-10 15:18 ` Hannes Reinecke
2024-10-30 10:41 ` [PATCHv5 RFC 2/3] nvme-multipath: Add visibility for numa io-policy Nilay Shroff
2024-10-30 10:41 ` [PATCHv5 RFC 3/3] nvme-multipath: Add visibility for queue-depth io-policy Nilay Shroff
2024-11-12 4:37 ` [PATCHv5 RFC 0/3] Add visibility for native NVMe multipath using sysfs Nilay Shroff
2024-11-29 12:19 ` Nilay Shroff
2024-12-10 7:03 ` Nilay Shroff
2024-12-10 9:34 ` Daniel Wagner
2024-12-11 9:29 ` Nilay Shroff [this message]
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=4b1cea16-675d-4167-9ccd-f5dd4ec7045a@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@fb.com \
--cc=dwagner@suse.de \
--cc=gjoyce@linux.ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@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