lkml.org 
[lkml]   [2023]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V4 00/17] io_uring/ublk: add IORING_OP_FUSED_CMD
On Fri, Mar 24, 2023 at 09:57:51PM +0800, Ming Lei wrote:
>Hello Jens,
>
>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.

Wondering if this new OP can also be used to do larger IO (than
device limit) on nvme-passthrough?
For example, 1MB IO on NVMe than has 512k or 256K maximum transfer
size.
\
 
 \ /
  Last update: 2023-03-28 07:12    [W:0.200 / U:22.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site