On 04/03/2026 10:26, Nilay Shroff wrote:
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 think that we can cross that bridge if it ever happens. It should not
be too difficult to allow a driver to specify which policies are
supported/unsupported and the lib can take care of management of that.
Thanks,
John
