lkml.org 
[lkml]   [2023]   [Mar]   [27]   [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
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.

Hi Ming,

io_uring and ublk are starting to be more on my radar these days. I
wanted to take a look at this series, but could not get past the
distracting "master"/"slave" terminology in this lead-in paragraph let
alone start looking at patches.

Frankly, the description sounds more like "head"/"tail", or even
"fuse0"/"fuse1" because, for example, who is to say you might not have
larger fused ops in the future and need terminology to address
"fuse{0,1,2,3}"?

Once that's fixed up I can take a look at forwarding on to others that
might be interested in this use case.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n338

Thanks in advance for fixing that up!

\
 
 \ /
  Last update: 2023-03-28 02:37    [W:0.136 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site