[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230328051037.GB8405@green5>
Date: Tue, 28 Mar 2023 10:40:37 +0530
From: Kanchan Joshi <joshi.k@...sung.com>
To: Ming Lei <ming.lei@...hat.com>
Cc: Jens Axboe <axboe@...nel.dk>, io-uring@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
Miklos Szeredi <mszeredi@...hat.com>,
ZiyangZhang <ZiyangZhang@...ux.alibaba.com>,
Xiaoguang Wang <xiaoguang.wang@...ux.alibaba.com>,
Bernd Schubert <bschubert@....com>,
Pavel Begunkov <asml.silence@...il.com>,
Stefan Hajnoczi <stefanha@...hat.com>
Subject: Re: [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.
Powered by blists - more mailing lists