public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: Caleb Sander Mateos <csander@purestorage.com>
To: Keith Busch <kbusch@meta.com>
Cc: io-uring@vger.kernel.org, axboe@kernel.dk,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv5 1/4] liburing: provide uring_cmd prep function
Date: Sun, 19 Oct 2025 09:24:10 -0700	[thread overview]
Message-ID: <CADUfDZp-6s8QYAoeikMG98MhvfsZ0V-Vu_EGVoHUhthM=xth6Q@mail.gmail.com> (raw)
In-Reply-To: <20251013180011.134131-4-kbusch@meta.com>

Looks good to me, just a few minor comments.

On Mon, Oct 13, 2025 at 11:00 AM Keith Busch <kbusch@meta.com> wrote:
>
> From: Keith Busch <kbusch@kernel.org>
>
> The rw prep doesn't clear __pad1, which is a reserved field for

io_uring_prep_rw() does assign to sqe->off, which is unioned with
cmd_op and __pad1. Though obviously __pad1 being set to 0 is dependent
on a offset being passed as 0 to io_uring_prep_rw(). But I certainly
agree a dedicated helper for IORING_OP_URING_CMD is a great
improvement.

> uring_cmd. If a prior submission in that entry did use that field, the
> uring_cmd will fail the kernel's checks.
>
> Also, the nvme uring_cmd tests had a couple places setting the sqe addr
> and length, which are unused fields for the nvme uring_cmds, so they
> shouldn't have been doing that, though had been checking these, so it

"had" -> "hadn't"?

