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

[John Garry <john.g.garry@oracle.com>]

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?

Thanks,
John