public inbox for [email protected]
 help / color / mirror / Atom feed
From: Xiaoguang Wang <[email protected]>
To: [email protected]
Cc: Jens Axboe <[email protected]>, Pavel Begunkov <[email protected]>
Subject: questions about io_uring buffer select feature
Date: Thu, 14 Apr 2022 15:51:12 +0800	[thread overview]
Message-ID: <[email protected]> (raw)

hi,

I spent some time to learn the history of buffer select feature, especially
from https://lwn.net/Articles/813311/. According to the description in this
link:
    when doing the same IORING_OP_RECV, no buffer is passed in
    with the request. Instead, it's flagged with IOSQE_BUFFER_SELECT, and
    sqe->buf_group is filled in with a valid group ID. When the kernel can
    satisfy the receive, a buffer is selected from the specified group ID
    pool. If none are available, the IO is terminated with -ENOBUFS. On
    success, the buffer ID is passed back through the (CQE) completion
    event. This tells the application what specific buffer was used.

According to my understandings, buffer select feature is suggested to be
used with fast-poll feature, then in example of io_read(), for the first nowait
try, io_read() will always get one io_buffer even later there is no data
ready, eagain is returned and this req will enter io_arm_poll_handler().
So it seems that this behaviour violates the rule that buffer is only selected
when data is ready?

And for ENOBUFS error, how should apps handle this error? Re-provide
buffers and re-issue requests from user space again? Thanks.


Regards,
Xiaoguang Wang


             reply	other threads:[~2022-04-14  7:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14  7:51 Xiaoguang Wang [this message]
     [not found] <[email protected]>
2022-04-14  8:32 ` questions about io_uring buffer select feature Pavel Begunkov
2022-04-14 11:23   ` Xiaoguang Wang

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 \
    --in-reply-to=34124b41-c17e-ef77-b317-570297123521@linux.alibaba.com \
    [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