mbox series

[PATCHSET,v2,0/3] Add support for multishot reads

Message ID 20230912172458.1646720-1-axboe@kernel.dk (mailing list archive)
Headers show
Series Add support for multishot reads | expand

Message

Jens Axboe Sept. 12, 2023, 5:24 p.m. UTC
Hi,

We support multishot for other request types, generally in the shape of
a flag for the request. Doing a flag based approach with reads isn't
straightforward, as the read/write flags are in the RWF_ space. Instead,
add a separate opcode for this, IORING_OP_READ_MULTISHOT.

This can only be used provided buffers, like other multishot request
types that read/receive data.

It can also only be used for pollable file types, like a tun device or
pipes, for example. File types that are always readable (or seekable),
like regular files, cannot be used with multishot reads.

This is based on the io_uring-futex branch (which, in turn, is based on
the io_uring-waitid branch). No dependencies as such between them,
except the opcode numbering.

Can also be found here:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-mshot-read

and there's a liburing branch with some basic support and some test
cases here:

https://git.kernel.dk/cgit/liburing/log/?h=read-mshot

 include/uapi/linux/io_uring.h |  1 +
 io_uring/opdef.c              | 14 ++++++
 io_uring/opdef.h              |  2 +
 io_uring/rw.c                 | 92 ++++++++++++++++++++++++++++++++---
 io_uring/rw.h                 |  2 +
 5 files changed, 105 insertions(+), 6 deletions(-)

Changes since v1:
- Code reformatting
- Add/expand a few comments

Comments

Gabriel Krisman Bertazi Sept. 12, 2023, 6:39 p.m. UTC | #1
Jens Axboe <axboe@kernel.dk> writes:

> Hi,
>
> We support multishot for other request types, generally in the shape of
> a flag for the request. Doing a flag based approach with reads isn't
> straightforward, as the read/write flags are in the RWF_ space. Instead,
> add a separate opcode for this, IORING_OP_READ_MULTISHOT.
>
> This can only be used provided buffers, like other multishot request
> types that read/receive data.
>
> It can also only be used for pollable file types, like a tun device or
> pipes, for example. File types that are always readable (or seekable),
> like regular files, cannot be used with multishot reads.
>
> This is based on the io_uring-futex branch (which, in turn, is based on
> the io_uring-waitid branch). No dependencies as such between them,
> except the opcode numbering.
>
> Can also be found here:
>
> https://git.kernel.dk/cgit/linux/log/?h=io_uring-mshot-read
>
> and there's a liburing branch with some basic support and some test
> cases here:
>
> https://git.kernel.dk/cgit/liburing/log/?h=read-mshot

Hey Jens,

For the entire series, feel free to take:

Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>
Jens Axboe Sept. 12, 2023, 7:11 p.m. UTC | #2
On 9/12/23 12:39 PM, Gabriel Krisman Bertazi wrote:
> Jens Axboe <axboe@kernel.dk> writes:
> 
>> Hi,
>>
>> We support multishot for other request types, generally in the shape of
>> a flag for the request. Doing a flag based approach with reads isn't
>> straightforward, as the read/write flags are in the RWF_ space. Instead,
>> add a separate opcode for this, IORING_OP_READ_MULTISHOT.
>>
>> This can only be used provided buffers, like other multishot request
>> types that read/receive data.
>>
>> It can also only be used for pollable file types, like a tun device or
>> pipes, for example. File types that are always readable (or seekable),
>> like regular files, cannot be used with multishot reads.
>>
>> This is based on the io_uring-futex branch (which, in turn, is based on
>> the io_uring-waitid branch). No dependencies as such between them,
>> except the opcode numbering.
>>
>> Can also be found here:
>>
>> https://git.kernel.dk/cgit/linux/log/?h=io_uring-mshot-read
>>
>> and there's a liburing branch with some basic support and some test
>> cases here:
>>
>> https://git.kernel.dk/cgit/liburing/log/?h=read-mshot
> 
> Hey Jens,
> 
> For the entire series, feel free to take:
> 
> Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>

Thanks, added!