On Wed, 15 Feb 2023 at 01:11, Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > On Tue, Feb 14, 2023 at 04:39:01PM +0100, Miklos Szeredi wrote: > > On Tue, 14 Feb 2023 at 15:35, Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > > > > I understand it isn't one issue from block device driver viewpoint at > > > least, since the WRITE to buffer in sink end can be thought as DMA > > > to buffer from device, and it is the upper layer(FS)'s responsibility > > > for updating page flag. And block driver needn't to handle page > > > status update. > > > > The block device still needs to know when the DMA is finished, right? > > Yeah, for normal in-kernel device driver, the completion is triggered by > interrupt or io polling. > > For ublk, io handling is done by userspace, here we use io_uring to > handle the IO in aio style. When the aio is completed, the userspace > gets notified of the completion. I think it might be better if the write completion was directly signaled to the original pipe buffer. There are several advantages: - the kernel can guarantee (modulo bugs) that the buffer was initialized, this is important if the userspace server is unprivileged - the server process does not need to be woken up on I/O completion - there could be a chain of splices involving various entities, yet the original pipe buffer should always get the completion I'm not sure what a good implementation would look like. When a pipe buffer is split, things get complicated. Maybe just disallow splitting on such buffers... Thanks, Miklos
