From: Christoph Hellwig <hch@infradead.org>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: "Christoph Hellwig" <hch@infradead.org>,
io-uring@vger.kernel.org, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
"Keith Busch" <kbusch@kernel.org>, "David Wei" <dw@davidwei.uk>,
"Vishal Verma" <vishal1.verma@intel.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org
Subject: Re: [RFC 00/12] io_uring dmabuf read/write support
Date: Tue, 8 Jul 2025 02:45:15 -0700 [thread overview]
Message-ID: <aGzoqyM06rgXIJst@infradead.org> (raw)
In-Reply-To: <e210595b-d01f-4405-9b5d-a486ddca49ed@gmail.com>
On Mon, Jul 07, 2025 at 04:41:23PM +0100, Pavel Begunkov wrote:
> > I mean a reference the actual dma_buf (probably indirect through the file
> > * for it, but listen to the dma_buf experts for that and not me).
>
> My expectation is that io_uring would pass struct dma_buf to the
io_uring isn't the only user. We've already had one other use case
coming up for pre-load of media files in mobile very recently. It's
also a really good interface for P2P transfers of any kind.
> file during registration, so that it can do a bunch of work upfront,
> but iterators will carry sth already pre-attached and pre dma mapped,
> probably in a file specific format hiding details for multi-device
> support, and possibly bundled with the dma-buf pointer if necessary.
> (All modulo move notify which I need to look into first).
I'd expect that the exported passed around the dma_buf, and something
that has access to it then imports it to the file. This could be
directly forwarded to the device for the initial scrope in your series
where you only support it for block device files.
Now we have two variants:
1) the file instance returns a cookie for the registration that the
caller has to pass into every read/write
2) the file instance tracks said cookie itself and matches it on
every read/write
1) sounds faster, 2) has more sanity checking and could prevent things
from going wrong.
(all this is based on my limited dma_buf understanding, corrections
always welcome).
> > > But maybe that's fine. It's 40B -> 48B,
> >
> > Alternatively we could the union point to a struct that has the dma buf
> > pointer and a variable length array of dma_segs. Not sure if that would
> > create a mess in the callers, though.
>
> Iteration helpers adjust the pointer, so either it needs to store
> the pointer directly in iter or keep the current index. It could rely
> solely on offsets, but that'll be a mess with nested loops (where the
> inner one would walk some kind of sg table).
Yeah. Maybe just keep is as a separate pointer growing the structure
and see if anyone screams.
prev parent reply other threads:[~2025-07-08 9:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 15:10 [RFC 00/12] io_uring dmabuf read/write support Pavel Begunkov
2025-06-27 15:10 ` [RFC 01/12] file: add callback returning dev for dma operations Pavel Begunkov
2025-06-27 15:10 ` [RFC 02/12] iov_iter: introduce iter type for pre-registered dma Pavel Begunkov
2025-06-27 15:10 ` [RFC 03/12] block: move around bio flagging helpers Pavel Begunkov
2025-06-27 15:10 ` [RFC 04/12] block: introduce dmavec bio type Pavel Begunkov
2025-06-27 15:10 ` [RFC 05/12] block: implement ->get_dma_device callback Pavel Begunkov
2025-06-27 15:10 ` [RFC 06/12] nvme-pci: add support for user passed dma vectors Pavel Begunkov
2025-06-27 15:10 ` [RFC 07/12] io_uring/rsrc: extended reg buffer registration Pavel Begunkov
2025-06-27 15:10 ` [RFC 08/12] io_uring: add basic dmabuf helpers Pavel Begunkov
2025-06-27 15:10 ` [RFC 09/12] io_uring/rsrc: add imu flags Pavel Begunkov
2025-06-27 15:10 ` [RFC 10/12] io_uring/rsrc: add dmabuf-backed buffer registeration Pavel Begunkov
2025-06-27 15:10 ` [RFC 11/12] io_uring/rsrc: implement dmabuf regbuf import Pavel Begunkov
2025-06-27 15:10 ` [RFC 12/12] io_uring/rw: enable dma registered buffers Pavel Begunkov
2025-07-03 14:23 ` [RFC 00/12] io_uring dmabuf read/write support Christoph Hellwig
2025-07-03 14:37 ` Christian König
2025-07-07 11:15 ` Pavel Begunkov
2025-07-07 14:48 ` Christoph Hellwig
2025-07-07 15:41 ` Pavel Begunkov
2025-07-08 9:45 ` Christoph Hellwig [this message]
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=aGzoqyM06rgXIJst@infradead.org \
--to=hch@infradead.org \
--cc=asml.silence@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dw@davidwei.uk \
--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-media@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sumit.semwal@linaro.org \
--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