> -----Original Message----- > From: Christian König <christian.koe...@amd.com> > Sent: Friday, May 16, 2025 6:29 PM > To: wangtao <tao.wang...@honor.com>; sumit.sem...@linaro.org; > benjamin.gaign...@collabora.com; brian.star...@arm.com; > jstu...@google.com; tjmerc...@google.com > Cc: linux-me...@vger.kernel.org; dri-devel@lists.freedesktop.org; linaro- > mm-...@lists.linaro.org; linux-ker...@vger.kernel.org; > wangbintian(BintianWang) <bintian.w...@honor.com>; yipengxiang > <yipengxi...@honor.com>; liulu <liulu....@honor.com>; hanfeng > <feng....@honor.com> > Subject: Re: [PATCH 2/2] dmabuf/heaps: implement > DMA_BUF_IOCTL_RW_FILE for system_heap > > On 5/16/25 11:49, wangtao wrote: > >>>> Please try using udmabuf with sendfile() as confirmed to be working > >>>> by > >> T.J. > >>> [wangtao] Using buffer IO with dmabuf file read/write requires one > >> memory copy. > >>> Direct IO removes this copy to enable zero-copy. The sendfile system > >>> call reduces memory copies from two (read/write) to one. However, > >>> with udmabuf, sendfile still keeps at least one copy, failing zero-copy. > >> > >> > >> Then please work on fixing this. > > [wangtao] What needs fixing? Does sendfile achieve zero-copy? > > sendfile reduces memory copies (from 2 to 1) for network sockets, but > > still requires one copy and cannot achieve zero copies. > > Well why not? See sendfile() is the designated Linux uAPI for moving data > between two files, maybe splice() is also appropriate. > > The memory file descriptor and your destination file are both a files. So > those > uAPIs apply. [wangtao] I realize our disagreement lies here: You believe sendfile enables zero-copy for regular file → socket/file: sendfile(dst_socket, src_disk) [disk] --DMA--> [page buffer] --DMA--> [NIC] sendfile(dst_disk, src_disk) [disk] --DMA--> [page buffer] --DMA--> [DISK]
But for regular file → memory file (e.g., tmpfs/shmem), a CPU copy is unavoidable: sendfile(dst_memfile, src_disk) [disk] --DMA--> [page buffer] --CPU copy--> [DISK] Without memory-to-memory DMA, this wastes CPU/power — critical for embedded devices. > > Now what you suggest is to add a new IOCTL to do this in a very specific > manner just for the system DMA-buf heap. And as far as I can see that is in > general a complete no-go. > > I mean I understand why you do this. Instead of improving the existing > functionality you're just hacking something together because it is simple for > you. > > It might be possible to implement that generic for DMA-buf heaps if > udmabuf allocation overhead can't be reduced, but that is then just the > second step. [wangtao] On dmabuf: - DMABUF lacks Direct I/O support, hence our proposal. - memfd supports Direct I/O but doesn’t fit our use case. - udmabuf via memfd works but needs systemic changes (low ROI) and has slow allocation. Your objections: 1. Adding an IOCTL? This targets dmabuf specifically, and our fix is simple. sendfile doesn’t resolve it. 2. Accessing sgtable pages in the exporter? As the dmabuf creator, the exporter fully controls sgtable/page data. We can restrict access to cases with no external users. Could you clarify which point you oppose? > > Regards, > Christian.
