From: Pavel Begunkov <[email protected]>
To: "Carter Li 李通洲" <[email protected]>,
io-uring <[email protected]>
Subject: Re: [FEATURE REQUEST] Specify a sqe won't generate a cqe
Date: Fri, 14 Feb 2020 13:34:02 +0300 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 2/14/2020 11:29 AM, Carter Li 李通洲 wrote:
> To implement io_uring_wait_cqe_timeout, we introduce a magic number
> called `LIBURING_UDATA_TIMEOUT`. The problem is that not only we
> must make sure that users should never set sqe->user_data to
> LIBURING_UDATA_TIMEOUT, but also introduce extra complexity to
> filter out TIMEOUT cqes.
>
> Former discussion: https://github.com/axboe/liburing/issues/53
>
> I’m suggesting introducing a new SQE flag called IOSQE_IGNORE_CQE
> to solve this problem.
>
> For a sqe tagged with IOSQE_IGNORE_CQE flag, it won’t generate a cqe
> on completion. So that IORING_OP_TIMEOUT can be filtered on kernel
> side.
>
> In addition, `IOSQE_IGNORE_CQE` can be used to save cq size.
>
> For example `POLL_ADD(POLLIN)->READ/RECV` link chain, people usually
> don’t care the result of `POLL_ADD` is ( since it will always be
> POLLIN ), `IOSQE_IGNORE_CQE` can be set on `POLL_ADD` to save lots
> of cq size.
>
> Besides POLL_ADD, people usually don’t care the result of POLL_REMOVE
> /TIMEOUT_REMOVE/ASYNC_CANCEL/CLOSE. These operations can also be tagged
> with IOSQE_IGNORE_CQE.
>
> Thoughts?
>
I like the idea! And that's one of my TODOs for the eBPF plans.
Let me list my use cases, so we can think how to extend it a bit.
1. In case of link fail, we need to reap all -ECANCELLED, analise it and
resubmit the rest. It's quite inconvenient. We may want to have CQE only
for not cancelled requests.
2. When chain succeeded, you in the most cases already know the result
of all intermediate CQEs, but you still need to reap and match them.
I'd prefer to have only 1 CQE per link, that is either for the first
failed or for the last request in the chain.
These 2 may shed much processing overhead from the userspace.
3. If we generate requests by eBPF even the notion of per-request event
may broke.
- eBPF creating new requests would also need to specify user-data, and
this may be problematic from the user perspective.
- may want to not generate CQEs automatically, but let eBPF do it.
--
Pavel Begunkov
next prev parent reply other threads:[~2020-02-14 10:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 8:29 [FEATURE REQUEST] Specify a sqe won't generate a cqe Carter Li 李通洲
2020-02-14 10:34 ` Pavel Begunkov [this message]
2020-02-14 11:27 ` Carter Li 李通洲
2020-02-14 12:52 ` Pavel Begunkov
2020-02-14 13:27 ` Carter Li 李通洲
2020-02-14 14:16 ` 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] \
/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