On Mon, Jul 07, 2025 at 12:15:54PM +0100, Pavel Begunkov wrote:
> > to attach to / detach from a dma_buf, and then have an iter that
> > specifies a dmabuf and offsets into. That way the code behind the
> > file operations can forward the attachment to all the needed
> > devices (including more/less while it remains attached to the file)
> > and can pick the right dma address for each device.
>
> By "iter that specifies a dmabuf" do you mean an opaque file-specific
> structure allocated inside the new fop?
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).
> Akin to what Keith proposed back
> then. That sounds good and has more potential for various optimisations.
> My concern would be growing struct iov_iter by an extra pointer:
> struct iov_iter {
> union {
> struct iovec *iov;
> struct dma_seg *dmav;
> ...
> };
> void *dma_token;
> };
>
> 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.
> and it'll get back to
> 40 when / if xarray_start / ITER_XARRAY is removed.
Would it? At least for 64-bit architectures nr_segs is the same size.
