Re: [PATCH 03/13] libmultipath: Add path selection support
From: John Garry
Date: Tue Apr 14 2026 - 09:13:16 EST
On 14/04/2026 12:43, Nilay Shroff wrote:
Yes, the idea is that congestion should be evaluated at the controller level rather than per-namespace.
about the queue-depth iopolicy, why is depth per controller and not per NS (path)? The following does not mention:
https://lore.kernel.org/linux-nvme/20240625122605.857462-3- jmeneghi@xxxxxxxxxx/
Is the idea that some controller may have another NS attached and have traffic there, and we need to account according to this also?
In NVMe, multiple namespaces can be attached to the same controller, and all of them share the same
transport path and I/O queue resources (submission and completion queues). As a result, any contention
or congestion is fundamentally observed at the controller, and not at an individual namespace.
If we were to track queue depth per namespace, it could give a misleading view of the actual load on
the underlying path, since multiple namespaces may be contributing to the same set of queues. In contrast,
tracking queue depth per controller provides a more accurate representation of the total outstanding I/O
and the level of congestion on that path.
In a multipath configuration, this allows us to compare controllers directly. For example, if one controller
has a lower queue depth than another, it is likely experiencing less contention and may offer lower latency,
making it a better candidate for forwarding I/O.
ok, thanks for the info. So on this basis I would think that SCSI host would be where we track requests for scsi-multipath. I need to consider it more... Hannes, thoughts?
John