public inbox for [email protected]
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH 3/3] io_uring/rw: add support for IORING_OP_READ_MULTISHOT
Date: Mon, 11 Sep 2023 20:38:38 -0400	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]> (Jens Axboe's message of "Mon, 11 Sep 2023 14:40:21 -0600")

Jens Axboe <[email protected]> writes:

> This behaves like IORING_OP_READ, except:
>
> 1) It only supports pollable files (eg pipes, sockets, etc). Note that
>    for sockets, you probably want to use recv/recvmsg with multishot
>    instead.
>
> 2) It supports multishot mode, meaning it will repeatedly trigger a
>    read and fill a buffer when data is available. This allows similar
>    use to recv/recvmsg but on non-sockets, where a single request will
>    repeatedly post a CQE whenever data is read from it.
>
> 3) Because of #2, it must be used with provided buffers. This is
>    uniformly true across any request type that supports multishot and
>    transfers data, with the reason being that it's obviously not
>    possible to pass in a single buffer for the data, as multiple reads
>    may very well trigger before an application has a chance to process
>    previous CQEs and the data passed from them.
>
> Signed-off-by: Jens Axboe <[email protected]>
> ---
>  include/uapi/linux/io_uring.h |  1 +
>  io_uring/opdef.c              | 13 +++++++
>  io_uring/rw.c                 | 66 +++++++++++++++++++++++++++++++++++
>  io_uring/rw.h                 |  2 ++
>  4 files changed, 82 insertions(+)
>
> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> index daa363d1a502..c35438af679a 100644
> --- a/include/uapi/linux/io_uring.h
> +++ b/include/uapi/linux/io_uring.h
> @@ -246,6 +246,7 @@ enum io_uring_op {
>  	IORING_OP_FUTEX_WAIT,
>  	IORING_OP_FUTEX_WAKE,
>  	IORING_OP_FUTEX_WAITV,
> +	IORING_OP_READ_MULTISHOT,
>  
>  	/* this goes last, obviously */
>  	IORING_OP_LAST,
> diff --git a/io_uring/opdef.c b/io_uring/opdef.c
> index bfb7c53389c0..03e1a6f26fa5 100644
> --- a/io_uring/opdef.c
> +++ b/io_uring/opdef.c
> @@ -460,6 +460,16 @@ const struct io_issue_def io_issue_defs[] = {
>  		.prep			= io_eopnotsupp_prep,
>  #endif
>  	},
> +	[IORING_OP_READ_MULTISHOT] = {
> +		.needs_file		= 1,
> +		.unbound_nonreg_file	= 1,
> +		.pollin			= 1,
> +		.buffer_select		= 1,
> +		.audit_skip		= 1,
> +		.ioprio			= 1,
> +		.prep			= io_read_mshot_prep,
> +		.issue			= io_read_mshot,
> +	},
>  };
>  
>  const struct io_cold_def io_cold_defs[] = {
> @@ -692,6 +702,9 @@ const struct io_cold_def io_cold_defs[] = {
>  	[IORING_OP_FUTEX_WAITV] = {
>  		.name			= "FUTEX_WAITV",
>  	},
> +	[IORING_OP_READ_MULTISHOT] = {
> +		.name			= "READ_MULTISHOT",
> +	},
>  };
>  
>  const char *io_uring_get_opcode(u8 opcode)
> diff --git a/io_uring/rw.c b/io_uring/rw.c
> index c3bf38419230..7305792fbbbf 100644
> --- a/io_uring/rw.c
> +++ b/io_uring/rw.c
> @@ -123,6 +123,22 @@ int io_prep_rw(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>  	return 0;
>  }
>  
> +/*
> + * Multishot read is prepared just like a normal read/write request, only
> + * difference is that we set the MULTISHOT flag.
> + */
> +int io_read_mshot_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
> +{
> +	int ret;
> +
> +	ret = io_prep_rw(req, sqe);
> +	if (unlikely(ret))
> +		return ret;
> +
> +	req->flags |= REQ_F_APOLL_MULTISHOT;
> +	return 0;
> +}
> +
>  void io_readv_writev_cleanup(struct io_kiocb *req)
>  {
>  	struct io_async_rw *io = req->async_data;
> @@ -869,6 +885,56 @@ int io_read(struct io_kiocb *req, unsigned int issue_flags)
>  	return kiocb_done(req, ret, issue_flags);
>  }
>  
> +int io_read_mshot(struct io_kiocb *req, unsigned int issue_flags)
> +{
> +	unsigned int cflags = 0;
> +	int ret;
> +
> +	/*
> +	 * Multishot MUST be used on a pollable file
> +	 */
> +	if (!file_can_poll(req->file))
> +		return -EBADFD;
> +

Please disregard my previous comment about checking for
io_uring_fops. It is not necessary because this kind of file can't be
read in the first place, so it would never get here.

(Also, things seems to be misbehaving on my MUA archive and Lore didn't
get my own message yet, so I'm not replying directly to it)

-- 
Gabriel Krisman Bertazi

  parent reply	other threads:[~2023-09-12  1:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11 20:40 [PATCHSET 0/3] Add support for multishot reads Jens Axboe
2023-09-11 20:40 ` [PATCH 1/3] io_uring/rw: split io_read() into a helper Jens Axboe
2023-09-11 20:40 ` [PATCH 2/3] io_uring/rw: mark readv/writev as vectored in the opcode definition Jens Axboe
2023-09-11 20:40 ` [PATCH 3/3] io_uring/rw: add support for IORING_OP_READ_MULTISHOT Jens Axboe
2023-09-11 23:57   ` Gabriel Krisman Bertazi
2023-09-12  0:46     ` Jens Axboe
2023-09-12  0:53       ` Jens Axboe
2023-09-12  0:38   ` Gabriel Krisman Bertazi [this message]
2023-09-12  0:47     ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2023-09-12 17:24 [PATCHSET v2 0/3] Add support for multishot reads Jens Axboe
2023-09-12 17:24 ` [PATCH 3/3] io_uring/rw: add support for IORING_OP_READ_MULTISHOT Jens Axboe
2023-09-12 18:21   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox