From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Subject: Re: [PATCH v2 0/4] allow to skip CQE posting
Date: Wed, 24 Nov 2021 18:02:15 +0000 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 11/24/21 17:57, Jens Axboe wrote:
> On 11/24/21 10:55 AM, Pavel Begunkov wrote:
>> On 11/10/21 16:47, Jens Axboe wrote:
>>> On 11/10/21 9:42 AM, Pavel Begunkov wrote:
>>>> On 11/10/21 16:14, Jens Axboe wrote:
>>>>> On 11/10/21 8:49 AM, Pavel Begunkov wrote:
>>>>>> It's expensive enough to post an CQE, and there are other
>>>>>> reasons to want to ignore them, e.g. for link handling and
>>>>>> it may just be more convenient for the userspace.
>>>>>>
>>>>>> Try to cover most of the use cases with one flag. The overhead
>>>>>> is one "if (cqe->flags & IOSQE_CQE_SKIP_SUCCESS)" check per
>>>>>> requests and a bit bloated req_set_fail(), should be bearable.
>>>>>
>>>>> I like the idea, one thing I'm struggling with is I think a normal use
>>>>> case of this would be fast IO where we still need to know if a
>>>>> completion event has happened, we just don't need to know the details of
>>>>> it since we already know what those details would be if it ends up in
>>>>> success.
>>>>>
>>>>> How about having a skip counter? That would supposedly also allow drain
>>>>> to work, and it could be mapped with the other cq parts to allow the app
>>>>> to see it as well.
>>>>
>>>> It doesn't go through expensive io_cqring_ev_posted(), so the
>>>> userspace can't really wait on it. It can do some linking tricks to
>>>> alleviate that, but I don't see any new capabilities from the current
>>>> approach.
>>>
>>> I'm not talking about waiting, just reading the cqring entry to see how
>>> many were skipped. If you ask for no cqe, by definition there would be
>>> nothing to wait on for you. Though it'd probably be better as an sqring
>>> entry, since we'd be accounting at that time. Only caveat there is then
>>> if the sqe errors and we do end up posting a cqe..
>>>
>>>> Also the locking is a problem, I was thinking about it, mainly hoping
>>>> that I can adjust cq_extra and leave draining, but it didn't appear
>>>> great to me. AFAIK, it's either an atomic, beating the purpose of the
>>>> thing.
>>>
>>> If we do submission side, then the ring mutex would cover it. No need
>>> for any extra locking
>>
>> Jens, let's decide what we're going to do with this feature
>
> Only weird bit is the drain, but apart from that I think it looks sane.
agree, but I can't find a fix without penalising performance
> Are you going to send a documentation update to liburing as well? Should
> be detailed in terms of what it does and the usability of it.
yeah, and also need to rebase and resend tests
--
Pavel Begunkov
next prev parent reply other threads:[~2021-11-24 18:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-10 15:49 [PATCH v2 0/4] allow to skip CQE posting Pavel Begunkov
2021-11-10 15:49 ` [PATCH v2 1/4] io_uring: clean cqe filling functions Pavel Begunkov
2021-11-10 15:49 ` [PATCH v2 2/4] io_uring: add option to skip CQE posting Pavel Begunkov
2021-11-10 15:49 ` [PATCH v2 3/4] io_uring: don't spinlock when not posting CQEs Pavel Begunkov
2021-11-25 3:48 ` Hao Xu
2021-11-25 7:35 ` Hao Xu
2021-11-10 15:49 ` [PATCH v2 4/4] io_uring: disable drain with cqe skip Pavel Begunkov
2021-11-10 16:14 ` [PATCH v2 0/4] allow to skip CQE posting Jens Axboe
2021-11-10 16:42 ` Pavel Begunkov
2021-11-10 16:47 ` Jens Axboe
2021-11-24 17:55 ` Pavel Begunkov
2021-11-24 17:57 ` Jens Axboe
2021-11-24 18:02 ` Pavel Begunkov [this message]
2021-11-24 18:17 ` Jens Axboe
2021-11-25 9:35 ` Hao Xu
2021-11-25 14:22 ` Pavel Begunkov
2021-11-24 18:18 ` Jens Axboe
2021-12-06 19:49 ` Olivier Langlois
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] \
/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