public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Xiaoguang Wang <[email protected]>,
	[email protected]
Cc: [email protected]
Subject: Re: [PATCH] io_uring: export cq overflow status to userspace
Date: Tue, 7 Jul 2020 11:23:23 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 7/7/20 10:36 AM, Xiaoguang Wang wrote:
> hi,
> 
>> On 7/7/20 8:28 AM, Jens Axboe wrote:
>>> On 7/7/20 7:24 AM, Xiaoguang Wang wrote:
>>>> For those applications which are not willing to use io_uring_enter()
>>>> to reap and handle cqes, they may completely rely on liburing's
>>>> io_uring_peek_cqe(), but if cq ring has overflowed, currently because
>>>> io_uring_peek_cqe() is not aware of this overflow, it won't enter
>>>> kernel to flush cqes, below test program can reveal this bug:
>>>>
>>>> static void test_cq_overflow(struct io_uring *ring)
>>>> {
>>>>          struct io_uring_cqe *cqe;
>>>>          struct io_uring_sqe *sqe;
>>>>          int issued = 0;
>>>>          int ret = 0;
>>>>
>>>>          do {
>>>>                  sqe = io_uring_get_sqe(ring);
>>>>                  if (!sqe) {
>>>>                          fprintf(stderr, "get sqe failed\n");
>>>>                          break;;
>>>>                  }
>>>>                  ret = io_uring_submit(ring);
>>>>                  if (ret <= 0) {
>>>>                          if (ret != -EBUSY)
>>>>                                  fprintf(stderr, "sqe submit failed: %d\n", ret);
>>>>                          break;
>>>>                  }
>>>>                  issued++;
>>>>          } while (ret > 0);
>>>>          assert(ret == -EBUSY);
>>>>
>>>>          printf("issued requests: %d\n", issued);
>>>>
>>>>          while (issued) {
>>>>                  ret = io_uring_peek_cqe(ring, &cqe);
>>>>                  if (ret) {
>>>>                          if (ret != -EAGAIN) {
>>>>                                  fprintf(stderr, "peek completion failed: %s\n",
>>>>                                          strerror(ret));
>>>>                                  break;
>>>>                          }
>>>>                          printf("left requets: %d\n", issued);
>>>>                          continue;
>>>>                  }
>>>>                  io_uring_cqe_seen(ring, cqe);
>>>>                  issued--;
>>>>                  printf("left requets: %d\n", issued);
>>>>          }
>>>> }
>>>>
>>>> int main(int argc, char *argv[])
>>>> {
>>>>          int ret;
>>>>          struct io_uring ring;
>>>>
>>>>          ret = io_uring_queue_init(16, &ring, 0);
>>>>          if (ret) {
>>>>                  fprintf(stderr, "ring setup failed: %d\n", ret);
>>>>                  return 1;
>>>>          }
>>>>
>>>>          test_cq_overflow(&ring);
>>>>          return 0;
>>>> }
>>>>
>>>> To fix this issue, export cq overflow status to userspace, then
>>>> helper functions() in liburing, such as io_uring_peek_cqe, can be
>>>> aware of this cq overflow and do flush accordingly.
>>>
>>> Is there any way we can accomplish the same without exporting
>>> another set of flags? Would it be enough for the SQPOLl thread to set
>>> IORING_SQ_NEED_WAKEUP if we're in overflow condition? That should
>>> result in the app entering the kernel when it's flushed the user CQ
>>> side, and then the sqthread could attempt to flush the pending
>>> events as well.
>>>
>>> Something like this, totally untested...
>>
>> OK, took a closer look at this, it's a generic thing, not just
>> SQPOLL related. My bad!
>>
>> Anyway, my suggestion would be to add IORING_SQ_CQ_OVERFLOW to the
>> existing flags, and then make a liburing change almost identical to
>> what you had.
> Thanks.
> It's somewhat late today, I'll test and send these two patches tomorrow.

Sounds good, thanks.

-- 
Jens Axboe


  reply	other threads:[~2020-07-07 17:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-07 13:24 [PATCH] io_uring: export cq overflow status to userspace Xiaoguang Wang
2020-07-07 14:28 ` Jens Axboe
2020-07-07 16:21   ` Jens Axboe
2020-07-07 16:25     ` Pavel Begunkov
2020-07-07 16:30       ` Jens Axboe
2020-07-07 16:36     ` Xiaoguang Wang
2020-07-07 17:23       ` Jens Axboe [this message]
2020-07-08  3:25     ` Xiaoguang Wang
2020-07-08  3:46       ` Jens Axboe
2020-07-08  5:29         ` Xiaoguang Wang
2020-07-08 15:29           ` Jens Axboe
2020-07-08 15:39             ` Xiaoguang Wang
2020-07-08 15:41               ` Jens Axboe
2020-07-08 16:51                 ` Xiaoguang Wang
2020-07-08 21:33                   ` Jens Axboe
2020-07-09  0:52                     ` Xiaoguang Wang
2020-07-07 16:29   ` Xiaoguang Wang
2020-07-07 16:30     ` 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