From: David Carlier <devnexen@gmail.com>
To: netdev@vger.kernel.org
Cc: sgarzare@redhat.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
David Carlier <devnexen@gmail.com>
Subject: [PATCH net-next 0/2] vsock: receive queue hint for io_uring
Date: Sun, 20 Sep 2026 20:47:08 +0100 [thread overview]
Message-ID: <20260920194710.1114748-1-devnexen@gmail.com> (raw)
AF_VSOCK stream receives never fill msghdr.msg_inq. io_uring initialises the
hint to -1 and treats that as "unknown", so it cannot set
IORING_CQE_F_SOCK_NONEMPTY, and it speculatively retries a multishot receive
after every completion, including when the queue is already empty.
Patch 1 fills the hint at the common exit of __vsock_connectible_recvmsg(),
reusing vsock_stream_has_data(), the transport callback that SIOCINQ already
uses. Following tcp_inq_hint(), it reports a terminal hint of 1 once the
connection is finished, so the caller still performs the receive that
observes EOF. Patch 2 adds selftest coverage.
Numbers come from a ping-pong over vsock loopback using io_uring multishot
receive, 4 KiB messages, the queue drained between messages, with kernel
receives counted by a kprobe. The baseline is the same tree with patch 1
reverted:
entries per delivered message 1.97 -> 1.00 (5000 messages)
receiver CPU time, median 1.640s -> 1.587s (-3.2%)
receiver wall time, median 3.260s -> 3.183s (-2.4%)
Timing is 25 runs of 50000 messages per kernel; CPU gives Mann-Whitney
p=0.006, wall time does not separate from noise (p=0.12), as expected for a
latency-bound workload.
The hint is gated to SOCK_STREAM; seqpacket is untouched. SO_INQ and SCM_INQ
are deliberately left out: they need their own per-socket state and
ancillary-message semantics, and a byte-count contract would have to account
for transports reporting less than the whole queue. That can follow.
Testing: built and run under virtme-ng on loopback, where the new cases pass
and vsock_test still passes 41 of 41 with a clean dmesg. Other transports
were reviewed but not tested. Hyper-V reports the current packet rather than
the whole queue and can return -EIO; an undercount only understates what is
readable, and a negative result leaves the caller's hint untouched.
David Carlier (2):
vsock: report pending receive data to io_uring
vsock/test: cover receive queue hints
net/vmw_vsock/af_vsock.c | 39 +++
tools/testing/vsock/vsock_uring_test.c | 367 +++++++++++++++++++++++++
2 files changed, 406 insertions(+)
base-commit: cea851523034d83dc61d882b1a6a3ad273480f7b
--
2.55.0
next reply other threads:[~2026-09-20 19:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 19:47 David Carlier [this message]
2026-09-20 19:47 ` [PATCH net-next 1/2] vsock: report pending receive data to io_uring David Carlier
2026-09-21 19:47 ` sashiko-bot
2026-09-22 13:56 ` Stefano Garzarella
2026-09-22 20:31 ` David CARLIER
2026-09-20 19:47 ` [PATCH net-next 2/2] vsock/test: cover receive queue hints David Carlier
2026-09-21 19:47 ` sashiko-bot
2026-09-22 14:49 ` Stefano Garzarella
2026-09-22 17:34 ` Bobby Eshleman
2026-09-22 20:37 ` David CARLIER
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=20260920194710.1114748-1-devnexen@gmail.com \
--to=devnexen@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux.dev \
/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.