Re: [PATCH v2 5/8] docs: document options for io_uring_cmd I/O engine

[Ankit Kumar <ankit.kumar@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

On Fri, May 27, 2022 at 12:24:03PM +0530, Kanchan Joshi wrote:
> On Thu, May 26, 2022 at 08:18:06PM +0530, Ankit Kumar wrote:
> > .B libaio
> > Linux native asynchronous I/O. Note that Linux may only support
> > queued behavior with non-buffered I/O (set `direct=1' or
> > @@ -2045,6 +2054,15 @@ release them when IO is done. If this option is set, the pages are pre-mapped
> > before IO is started. This eliminates the need to map and release for each IO.
> > This is more efficient, and reduces the IO latency as well.
> > .TP
> > +.BI (io_uring,io_uring_cmd)nonvectored
> > +With this option, fio will use non-vectored read/write commands, where address
> > +must contain the address directly.
> > +.TP
> > +.BI (io_uring,io_uring_cmd)force_async
> > +Normal operation for io_uring is to try and issue an sqe as non-blocking first,
> > +and if that fails, execute it in an async manner. With this option set to N,
> > +then every N request fio will ask sqe to be issued in an async manner.
> > +.TP
> > .BI (io_uring,xnvme)hipri
> 
> io_uring_cmd should be added here? And same for fixedbufs too.
>
Agreed, will be done in v3
> > If this option is set, fio will attempt to use polled IO completions. Normal IO
> > completions generate interrupts to signal the completion of IO, polled
> > @@ -2052,22 +2070,26 @@ completions do not. Hence they are require active reaping by the application.
> > The benefits are more efficient IO for high IOPS scenarios, and lower latencies
> > for low queue depth IO.
> > .TP
> > -.BI (io_uring)registerfiles
> > +.BI (io_uring,io_uring_cmd)registerfiles
> > With this option, fio registers the set of files being used with the kernel.
> > This avoids the overhead of managing file counts in the kernel, making the
> > submission and completion part more lightweight. Required for the below
> > sqthread_poll option.
> > .TP
> > -.BI (io_uring,xnvme)sqthread_poll
> > +.BI (io_uring,io_uring_cmd,xnvme)sqthread_poll
> > Normally fio will submit IO by issuing a system call to notify the kernel of
> > available items in the SQ ring. If this option is set, the act of submitting IO
> > will be done by a polling thread in the kernel. This frees up cycles for fio, at
> > the cost of using more CPU in the system.
> > .TP
> > -.BI (io_uring)sqthread_poll_cpu
> > +.BI (io_uring,io_uring_cmd)sqthread_poll_cpu
> > When `sqthread_poll` is set, this option provides a way to define which CPU
> > should be used for the polling thread.
> > .TP
> > +.BI (io_uring_cmd)cmd_type \fR=\fPstr
> > +Specifies the type of uring passthrough command to be used. Supported
> > +value is nvme.
> 
> Seems that is default value too. So that part needs to be mentioned
> here.
Yes, will add it in v3


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]