public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Ming Lei <[email protected]>, Stefan Hajnoczi <[email protected]>
Cc: [email protected]
Subject: Re: Resizing io_uring SQ/CQ?
Date: Thu, 9 Mar 2023 19:58:31 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 3/9/23 6:38?PM, Ming Lei wrote:
> On Thu, Mar 09, 2023 at 08:48:08AM -0500, Stefan Hajnoczi wrote:
>> 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.
> 
> Can you explain a bit the deadlock in case of network application? io_uring
> does support to queue many network SQEs via IOSQE_IO_LINK, at least for
> send.
> 
>>
>> Sometimes the application does not know how many SQEs/CQEs are needed upfront
>> and that's when we face this challenge.
> 
> When running out of SQEs,  the application can call io_uring_enter() to submit
> queued SQEs immediately without waiting for get events, then once
> io_uring_enter() returns, you get free SQEs for moving one.
> 
>>
>> 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.
> 
> Can you please explain the deadlock scenario?

I'm also curious of what these deadlocks are. As Ming says, you
generally never run out of SQEs as you can always just submit what you
have pending and now you have a full queue size worth of them available
again.

I do think resizing the CQ ring may have some merit, as for networking
you may want to start smaller and resize it if you run into overflows as
those will be less efficient. But I'm somewhat curious on the reasonings
for wanting to resize the SQ ring?

-- 
Jens Axboe


  reply	other threads:[~2023-03-10  2:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 13:48 Resizing io_uring SQ/CQ? Stefan Hajnoczi
2023-03-10  1:38 ` Ming Lei
2023-03-10  2:58   ` Jens Axboe [this message]
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 \
    [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