On Mon, Mar 14, 2022 at 3:23 AM Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
>
>
> > +int nvme_ns_head_chr_async_cmd(struct io_uring_cmd *ioucmd)
> > +{
> > + struct cdev *cdev = file_inode(ioucmd->file)->i_cdev;
> > + struct nvme_ns_head *head = container_of(cdev, struct nvme_ns_head, cdev);
> > + int srcu_idx = srcu_read_lock(&head->srcu);
> > + struct nvme_ns *ns = nvme_find_path(head);
> > + int ret = -EWOULDBLOCK;
> > +
> > + if (ns)
> > + ret = nvme_ns_async_ioctl(ns, ioucmd);
> > + srcu_read_unlock(&head->srcu, srcu_idx);
> > + return ret;
> > +}
>
> No one cares that this has no multipathing capabilities what-so-ever?
> despite being issued on the mpath device node?
>
> I know we are not doing multipathing for userspace today, but this
> feels like an alternative I/O interface for nvme, seems a bit cripled
> with zero multipathing capabilities...
Multipathing is on the radar. Either in the first cut or in
subsequent. Thanks for bringing this up.
So the char-node (/dev/ngX) will be exposed to the host if we enable
controller passthru on the target side. And then the host can send
commands using uring-passthru in the same way.
May I know what are the other requirements here.
Bit of a shame that I missed adding that in the LSF proposal, but it's
correctible.
--
Kanchan
