Re: [PATCH V4 00/27] ublk: add UBLK_F_BATCH_IO

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

On Fri, Nov 21, 2025 at 09:58:22AM +0800, Ming Lei wrote:
> Hello,
> 
> This patchset adds UBLK_F_BATCH_IO feature for communicating between kernel and ublk
> server in batching way:
> 
> - Per-queue vs Per-I/O: Commands operate on queues rather than individual I/Os
> 
> - Batch processing: Multiple I/Os are handled in single operation
> 
> - Multishot commands: Use io_uring multishot for reducing submission overhead
> 
> - Flexible task assignment: Any task can handle any I/O (no per-I/O daemons)
> 
> - Better load balancing: Tasks can adjust their workload dynamically
> 
> - help for future optimizations:
> 	- blk-mq batch tags free
>   	- support io-poll
> 	- per-task batch for avoiding per-io lock
> 	- fetch command priority
> 
> - simplify command cancel process with per-queue lock
> 
> selftest are provided.
> 
> 
> Performance test result(IOPS) on V3:
> 
> - page copy
> 
> tools/testing/selftests/ublk//kublk add -t null -q 16 [-b]
> 
> - zero copy(--auto_zc)
> tools/testing/selftests/ublk//kublk add -t null -q 16 --auto_zc [-b]
> 
> - IO test
> taskset -c 0-31 fio/t/io_uring -p0 -n $JOBS -r 30 /dev/ublkb0
> 
> 1) 16 jobs IO
> - page copy:  			37.77M vs. 42.40M(BATCH_IO), +12%
> - zero copy(--auto_zc): 42.83M vs. 44.43M(BATCH_IO), +3.7%
> 
> 
> 2) single job IO
> - page copy:  			2.54M vs. 2.6M(BATCH_IO),   +2.3%
> - zero copy(--auto_zc): 3.13M vs. 3.35M(BATCH_IO),  +7%
> 
> 
> V4:
> 	- fix handling in case of running out of mshot buffer, request has to
> 	  be un-prepared for zero copy
> 	- don't expose unused tag to userspace
> 	- replace fixed buffer with plain user buffer for
> 	  UBLK_U_IO_PREP_IO_CMDS and UBLK_U_IO_COMMIT_IO_CMDS
> 	- replace iov iterator with plain copy_from_user() for
> 	  ublk_walk_cmd_buf(), code is simplified with performance improvement
> 	- don't touch sqe->len for UBLK_U_IO_PREP_IO_CMDS and
> 	  UBLK_U_IO_COMMIT_IO_CMDS(Caleb Sander Mateos)
> 	- use READ_ONCE() for access sqe->addr (Caleb Sander Mateos)
> 	- all kinds of patch style fix(Caleb Sander Mateos)
> 	- inline __kfifo_alloc() (Caleb Sander Mateos)

Hi Caleb Sander Mateos and Jens,

Caleb have reviewed patch 1 ~ patch 8, and driver patch 9 ~ patch 18 are not
reviewed yet.

I'd want to hear your idea for how to move on. So far, looks there are
several ways:

1) merge patch 1 ~ patch 6 to v6.19 first, which can be prep patches for BATCH_IO

2) delay the whole patchset to v6.20 cycle

3) merge the whole patchset to v6.19

I am fine with either one, which one do you prefer to?

BTW, V4 pass all builtin function and stress tests, and there is just one small bug
fix not posted yet, which can be a follow-up. The new feature takes standalone
code path, so regression risk is pretty small.


Thanks,
Ming