From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
Keith Busch <kbusch@meta.com>,
io-uring@vger.kernel.org, Keith Busch <kbusch@kernel.org>
Subject: Re: [RFC PATCHv2 1/1] io_uring: add support for IORING_SETUP_SQE_MIXED
Date: Thu, 11 Sep 2025 10:19:06 +0800 [thread overview]
Message-ID: <aMIxmiGv5D0GvSro@fedora> (raw)
In-Reply-To: <aMIv4zFIJVj-dza5@fedora>
On Thu, Sep 11, 2025 at 10:11:47AM +0800, Ming Lei wrote:
> On Wed, Sep 10, 2025 at 06:28:43PM -0600, Jens Axboe wrote:
> > On 9/10/25 11:44 AM, Caleb Sander Mateos wrote:
> > >> 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,
> > >
> > > Have you given any thought to how we would handle the likely scenario
> > > that we want to define more SQE flags in the future? Are there
> > > existing unused bytes of the SQE where the new flags could go? If not,
> > > we may need to repurpose some existing but rarely used field. And then
> > > we'd likely want to reserve this last flag bit to specify whether the
> > > SQE is using this "extended flags" field.
> >
> > Yep this is my main problem with this change. If you search the io_uring
> > list on lore you can find discussions about this in relation to when
> > Ming had his SQE grouping patches that also used this last bit. My
> > suggestion then was indeed to have this last flag be "look at XX for
> > IOSQE2_* flags". But it never quite got finalized. IIRC, my suggestion
> > back then was to use the personality field, since it's a pretty
> > specialized use case. Only issue with that is that you could then not
> > use IOSQE2_* flags with personality.
> >
> > IOW, I think the IOSQE_SQE_128B flag is fine for prototyping and testing
> > these patches, but we unfortunately do need to iron out how on earth
> > we'll expose some more flags before this can go in.
>
> SQE128 is used for uring_cmd only, so it could be one uring_cmd
> private flag. However, the implementation may be ugly and fragile.
Or in case of IORING_SETUP_SQE_MIXED, IORING_OP_URING_CMD is always interpreted
as plain 64bit SQE, also add IORING_OP_URING_CMD128 for SQE128 only.
Thanks,
Ming
next prev parent reply other threads:[~2025-09-11 2:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 19:27 [RFC PATCHv2 0/1] Keith Busch
2025-09-04 19:27 ` [RFC PATCHv2 1/3] Add support IORING_SETUP_SQE_MIXED Keith Busch
2025-09-11 16:27 ` Caleb Sander Mateos
2025-09-04 19:27 ` [RFC PATCHv2 1/1] io_uring: add support for IORING_SETUP_SQE_MIXED Keith Busch
2025-09-10 17:44 ` Caleb Sander Mateos
2025-09-11 0:28 ` Jens Axboe
2025-09-11 2:11 ` Ming Lei
2025-09-11 2:19 ` Ming Lei [this message]
2025-09-11 13:02 ` Keith Busch
2025-09-11 13:07 ` Ming Lei
2025-09-17 14:44 ` Jens Axboe
2025-09-18 21:22 ` Keith Busch
2025-09-18 23:35 ` Jens Axboe
2025-09-11 2:06 ` Keith Busch
2025-09-04 19:27 ` [RFC PATCHv2 2/3] Add nop testing " Keith Busch
2025-09-04 19:27 ` [RFC PATCHv2 3/3] 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=aMIxmiGv5D0GvSro@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--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