> 
> On Mon, Jun 09, 2025 at 09:32:20AM +0000, wangtao wrote:
> > Are you suggesting adding an ITER_DMABUF type to iov_iter,
> 
> Yes.

May I clarify: Do all disk operations require data to pass through
memory (reading into memory or writing from memory)? In the block layer,
the bio structure uses bio_iov_iter_get_pages to convert iter_type
objects into memory-backed bio_vec representations.
However, some dmabufs are not memory-based, making page-to-bio_vec
conversion impossible. This suggests adding a callback function in
dma_buf_ops to handle dmabuf- to-bio_vec conversion.

Interestingly, if such a callback exists, the need for a dedicated
ITER_DMABUF type might disappear. Would you like to discuss potential
implementation tradeoffs here?

Regards,
Wangtao.

On Fri, Jun 13, 2025 at 09:33:55AM +0000, wangtao wrote:
> 
> > 
> > On Mon, Jun 09, 2025 at 09:32:20AM +0000, wangtao wrote:
> > > Are you suggesting adding an ITER_DMABUF type to iov_iter,
> > 
> > Yes.
> 
> May I clarify: Do all disk operations require data to pass through
> memory (reading into memory or writing from memory)? In the block layer,
> the bio structure uses bio_iov_iter_get_pages to convert iter_type
> objects into memory-backed bio_vec representations.
> However, some dmabufs are not memory-based, making page-to-bio_vec
> conversion impossible. This suggests adding a callback function in
> dma_buf_ops to handle dmabuf- to-bio_vec conversion.

bios do support PCI P2P tranfers.  This could be fairly easily extended
to other peer to peer transfers if we manage to come up with a coherent
model for them.  No need for a callback.