From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: io-uring@vger.kernel.org, Guang Wu <guazhang@redhat.com>,
ming.lei@redhat.com
Subject: Re: [v6.4 Regression] rust/io_uring: tests::net::test_tcp_recv_multi hangs
Date: Thu, 19 Oct 2023 19:47:10 +0800 [thread overview]
Message-ID: <ZTEXPlB70Eqe3WOJ@fedora> (raw)
In-Reply-To: <aa10bf89-779c-4383-a36c-5615f73dc6a4@kernel.dk>
On Thu, Oct 19, 2023 at 05:31:11AM -0600, Jens Axboe wrote:
> On 10/19/23 2:06 AM, Ming Lei wrote:
> > Hello Jens,
> >
> > Guang Wu found that tests::net::test_tcp_recv_multi in rust:io_uring
> > hangs, and no such issue in RH test kernel.
> >
> > - git clone https://github.com/tokio-rs/io-uring.git
> > - cd io-uring
> > - cargo run --package io-uring-test
> >
> > I figured out that it is made by missing the last CQE with -ENOBUFS,
> > which is caused by commit a2741c58ac67 ("io_uring/net: don't retry recvmsg()
> > unnecessarily").
> >
> > I am not sure if the last CQE should be returned and that depends how normal
> > recv_multi is written, but IORING_CQE_F_MORE in the previous CQE shouldn't be
> > returned at least.
>
> Is this because it depends on this spurious retry? IOW, it adds N
> buffers and triggers N receives, then depends on an internal extra retry
> which would then yield -ENOBUFS? Because that sounds like a broken test.
Yeah, that is basically what the test does.
The test gets two recv CQEs, both have IORING_CQE_F_MORE. And it waits for 3
CQEs, and never return because there isn't the 3rd CQE after
a2741c58ac67 ("io_uring/net: don't retry recvmsg() unnecessarily")
is merged.
> As long as the recv triggers successfully, IORING_CQE_F_MORE will be
> set. Only if it his some terminating condition would it trigger a CQE
> without the MORE flag set. If it remains armed and ready to trigger
> again, it will have MORE set. I'll take a look, this is pure guesswork
> on my side right now.
.B IORING_CQE_F_MORE
If set, the application should expect more completions from the request. This
is used for requests that can generate multiple completions, such as multi-shot
requests, receive, or accept.
I understand that if one CQE is received with IORING_CQE_F_MORE, it is
reasonable for userspace to wait for one extra CQE, is this expectation
correct? Or the documentation needs to be updated?
Thanks,
Ming
next prev parent reply other threads:[~2023-10-19 11:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 8:06 [v6.4 Regression] rust/io_uring: tests::net::test_tcp_recv_multi hangs Ming Lei
2023-10-19 11:31 ` Jens Axboe
2023-10-19 11:47 ` Ming Lei [this message]
2023-10-19 12:10 ` 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 \
--in-reply-to=ZTEXPlB70Eqe3WOJ@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=guazhang@redhat.com \
--cc=io-uring@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.