From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, Keith Busch <[email protected]>,
[email protected], [email protected]
Cc: Keith Busch <[email protected]>
Subject: Re: [PATCH 1/3] io_uring: split req init from submit
Date: Tue, 1 Aug 2023 15:13:59 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 7/31/23 22:00, Jens Axboe wrote:
> On 7/31/23 6:53?AM, Pavel Begunkov wrote:
>> On 7/28/23 21:14, Keith Busch wrote:
>>> From: Keith Busch <[email protected]>
>>>
>>> Split the req initialization and link handling from the submit. This
>>> simplifies the submit path since everything that can fail is separate
>>> from it, and makes it easier to create batched submissions later.
>>
>> Keith, I don't think this prep patch does us any good, I'd rather
>> shove the link assembling code further out of the common path. I like
>> the first version more (see [1]). I'd suggest to merge it, and do
>> cleaning up after.
>>
>> I'll also say that IMHO the overhead is well justified. It's not only
>> about having multiple nvmes, the problem slows down cases mixing storage
>> with net and the rest of IO in a single ring.
>>
>> [1] https://lore.kernel.org/io-uring/[email protected]/
>
> The downside of that one, to me, is that it just serializes all of it
> and we end up looping over the submission list twice.
Right, and there is nothing can be done if we want to know about all
requests in advance, at least without changing uapi and/or adding
userspace hints.
> With alloc+init
> split, at least we get some locality wins by grouping the setup side of
> the requests.
I don't think I follow, what grouping do you mean? As far as I see, v1
and v2 are essentially same with the difference of whether you have a
helper for setting up links or not, see io_setup_link() from v2. In both
cases it's executed in the same sequence:
1) init (generic init + opcode init + link setup) each request and put
into a temporary list.
2) go go over the list and submit them one by one
And after inlining they should look pretty close.
--
Pavel Begunkov
next prev parent reply other threads:[~2023-08-01 14:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 20:14 [PATCH 1/3] io_uring: split req init from submit Keith Busch
2023-07-28 20:14 ` [PATCH 2/3] io_uring: split req prep and submit loops Keith Busch
2023-07-28 20:14 ` [PATCH 3/3] io_uring: set plug tags for same file Keith Busch
2023-07-31 12:53 ` [PATCH 1/3] io_uring: split req init from submit Pavel Begunkov
2023-07-31 21:00 ` Jens Axboe
2023-08-01 14:13 ` Pavel Begunkov [this message]
2023-08-01 15:17 ` Keith Busch
2023-08-01 16:05 ` Pavel Begunkov
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] \
[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