From: Jens Axboe <[email protected]>
To: Stefano Garzarella <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH liburing v2 0/1] test: add epoll test case
Date: Fri, 31 Jan 2020 08:39:46 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 1/31/20 7:29 AM, Stefano Garzarella wrote:
> Hi Jens,
> this is a v2 of the epoll test.
>
> v1 -> v2:
> - if IORING_FEAT_NODROP is not available, avoid to overflow the CQ
> - add 2 new tests to test epoll with IORING_FEAT_NODROP
> - cleanups
>
> There are 4 sub-tests:
> 1. test_epoll
> 2. test_epoll_sqpoll
> 3. test_epoll_nodrop
> 4. test_epoll_sqpoll_nodrop
>
> In the first 2 tests, I try to avoid to queue more requests than we have room
> for in the CQ ring. These work fine, I have no faults.
Thanks!
> In the tests 3 and 4, if IORING_FEAT_NODROP is supported, I try to submit as
> much as I can until I get a -EBUSY, but they often fail in this way:
> the submitter manages to submit everything, the receiver receives all the
> submitted bytes, but the cleaner loses completion events (I also tried to put a
> timeout to epoll_wait() in the cleaner to be sure that it is not related to the
> patch that I send some weeks ago, but the situation doesn't change, it's like
> there is still overflow in the CQ).
>
> Next week I'll try to investigate better which is the problem.
Does it change if you have an io_uring_enter() with GETEVENTS set? I wonder if
you just pruned the CQ ring but didn't flush the internal side.
> I hope my test make sense, otherwise let me know what is wrong.
I'll take a look...
> Anyway, when I was exploring the library, I had a doubt:
> - in the __io_uring_get_cqe() should we call sys_io_uring_enter() also if
> submit and wait_nr are zero, but IORING_SQ_NEED_WAKEUP is set in the
> sq.kflags?
It's a submission side thing, the completion side shouldn't care. That
flag is only relevant if you're submitting IO with SQPOLL. Then it tells
you that the thread needs to get woken up, which you need io_uring_enter()
to do. But for just reaping completions and not needing to submit
anything new, we don't care if the thread is sleeping.
--
Jens Axboe
next prev parent reply other threads:[~2020-01-31 15:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 14:29 [PATCH liburing v2 0/1] test: add epoll test case Stefano Garzarella
2020-01-31 14:29 ` [PATCH liburing v2 1/1] " Stefano Garzarella
2020-01-31 15:41 ` Jens Axboe
2020-02-03 9:04 ` Stefano Garzarella
2020-02-03 15:43 ` Jens Axboe
2020-01-31 15:39 ` Jens Axboe [this message]
2020-02-03 9:03 ` [PATCH liburing v2 0/1] " Stefano Garzarella
2020-02-06 17:33 ` Stefano Garzarella
2020-02-06 19:15 ` Jens Axboe
2020-02-06 19:51 ` Jens Axboe
2020-02-06 20:12 ` Stefano Garzarella
2020-02-06 19:46 ` Jens Axboe
2020-02-07 16:51 ` Stefano Garzarella
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