From: "Christian König" <christian.koenig@amd.com>
To: Pavel Begunkov <asml.silence@gmail.com>,
linux-block@vger.kernel.org, io-uring@vger.kernel.org
Cc: Vishal Verma <vishal1.verma@intel.com>,
tushar.gohad@intel.com, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [RFC v2 00/11] Add dmabuf read/write via io_uring
Date: Mon, 24 Nov 2025 11:33:03 +0100 [thread overview]
Message-ID: <fd10fe48-f278-4ed0-b96b-c4f5a91b7f95@amd.com> (raw)
In-Reply-To: <cover.1763725387.git.asml.silence@gmail.com>
On 11/23/25 23:51, Pavel Begunkov wrote:
> Picking up the work on supporting dmabuf in the read/write path.
IIRC that work was completely stopped because it violated core dma_fence and DMA-buf rules and after some private discussion was considered not doable in general.
Or am I mixing something up here? Since I don't see any dma_fence implementation at all that might actually be the case.
On the other hand we have direct I/O from DMA-buf working for quite a while, just not upstream and without io_uring support.
Regards,
Christian.
> There
> are two main changes. First, it doesn't pass a dma addresss directly by
> rather wraps it into an opaque structure, which is extended and
> understood by the target driver.
>
> The second big change is support for dynamic attachments, which added a
> good part of complexity (see Patch 5). I kept the main machinery in nvme
> at first, but move_notify can ask to kill the dma mapping asynchronously,
> and any new IO would need to wait during submission, thus it was moved
> to blk-mq. That also introduced an extra callback layer b/w driver and
> blk-mq.
>
> There are some rough corners, and I'm not perfectly happy about the
> complexity and layering. For v3 I'll try to move the waiting up in the
> stack to io_uring wrapped into library helpers.
>
> For now, I'm interested what is the best way to test move_notify? And
> how dma_resv_reserve_fences() errors should be handled in move_notify?
>
> The uapi didn't change, after registration it looks like a normal
> io_uring registered buffer and can be used as such. Only non-vectored
> fixed reads/writes are allowed. Pseudo code:
>
> // registration
> reg_buf_idx = 0;
> io_uring_update_buffer(ring, reg_buf_idx, { dma_buf_fd, file_fd });
>
> // request creation
> io_uring_prep_read_fixed(sqe, file_fd, buffer_offset,
> buffer_size, file_offset, reg_buf_idx);
>
> And as previously, a good bunch of code was taken from Keith's series [1].
>
> liburing based example:
>
> git: https://github.com/isilence/liburing.git dmabuf-rw
> link: https://github.com/isilence/liburing/tree/dmabuf-rw
>
> [1] https://lore.kernel.org/io-uring/20220805162444.3985535-1-kbusch@fb.com/
>
> Pavel Begunkov (11):
> file: add callback for pre-mapping dmabuf
> iov_iter: introduce iter type for pre-registered dma
> block: move around bio flagging helpers
> block: introduce dma token backed bio type
> block: add infra to handle dmabuf tokens
> nvme-pci: add support for dmabuf reggistration
> nvme-pci: implement dma_token backed requests
> io_uring/rsrc: add imu flags
> io_uring/rsrc: extended reg buffer registration
> io_uring/rsrc: add dmabuf-backed buffer registeration
> io_uring/rsrc: implement dmabuf regbuf import
>
> block/Makefile | 1 +
> block/bdev.c | 14 ++
> block/bio.c | 21 +++
> block/blk-merge.c | 23 +++
> block/blk-mq-dma-token.c | 236 +++++++++++++++++++++++++++++++
> block/blk-mq.c | 20 +++
> block/blk.h | 3 +-
> block/fops.c | 3 +
> drivers/nvme/host/pci.c | 217 ++++++++++++++++++++++++++++
> include/linux/bio.h | 49 ++++---
> include/linux/blk-mq-dma-token.h | 60 ++++++++
> include/linux/blk-mq.h | 21 +++
> include/linux/blk_types.h | 8 +-
> include/linux/blkdev.h | 3 +
> include/linux/dma_token.h | 35 +++++
> include/linux/fs.h | 4 +
> include/linux/uio.h | 10 ++
> include/uapi/linux/io_uring.h | 13 +-
> io_uring/rsrc.c | 201 +++++++++++++++++++++++---
> io_uring/rsrc.h | 23 ++-
> io_uring/rw.c | 7 +-
> lib/iov_iter.c | 30 +++-
> 22 files changed, 948 insertions(+), 54 deletions(-)
> create mode 100644 block/blk-mq-dma-token.c
> create mode 100644 include/linux/blk-mq-dma-token.h
> create mode 100644 include/linux/dma_token.h
>
next prev parent reply other threads:[~2025-11-24 10:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-23 22:51 [RFC v2 00/11] Add dmabuf read/write via io_uring Pavel Begunkov
2025-11-23 22:51 ` [RFC v2 01/11] file: add callback for pre-mapping dmabuf Pavel Begunkov
2025-12-04 10:42 ` Christoph Hellwig
2025-12-12 1:02 ` Pavel Begunkov
2025-12-04 10:46 ` Christian König
2025-12-04 11:07 ` Christoph Hellwig
2025-12-04 11:09 ` Christian König
2025-12-04 13:10 ` Christoph Hellwig
2025-11-23 22:51 ` [RFC v2 02/11] iov_iter: introduce iter type for pre-registered dma Pavel Begunkov
2025-12-04 10:43 ` Christoph Hellwig
2025-12-12 1:06 ` Pavel Begunkov
2025-11-23 22:51 ` [RFC v2 03/11] block: move around bio flagging helpers Pavel Begunkov
2025-12-04 10:43 ` Christoph Hellwig
2025-12-12 1:08 ` Pavel Begunkov
2025-12-12 20:10 ` Jens Axboe
2025-11-23 22:51 ` [RFC v2 04/11] block: introduce dma token backed bio type Pavel Begunkov
2025-12-04 10:48 ` Christoph Hellwig
2025-11-23 22:51 ` [RFC v2 05/11] block: add infra to handle dmabuf tokens Pavel Begunkov
2025-11-24 13:38 ` Anuj gupta
2025-12-04 10:56 ` Christoph Hellwig
2025-12-12 1:56 ` Pavel Begunkov
2025-12-04 13:08 ` Christoph Hellwig
2025-11-23 22:51 ` [RFC v2 06/11] nvme-pci: add support for dmabuf reggistration Pavel Begunkov
2025-11-24 13:40 ` Anuj gupta
2025-12-04 11:00 ` Christoph Hellwig
2025-12-04 19:07 ` Keith Busch
2025-11-23 22:51 ` [RFC v2 07/11] nvme-pci: implement dma_token backed requests Pavel Begunkov
2025-12-04 11:04 ` Christoph Hellwig
2025-11-23 22:51 ` [RFC v2 08/11] io_uring/rsrc: add imu flags Pavel Begunkov
2025-11-23 22:51 ` [RFC v2 09/11] io_uring/rsrc: extended reg buffer registration Pavel Begunkov
2025-11-23 22:51 ` [RFC v2 10/11] io_uring/rsrc: add dmabuf-backed buffer registeration Pavel Begunkov
2025-11-23 22:51 ` [RFC v2 11/11] io_uring/rsrc: implement dmabuf regbuf import Pavel Begunkov
2025-11-24 10:33 ` Christian König [this message]
2025-11-24 11:30 ` [RFC v2 00/11] Add dmabuf read/write via io_uring Pavel Begunkov
2025-11-24 14:17 ` Christian König
2025-11-25 13:52 ` Pavel Begunkov
2025-11-25 14:21 ` Christian König
2025-11-25 19:40 ` Pavel Begunkov
2025-11-24 13:35 ` Anuj gupta
2025-11-25 12:35 ` Pavel Begunkov
2025-12-12 19:37 ` (subset) " Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd10fe48-f278-4ed0-b96b-c4f5a91b7f95@amd.com \
--to=christian.koenig@amd.com \
--cc=akpm@linux-foundation.org \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=io-uring@vger.kernel.org \
--cc=kbusch@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=sumit.semwal@linaro.org \
--cc=tushar.gohad@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vishal1.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).