From: Stefan Hajnoczi <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Resizing io_uring SQ/CQ?
Date: Thu, 9 Mar 2023 08:48:08 -0500 [thread overview]
Message-ID: <20230309134808.GA374376@fedora> (raw)
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]
Hi,
For block I/O an application can queue excess SQEs in userspace when the
SQ ring becomes full. For network and IPC operations that is not
possible because deadlocks can occur when socket, pipe, and eventfd SQEs
cannot be submitted.
Sometimes the application does not know how many SQEs/CQEs are needed upfront
and that's when we face this challenge.
A simple solution is to call io_uring_setup(2) with a higher entries
value than you'll ever need. However, if that value is exceeded then
we're back to the deadlock scenario and that worries me.
I've thought about userspace solutions like keeping a list of io_uring
contexts where a new io_uring context is created and inserted at the
head every time a resize is required. New SQEs are only submitted to the
head io_uring context. The older io_uring contexts are drained until the
CQ ring is empty and then destroyed. But this seems complex to me.
Another idea is a new io_uring_register(2) IORING_REGISTER_RING_SIZE
opcode:
1. Userspace ensures that the kernel has seen all SQEs in the SQ ring.
2. Userspace munmaps the ring fd.
3. Userspace calls io_uring_register(2) IORING_REGISTER_RING_SIZE with the new size.
4. The kernel allocates the new ring.
5. The kernel copies over CQEs that userspace has not consumed from the
old CQ ring to the new one.
6. The io_uring_register(2) syscall returns.
7. Userspace mmaps the fd again.
How do you deal with changing ring size at runtime?
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2023-03-09 15:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 13:48 Stefan Hajnoczi [this message]
2023-03-10 1:38 ` Resizing io_uring SQ/CQ? Ming Lei
2023-03-10 2:58 ` Jens Axboe
2023-03-10 3:42 ` Vito Caputo
2023-03-10 13:44 ` Stefan Hajnoczi
2023-03-10 15:14 ` Ming Lei
2023-03-10 16:39 ` Stefan Hajnoczi
2023-03-10 16:56 ` Stefan Hajnoczi
2023-03-15 15:18 ` Jens Axboe
2023-03-15 15:15 ` Stefan Hajnoczi
2023-03-15 15:19 ` Jens Axboe
2023-03-15 19:01 ` Stefan Hajnoczi
2023-03-15 19:10 ` 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 \
--in-reply-to=20230309134808.GA374376@fedora \
[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