From: Caleb Sander Mateos <csander@purestorage.com>
To: Keith Busch <kbusch@meta.com>
Cc: axboe@kernel.dk, io-uring@vger.kernel.org,
Keith Busch <kbusch@kernel.org>
Subject: Re: [RFC PATCH 1/1] io_uring: add support for IORING_SETUP_SQE_MIXED
Date: Fri, 29 Aug 2025 14:29:39 -0700 [thread overview]
Message-ID: <CADUfDZqpTsEOROA0Tkrq1WprpBvmzvhMPiFXZwLT4WMTSmAXqQ@mail.gmail.com> (raw)
In-Reply-To: <20250829193935.1910175-3-kbusch@meta.com>
On Fri, Aug 29, 2025 at 12:41 PM Keith Busch <kbusch@meta.com> wrote:
>
> From: Keith Busch <kbusch@kernel.org>
>
> Normal rings support 64b SQEs for posting submissions, while certain
> features require the ring to be configured with IORING_SETUP_SQE128, as
> they need to convey more information per submission. This, in turn,
> makes ALL the SQEs be 128b in size. This is somewhat wasteful and
> inefficient, particularly when only certain SQEs need to be of the
> bigger variant.
>
> This adds support for setting up a ring with mixed SQE sizes, using
> IORING_SETUP_SQE_MIXED. When setup in this mode, SQEs posted to the ring
> may be either 64b or 128b in size. If a SQE is 128b in size, then
> IOSQE_SQE_128B flag is set in the SQE flags to indicate that this is the
> case. If this flag isn't set, the SQE is the normal 64b variant.
>
> SQEs on these types of mixed rings may also utilize NOP with skip
> success set. This can happen if the ring is one (small) SQE entry away
> from wrapping, and an attempt is made to post a 128b SQE. As SQEs must be
> contigious in the SQ ring, a 128b SQE cannot wrap the ring. For this
typo: contiguous"
> case, a single NOP SQE is posted with the SKIP flag set. The kernel
> should simply ignore those.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
> include/uapi/linux/io_uring.h | 9 +++++++++
> io_uring/fdinfo.c | 21 ++++++++++-----------
> io_uring/io_uring.c | 15 ++++++++++++++-
> 3 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> index 04ebff33d0e62..9cef9085f52ee 100644
> --- a/include/uapi/linux/io_uring.h
> +++ b/include/uapi/linux/io_uring.h
> @@ -146,6 +146,7 @@ enum io_uring_sqe_flags_bit {
> IOSQE_ASYNC_BIT,
> IOSQE_BUFFER_SELECT_BIT,
> IOSQE_CQE_SKIP_SUCCESS_BIT,
> + IOSQE_SQE_128B_BIT,
> };
>
> /*
> @@ -165,6 +166,8 @@ enum io_uring_sqe_flags_bit {
> #define IOSQE_BUFFER_SELECT (1U << IOSQE_BUFFER_SELECT_BIT)
> /* don't post CQE if request succeeded */
> #define IOSQE_CQE_SKIP_SUCCESS (1U << IOSQE_CQE_SKIP_SUCCESS_BIT)
> +/* this is a 128b/big-sqe posting */
> +#define IOSQE_SQE_128B (1U << IOSQE_SQE_128B_BIT)
>
> /*
> * io_uring_setup() flags
> @@ -231,6 +234,12 @@ enum io_uring_sqe_flags_bit {
> */
> #define IORING_SETUP_CQE_MIXED (1U << 18)
>
> +/*
> + * Allow both 64b and 128b SQEs. If a 128b SQE is posted, it will have
> + * IOSQE_SQE_128B set in sqe->flags.
> + */
> +#define IORING_SETUP_SQE_MIXED (1U << 19)
> +
> enum io_uring_op {
> IORING_OP_NOP,
> IORING_OP_READV,
> diff --git a/io_uring/fdinfo.c b/io_uring/fdinfo.c
> index 5c73398387690..4eb6dbb9807be 100644
> --- a/io_uring/fdinfo.c
> +++ b/io_uring/fdinfo.c
> @@ -65,15 +65,10 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
> unsigned int sq_tail = READ_ONCE(r->sq.tail);
> unsigned int cq_head = READ_ONCE(r->cq.head);
> unsigned int cq_tail = READ_ONCE(r->cq.tail);
> - unsigned int sq_shift = 0;
> - unsigned int sq_entries;
> int sq_pid = -1, sq_cpu = -1;
> u64 sq_total_time = 0, sq_work_time = 0;
> unsigned int i;
>
> - if (ctx->flags & IORING_SETUP_SQE128)
> - sq_shift = 1;
> -
> /*
> * we may get imprecise sqe and cqe info if uring is actively running
> * since we get cached_sq_head and cached_cq_tail without uring_lock
> @@ -89,18 +84,19 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
> seq_printf(m, "CqTail:\t%u\n", cq_tail);
> seq_printf(m, "CachedCqTail:\t%u\n", data_race(ctx->cached_cq_tail));
> seq_printf(m, "SQEs:\t%u\n", sq_tail - sq_head);
> - sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
> - for (i = 0; i < sq_entries; i++) {
> - unsigned int entry = i + sq_head;
> + while (sq_head < sq_tail) {
> struct io_uring_sqe *sqe;
> unsigned int sq_idx;
> + bool sqe128 = false;
>
> if (ctx->flags & IORING_SETUP_NO_SQARRAY)
> break;
> - sq_idx = READ_ONCE(ctx->sq_array[entry & sq_mask]);
> + sq_idx = READ_ONCE(ctx->sq_array[sq_head & sq_mask]);
> if (sq_idx > sq_mask)
> continue;
> - sqe = &ctx->sq_sqes[sq_idx << sq_shift];
> + sqe = &ctx->sq_sqes[sq_idx];
We still need to double the sq_idx in the IORING_SETUP_SQE128 case, right?
> + if (sqe->flags & IOSQE_SQE_128B || ctx->flags & IORING_SETUP_SQE128)
> + sqe128 = true;
> seq_printf(m, "%5u: opcode:%s, fd:%d, flags:%x, off:%llu, "
> "addr:0x%llx, rw_flags:0x%x, buf_index:%d "
> "user_data:%llu",
> @@ -108,7 +104,7 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
> sqe->flags, (unsigned long long) sqe->off,
> (unsigned long long) sqe->addr, sqe->rw_flags,
> sqe->buf_index, sqe->user_data);
> - if (sq_shift) {
> + if (sqe128) {
> u64 *sqeb = (void *) (sqe + 1);
Needs to check that IOSQE_SQE_128B isn't set on the last entry in the
SQE array to avoid accessing past the end of it?
> int size = sizeof(struct io_uring_sqe) / sizeof(u64);
> int j;
> @@ -120,6 +116,9 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
> }
> }
> seq_printf(m, "\n");
> + sq_head++;
> + if (sqe128)
> + sq_head++;
> }
> seq_printf(m, "CQEs:\t%u\n", cq_tail - cq_head);
> while (cq_head < cq_tail) {
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index 6c07efac977ce..7788292be8560 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -2416,6 +2416,8 @@ static bool io_get_sqe(struct io_ring_ctx *ctx, const struct io_uring_sqe **sqe)
> if (ctx->flags & IORING_SETUP_SQE128)
> head <<= 1;
> *sqe = &ctx->sq_sqes[head];
> + if (ctx->flags & IORING_SETUP_SQE_MIXED && (*sqe)->flags & IOSQE_SQE_128B)
Use READ_ONCE() to read userspace-mapped memory?
Do we also need to check that this isn't the last entry in the SQEs
array? Otherwise, it seems like buggy/malicious userspace can cause
the kernel to read past the end of the array.
> + ctx->cached_sq_head++;
Probably worth documenting that when using the SQ indirection array
(i.e. not IORING_SETUP_NO_SQARRAY), the index into the indirection
array is expected to increment twice for a 128-byte SQE even though it
still only uses a single unsigned entry in this array. I can see how
this behavior eases the liburing implementation of this (so the
indirection array is always an identity mapping to the SQE array), but
it might be surprising for applications that reuse SQEs and only
modify the indirection array that they have to skip an extra entry in
the indirection array.
io_get_sequence() seems to have some funky logic that assumes
cached_sq_head counts full I/Os rather than SQEs, so this might break
it.
io_sqring_entries() also computes sq.tail - cached_sq_head, which I
don't think works in the presence of IOSQE_SQE_128B. io_submit_sqes()
probably needs to compare cached_sq_head to the (cached) value of
sq.tail to tell when all the SQEs have been consumed.
> return true;
> }
>
> @@ -2793,6 +2795,10 @@ unsigned long rings_size(unsigned int flags, unsigned int sq_entries,
> if (cq_entries < 2)
> return SIZE_MAX;
> }
> + if (flags & IORING_SETUP_SQE_MIXED) {
> + if (sq_entries < 2)
> + return SIZE_MAX;
> + }
>
> #ifdef CONFIG_SMP
> off = ALIGN(off, SMP_CACHE_BYTES);
> @@ -3724,6 +3730,13 @@ static int io_uring_sanitise_params(struct io_uring_params *p)
> if ((flags & (IORING_SETUP_CQE32|IORING_SETUP_CQE_MIXED)) ==
> (IORING_SETUP_CQE32|IORING_SETUP_CQE_MIXED))
> return -EINVAL;
> + /*
> + * Nonsensical to ask for SQE128 and mixed SQE support, it's not
> + * supported to post 64b SQEs on a ring setup with SQE128.
> + */
> + if ((flags & (IORING_SETUP_SQE128|IORING_SETUP_SQE_MIXED)) ==
> + (IORING_SETUP_SQE128|IORING_SETUP_SQE_MIXED))
> + return -EINVAL;
>
> return 0;
> }
> @@ -3952,7 +3965,7 @@ static long io_uring_setup(u32 entries, struct io_uring_params __user *params)
> IORING_SETUP_SINGLE_ISSUER | IORING_SETUP_DEFER_TASKRUN |
> IORING_SETUP_NO_MMAP | IORING_SETUP_REGISTERED_FD_ONLY |
> IORING_SETUP_NO_SQARRAY | IORING_SETUP_HYBRID_IOPOLL |
> - IORING_SETUP_CQE_MIXED))
> + IORING_SETUP_CQE_MIXED | IORING_SETUP_SQE_MIXED))
There are a few other users of IORING_SETUP_SQE128 that likely need to
be made aware of IOSQE_SQE_128B. For one, uring_sqe_size(), which is
used to determine how large the SQE payload is when copying it for a
uring_cmd that goes async. And the logic for setting IO_URING_F_SQE128
in io_uring_cmd() also needs to be adjusted.
Best,
Caleb
> return -EINVAL;
>
> return io_uring_create(entries, &p, params);
> --
> 2.47.3
>
>
next prev parent reply other threads:[~2025-08-29 21:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 19:39 [RFC PATCH 0/1] io_uring: mixed sqe support Keith Busch
2025-08-29 19:39 ` [RFC PATCH liburing 1/2] Add support IORING_SETUP_SQE_MIXED Keith Busch
2025-08-29 19:39 ` [RFC PATCH 1/1] io_uring: add support for IORING_SETUP_SQE_MIXED Keith Busch
2025-08-29 21:29 ` Caleb Sander Mateos [this message]
2025-09-02 18:03 ` Keith Busch
2025-08-29 19:39 ` [RFC PATCH liburing 2/2] Add nop testing " 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=CADUfDZqpTsEOROA0Tkrq1WprpBvmzvhMPiFXZwLT4WMTSmAXqQ@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