Hmm, I'm a little confused on what this is trying to archive. The io_uring passthrough already does support multipathing, it picks an available path in nvme_ns_head_chr_uring_cmd and uses that. What this does is adding support for requeing on failure or the lack of an available path. Which very strongly is against our passthrough philosophy both in SCSI and NVMe where error handling is left entirely to the userspace program issuing the I/O. So this does radically change behavior in a very unexpected way. Why?
I think the difference from scsi-generic and controller nvme passthru is that this is a mpath device node (or mpath chardev). This is why I think that users would expect that it would have equivalent multipath capabilities (i.e. failover). In general, I think that uring passthru as an alternative I/O interface and as such needs to be able to failover. If this is not expected from the interface, then why are we exposing a chardev for the mpath device node? why not only the bottom namespaces? I can't really imagine a user that would use uring passthru and when it gets an error completion, would then try to reconcile if there is an available path (from sysfs?), and submitting it again in hope that an available path is selected by the driver (without really being able to control any of this)... Maybe I'm wrong, but it looks like an awkward interface to operate on a multipath device node, but implement failover yourself, based on some information that is not necessarily in-sync with the driver.
