Re: [PATCH V3 00/16] io_uring/ublk: add IORING_OP_FUSED_CMD

[Ming Lei <ming.lei@redhat.com>]

On Sun, Mar 19, 2023 at 07:42:26AM +0800, Ming Lei wrote:
> On Sat, Mar 18, 2023 at 04:51:14PM +0000, Pavel Begunkov wrote:
> > On 3/18/23 13:35, Ming Lei wrote:
> > > Hi Jens,
> > > 
> > > Thanks for the response!
> > > 
> > > On Sat, Mar 18, 2023 at 06:59:41AM -0600, Jens Axboe wrote:
> > > > On 3/17/23 2:14?AM, Ming Lei wrote:
> > > > > On Tue, Mar 14, 2023 at 08:57:11PM +0800, Ming Lei wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > Add IORING_OP_FUSED_CMD, it is one special URING_CMD, which has to
> > > > > > be SQE128. The 1st SQE(master) is one 64byte URING_CMD, and the 2nd
> > > > > > 64byte SQE(slave) is another normal 64byte OP. For any OP which needs
> > > > > > to support slave OP, io_issue_defs[op].fused_slave needs to be set as 1,
> > > > > > and its ->issue() can retrieve/import buffer from master request's
> > > > > > fused_cmd_kbuf. The slave OP is actually submitted from kernel, part of
> > > > > > this idea is from Xiaoguang's ublk ebpf patchset, but this patchset
> > > > > > submits slave OP just like normal OP issued from userspace, that said,
> > > > > > SQE order is kept, and batching handling is done too.
> > > > > > 
> > > > > > Please see detailed design in commit log of the 2th patch, and one big
> > > > > > point is how to handle buffer ownership.
> > > > > > 
> > > > > > With this way, it is easy to support zero copy for ublk/fuse device.
> > > > > > 
> > > > > > Basically userspace can specify any sub-buffer of the ublk block request
> > > > > > buffer from the fused command just by setting 'offset/len'
> > > > > > in the slave SQE for running slave OP. This way is flexible to implement
> > > > > > io mapping: mirror, stripped, ...
> > > > > > 
> > > > > > The 3th & 4th patches enable fused slave support for the following OPs:
> > > > > > 
> > > > > > 	OP_READ/OP_WRITE
> > > > > > 	OP_SEND/OP_RECV/OP_SEND_ZC
> > > > > > 
> > > > > > The other ublk patches cleans ublk driver and implement fused command
> > > > > > for supporting zero copy.
> > > > > > 
> > > > > > Follows userspace code:
> > > > > > 
> > > > > > https://github.com/ming1/ubdsrv/tree/fused-cmd-zc-v2
> > > > > > 
> > > > > > All three(loop, nbd and qcow2) ublk targets have supported zero copy by passing:
> > > > > > 
> > > > > > 	ublk add -t [loop|nbd|qcow2] -z ....
> > > > > > 
> > > > > > Basic fs mount/kernel building and builtin test are done, and also not
> > > > > > observe regression on xfstest test over ublk-loop with zero copy.
> > > > > > 
> > > > > > Also add liburing test case for covering fused command based on miniublk
> > > > > > of blktest:
> > > > > > 
> > > > > > https://github.com/ming1/liburing/commits/fused_cmd_miniublk
> > > > > > 
> > > > > > Performance improvement is obvious on memory bandwidth
> > > > > > related workloads, such as, 1~2X improvement on 64K/512K BS
> > > > > > IO test on loop with ramfs backing file.
> > > > > > 
> > > > > > Any comments are welcome!
> > > > > > 
> > > > > > V3:
> > > > > > 	- fix build warning reported by kernel test robot
> > > > > > 	- drop patch for checking fused flags on existed drivers with
> > > > > > 	  ->uring_command(), which isn't necessary, since we do not do that
> > > > > >        when adding new ioctl or uring command
> > > > > >      - inline io_init_rq() for core code, so just export io_init_slave_req
> > > > > > 	- return result of failed slave request unconditionally since REQ_F_CQE_SKIP
> > > > > > 	will be cleared
> > > > > > 	- pass xfstest over ublk-loop
> > > > > 
> > > > > Hello Jens and Guys,
> > > > > 
> > > > > I have been working on io_uring zero copy support for ublk/fuse for a while, and
> > > > > I appreciate you may share any thoughts on this patchset or approach?
> > > > 
> > > > I'm a bit split on this one, as I really like (and want) the feature.
> > > > ublk has become popular pretty quickly, and it makes a LOT of sense to
> > > > support zero copy for it. At the same time, I'm not really a huge fan of
> > > > the fused commands... They seem too specialized to be useful for other
> > > > things, and it'd be a shame to do something like that only for it later
> > > > to be replaced by a generic solution. And then we're stuck with
> > > > supporting fused commands forever, not sure I like that prospect.
> > > > 
> > > > Both Pavel and Xiaoguang voiced similar concerns, and I think it may be
> > > > worth spending a bit more time on figuring out if splice can help us
> > > > here. David Howells currently has a lot going on in that area too.
> > > 
> > > IMO, splice(->splice_read()) can help much less in this use case, and
> > > I can't see improvement David Howells has done in this area:
> > 
> > Let me correct a misunderstanding I've seen a couple of times
> > from people. Apart from the general idea of providing buffers, it's
> > not that bound to splice. Yes, I reused splicing guts for that
> > half-made POC, but we can add a new callback that would do it a
> > bit nicer, i.e. better consolidating returned buffers. Would
> 
> ->release() is for releasing pipe-buffer(page), instead of the whole buffer(reference).
> 
> > probably be even better to have both of them falling back to
> > splice so it can cover more cases. The core of it is mediating
> > buffers through io_uring's registered buffer table, which
> > decouples all the components from each other.
> 
> For using pipe buffer's ->release() to release the whole buffer's
> reference, you have to allocate one pipe for each fixed buffer, and add
> pipe buffer to it, and keep each pipe buffer into the pipe
> until it is consumed, since ->release() needs to be called when
> unregistering buffer(all IOs are completed)
> 
> It(allocating/free pipe node, and populating it with each page) is
> really inefficient for handling one single IO.
> 
> So re-using splice for this purpose is still bad not mention splice
> can't support writeable spliced page.
> 
> Wiring device io buffer with context registered buffer table looks like
> another approach, however:
> 
> 1) two uring command OPs for registering/unregistering this buffer in io fast
> path has to be added since only userspace can know when buffer(reference)
> isn't needed
> 
> 2) userspace becomes more complicated, 3+ OPs are required for handling one
> single device IO
> 
> 3) buffer reference crosses multiple OPs, for cleanup the registered buffer,
> we have to store the device file & "buffer key" in each buffer(such as io_uring_bvec_buf)
> for unregistering buffer

Follows another problem or complexity here:

- normal usage when handling one application(ublk/fuse) IO:

	register device io buffer (file, buffer key)
	OP1 consumes the buffer reference and submits IO
	OP2 consumes the buffer reference and submits IO
	...
	unregister device io buffer(file, buffer key) after all above OPs are completed

- for avoiding devil userspace(we are allowed for unprivileged user) to consume
  buffer after buffer is un-registered, each OP has to grab the buffer(reference)'s
  reference or check if the buffer is stale in its io code path; which has to be added
  to current OP code path

- so the decoupling purpose may _not_ be supported actually, also the current
  fixed buffer interface does not support this kind of buffer retrieving via (xarray, (file, key))


thanks,
Ming