Re: [PATCH 03/13] libmultipath: Add path selection support

[Nilay Shroff <nilay@linux.ibm.com>]

On 4/14/26 3:33 PM, John Garry wrote:
> Hi Nilay,
> 
>>>
>>> I think so, but we will need scsi to maintain such a count internally to support this policy. And for NVMe we will need some abstraction to lookup the per-controller QD for a mpath_device.
>>>
>> This raises another question regarding the current framework. From what I can see, all NVMe multipath I/O policies are currently supported for SCSI as well. Going forward, if we introduce a new I/O policy for NVMe that does not make sense for SCSI, how can we ensure that the new policy is supported only for NVMe and not for SCSI? Conversely, we may also want to introduce a policy that is relevant only for SCSI but not for NVMe.
>>
>> With the current framework, it seems difficult to restrict a policy to a specific transport. It appears that all policies are implicitly shared between NVMe and SCSI.
>>
>> Would it make sense to introduce some abstraction for I/O policies in the framework so that a given policy can be implemented and exposed only for the relevant transport (e.g., NVMe-only or SCSI-only), rather than requiring it to be supported by both?
> 
> I am just coming back to this now....
> 
> 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@redhat.com/
> 
> Is the idea that some controller may have another NS attached and have traffic there, and we need to account according to this also?
> 
Yes, the idea is that congestion should be evaluated at the controller level rather than per-namespace.
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.

Thanks,
--Nilay