> didn't cause any errors.
>
> Provide a helper function specific to the uring_cmd preparation.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
>  src/include/liburing.h      | 19 +++++++++++++++----
>  test/io_uring_passthrough.c | 14 ++++----------
>  2 files changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/src/include/liburing.h b/src/include/liburing.h
> index c80bffd3..f7af20aa 100644
> --- a/src/include/liburing.h
> +++ b/src/include/liburing.h
> @@ -1517,6 +1517,19 @@ IOURINGINLINE void io_uring_prep_socket_direct_alloc(struct io_uring_sqe *sqe,
>         __io_uring_set_target_fixed_file(sqe, IORING_FILE_INDEX_ALLOC - 1);
>  }
>
> +IOURINGINLINE void io_uring_prep_uring_cmd(struct io_uring_sqe *sqe,
> +                                          int cmd_op,

I see this is copied from io_uring_prep_cmd_sock(), but u32 is
probably more accurate.


> +                                          int fd)
> +       LIBURING_NOEXCEPT
> +{
> +       sqe->opcode = (__u8) IORING_OP_URING_CMD;

Casting the constant seems unnecessary. Do compilers really warn about this?

> +       sqe->fd = fd;
> +       sqe->cmd_op = cmd_op;
> +       sqe->__pad1 = 0;
> +       sqe->addr = 0ul;
> +       sqe->len = 0;
> +}
> +
>  /*
>   * Prepare commands for sockets
>   */
> @@ -1529,11 +1542,10 @@ IOURINGINLINE void io_uring_prep_cmd_sock(struct io_uring_sqe *sqe,
>                                           int optlen)
>         LIBURING_NOEXCEPT
>  {
> -       io_uring_prep_rw(IORING_OP_URING_CMD, sqe, fd, NULL, 0, 0);
> +       io_uring_prep_uring_cmd(sqe, cmd_op, fd);
>         sqe->optval = (unsigned long) (uintptr_t) optval;
>         sqe->optname = optname;
>         sqe->optlen = optlen;
> -       sqe->cmd_op = cmd_op;
>         sqe->level = level;
>  }
>
> @@ -1607,8 +1619,7 @@ IOURINGINLINE void io_uring_prep_cmd_discard(struct io_uring_sqe *sqe,
>                                              uint64_t offset, uint64_t nbytes)
>         LIBURING_NOEXCEPT
>  {
> -       io_uring_prep_rw(IORING_OP_URING_CMD, sqe, fd, 0, 0, 0);
> -       sqe->cmd_op = BLOCK_URING_CMD_DISCARD;
> +       io_uring_prep_uring_cmd(sqe, BLOCK_URING_CMD_DISCARD, fd);
>         sqe->addr = offset;
>         sqe->addr3 = nbytes;
>  }
> diff --git a/test/io_uring_passthrough.c b/test/io_uring_passthrough.c
> index beaa81ad..26051710 100644
> --- a/test/io_uring_passthrough.c
> +++ b/test/io_uring_passthrough.c
> @@ -148,11 +148,9 @@ static int __test_io(const char *file, struct io_uring *ring, int tc, int read,
>                 if (async)
>                         sqe->flags |= IOSQE_ASYNC;
>                 if (nonvec)
> -                       sqe->cmd_op = NVME_URING_CMD_IO;
> +                       io_uring_prep_uring_cmd(sqe, NVME_URING_CMD_IO, use_fd);

I guess this works because io_uring_prep_uring_cmd() doesn't touch
sqe->buf_index or sqe->flags, but it seems like it would be less
brittle to call io_uring_prep_uring_cmd() before setting any of the
other sqe fields.

>                 else
> -                       sqe->cmd_op = NVME_URING_CMD_IO_VEC;
> -               sqe->fd = use_fd;
> -               sqe->opcode = IORING_OP_URING_CMD;
> +                       io_uring_prep_uring_cmd(sqe, NVME_URING_CMD_IO_VEC, use_fd);
>                 if (do_fixed)
>                         sqe->uring_cmd_flags |= IORING_URING_CMD_FIXED;
>                 sqe->user_data = ((uint64_t)offset << 32) | i;
> @@ -328,9 +326,7 @@ static int test_invalid_passthru_submit(const char *file)
>         }
>
>         sqe = io_uring_get_sqe(&ring);
> -       io_uring_prep_read(sqe, fd, vecs[0].iov_base, vecs[0].iov_len, 0);
> -       sqe->cmd_op = NVME_URING_CMD_IO;
> -       sqe->opcode = IORING_OP_URING_CMD;
> +       io_uring_prep_uring_cmd(sqe, NVME_URING_CMD_IO, fd);
>         sqe->user_data = 1;
>         cmd = (struct nvme_uring_cmd *)sqe->cmd;
>         memset(cmd, 0, sizeof(struct nvme_uring_cmd));
> @@ -401,10 +397,8 @@ static int test_io_uring_submit_enters(const char *file)
>                 __u32 nlb;
>
>                 sqe = io_uring_get_sqe(&ring);
> -               io_uring_prep_readv(sqe, fd, &vecs[i], 1, offset);
> +               io_uring_prep_uring_cmd(sqe, NVME_URING_CMD_IO, fd);
>                 sqe->user_data = i;
> -               sqe->opcode = IORING_OP_URING_CMD;
> -               sqe->cmd_op = NVME_URING_CMD_IO;
>                 cmd = (struct nvme_uring_cmd *)sqe->cmd;
>                 memset(cmd, 0, sizeof(struct nvme_uring_cmd));
>
> --
> 2.47.3
>

  reply	other threads:[~2025-10-19 16:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 18:00 [PATCHv5 0/4] liburing: support for mix sized sqe's Keith Busch
2025-10-13 18:00 ` [PATCHv5 0/1] io_uring: mixed submission queue entries sizes Keith Busch
2025-10-13 18:00 ` [PATCHv5 1/1] io_uring: add support for IORING_SETUP_SQE_MIXED Keith Busch
2025-10-14 22:33   ` Caleb Sander Mateos
2025-10-15  2:03     ` Keith Busch
2025-10-16 18:06       ` Keith Busch
2025-10-13 18:00 ` [PATCHv5 1/4] liburing: provide uring_cmd prep function Keith Busch
2025-10-19 16:24   ` Caleb Sander Mateos [this message]
2025-10-21 16:45     ` Keith Busch
2025-10-13 18:00 ` [PATCHv5 2/4] Add support IORING_SETUP_SQE_MIXED Keith Busch
2025-10-13 18:00 ` [PATCHv5 3/4] Add nop testing for IORING_SETUP_SQE_MIXED Keith Busch
2025-10-13 18:00 ` [PATCHv5 4/4] Add mixed sqe test for uring commands Keith Busch

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 \
    --in-reply-to='CADUfDZp-6s8QYAoeikMG98MhvfsZ0V-Vu_EGVoHUhthM=xth6Q@mail.gmail.com' \
    --to=csander@purestorage.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    /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