Re: [PATCH v3 00/10] Add dmabuf read/write via io_uring

[Pavel Begunkov]

On 5/7/26 10:50, Ming Lei wrote:
...
> > > BTW, inspired by this approach, I adds similar feature to ublk via UBLK_IO_F_SHMEM_ZC
> > > which can maintain long-term vfio dma mapping over registered user-place aligned buffer.
> >
> > Interesting, just too a glance, and it looks like what David Wei
> > was thinking to add to fuse, but IIUC he gave up exactly because the
> > client will need to cooperate and that could be troublesome.
>
> Here the cooperation is minimized, maybe one shmem/hugetlb path, or memfd,
> and it is one optimization and opt-in, and fallback to normal path
> if application doesn't cooperate.

My point is that with widely enough adopted interface the user will be
able to opportunistically use it without knowledge about the file, i.e.
not knowing whether it's ublk or something else. But as you mentioned
below, it'd be cooperative interface in either case.
> > Should we try to push everything under the same interface instead of
> > keeping a ublk specific one? Again to the point that it requires
>
> If generic interface can be figured out, it shouldn't be a big deal for
> ublk to switch to it, and the usage is simple actually.

Sure, you'd just need to maintain both as there is a mismatch between
interfaces.

> So far, ublk supports both FS and nvme block device.
>
> And cooperation can't be avoided for this usage no matter if generic or
> driver specific implementation is taken, for both fuse & ublk.
--
Pavel Begunkov