Netdev List
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: Jia Jia <physicalmtea@gmail.com>
Cc: netdev@vger.kernel.org, stefanha@redhat.com,
	bobbyeshleman@gmail.com,  mst@redhat.com, jasowangio@gmail.com,
	eperezma@redhat.com,  xuanzhuo@linux.alibaba.com,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	 pabeni@redhat.com, horms@kernel.org, kvm@vger.kernel.org,
	 virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v5 3/5] vsock/virtio: amortize RX socket locking for stream packets
Date: Thu, 5 Nov 2026 09:57:18 +0100	[thread overview]
Message-ID: <auxDWISLHB8Ln1x7@sgarzare-redhat> (raw)
In-Reply-To: <20261103041134.33310-4-physicalmtea@gmail.com>

On Tue, Nov 03, 2026 at 12:11:32PM +0800, Jia Jia wrote:
>The virtio-vsock RX worker looks up a socket and takes its lock for every
>packet. Retain the connected lookup reference and socket lock across a
>bounded run of STREAM/RW packets for one established native socket.
>
>Reuse the locked socket while packets match the same flow. Finish the
>batch on a malformed packet, flow change, non-RW traffic, or a change to
>the socket state, transport, protocol, sockmap state, or receive buffer
>limits. A connected lookup miss falls back to the existing receive path,
>which can still find a bound socket.
>
>Limit an uninterrupted socket-lock ownership interval to 64 packets and
>64 KiB of payload. The payload limit is one
>VIRTIO_VSOCK_MAX_PKT_BUF_SIZE. Small or zero-length packets still incur
>per-packet work, so an independent packet limit is needed. The 64-packet
>limit uses VHOST_NET_BATCH as a reference; it is a policy choice rather
>than a protocol limit.
>
>Beyond these limits, a larger batch would only further amortize socket
>lookup and lock/unlock operations, while virtqueue work, validation,
>tracing, skb ownership, credit update, and queueing remain per-packet. I
>therefore expect diminishing returns while the uninterrupted socket-lock
>interval continues to grow, but I have not measured larger limits yet.
>
>Only the guest virtio RX worker is changed. The benchmark exercises the
>host-sender-to-guest-receiver direction, where this worker is on the
>receive path. I have not measured the corresponding worker and socket-lock
>overhead in vhost-vsock or vsock_loopback, and they use different worker
>and locking models. Leave those paths unchanged pending separate policy
>and validation. I plan to evaluate vhost-vsock separately as follow-up
>work.
>
>Performance:
>
>These results cover P1-P3, before the notification changes in P4 and P5.
>
>Tested on a single-stream vsock connection (one Guest receiver thread on
>CPU0, virtio-vsock IRQ on Guest CPU1, fresh QEMU Guest per state). The host
>uses vhost-vsock.
>
>For throughput, vsock_perf runs on the host as the
>sender, with a custom single-threaded Guest receiver pinned to Guest CPU0
>using blocking recv(). The fixed-64K table uses a 64K buffer; the matched
>table uses the sender's request size. The virtio-vsock IRQ/RX worker is
>pinned to Guest CPU1. To normalize run times across payloads into a
>bounded, deterministic window and avoid long runs being skewed by host
>background noise or virtualization scheduling jitter, transfer sizes scale
>proportionally with the request size (64B/64M, 256B/256M, etc.), capped at
>2G for 4K-64K. The custom receiver keeps the recv() size and count
>explicit; vsock_perf's receiver uses poll()+read().
>
>End-to-end RX throughput (fixed-64K receiver; Gbit/s):
>
>  payload  baseline RX  PATCH RX  throughput change (95% CI)
>           (Gbit/s)      (Gbit/s)
>  64B        0.1285       0.2462    +91.59% [+79.74%, +104.22%]
>  256B       0.5909       0.9666    +63.59% [+61.03%, +66.19%]
>  512B       1.1817       1.8350    +55.29% [+46.76%, +64.32%]
>  1K         2.3252       3.3600    +44.50% [+38.93%, +50.30%]
>  4K         3.8436       5.5661    +44.82% [+40.30%, +49.47%]
>  8K         4.6609       5.4115    +16.10% [ +8.91%, +23.77%]
>  16K        5.1196       5.6399    +10.16% [ +4.07%, +16.61%]
>  64K        5.6095       5.7062     +1.72% [-3.19%, +6.89%]
>
>Fixed-syscall stress test (receiver recv() size = sender write size;
>no perf; Gbit/s):
>
>  payload  baseline RX  PATCH RX  throughput change (95% CI)
>  64B        0.1446       0.2540   +75.71% [+63.67%, +88.62%]
>       recv() calls (baseline/PATCH): 1048577/1048577
>  256B       0.4211       0.9061  +115.18% [+72.13%, +169.00%]
>       recv() calls (baseline/PATCH): 1048577/1048577
>  512B       0.7980       1.6112  +101.90% [+95.30%, +108.72%]
>       recv() calls (baseline/PATCH): 1048577/1048577
>  1K         1.4965       2.6986   +80.33% [+68.93%, +92.49%]
>       recv() calls (baseline/PATCH): 1048577/1048577
>  4K         2.9384       4.8590   +65.36% [+60.17%, +70.72%]
>       recv() calls (baseline/PATCH): 539544/524982
>  8K         3.8170       5.1887   +35.94% [+27.66%, +44.75%]
>       recv() calls (baseline/PATCH): 274857/262991
>  16K        4.6856       5.5996   +19.51% [+15.36%, +23.81%]
>       recv() calls (baseline/PATCH): 147518/131351
>  64K        5.5182       5.8800    +6.56% [-0.83%, +14.49%]
>       recv() calls (baseline/PATCH): 48492/32910
>
>Guest CPU1 aggregate cycles per received byte
>(fixed 64K receiver, with perf):
>
>  Buffer size  baseline cycles/B  PATCH cycles/B  cycles change (95% CI)
>  64B        66.728    61.220  -8.25% [-18.99%, +3.91%]
>  256B       14.363    14.515  +1.06% [ -4.22%, +6.64%]
>  512B        7.792     7.578  -2.74% [ -6.55%, +1.23%]
>  1K          3.988     4.032  +1.09% [ -1.64%, +3.88%]
>  4K          2.063     1.973  -4.38% [ -8.23%, -0.37%]
>  8K          1.702     1.667  -2.06% [ -7.99%, +4.25%]
>  16K         1.473     1.475  +0.17% [ -5.06%, +5.68%]
>  64K         1.385     1.358  -1.96% [-10.61%, +7.53%]
>
>Signed-off-by: Jia Jia <physicalmtea@gmail.com>
>---
> include/linux/virtio_vsock.h            |  23 ++
> net/vmw_vsock/virtio_transport.c        |   7 +-
> net/vmw_vsock/virtio_transport_common.c | 303 ++++++++++++++++++++++--
> 3 files changed, 318 insertions(+), 15 deletions(-)
>
>diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
>index f91704731057e..748633aa0cc81 100644
>--- a/include/linux/virtio_vsock.h
>+++ b/include/linux/virtio_vsock.h
>@@ -282,6 +282,29 @@ void virtio_transport_destruct(struct vsock_sock *vsk);
>
> void virtio_transport_recv_pkt(struct virtio_transport *t,
> 			       struct sk_buff *skb, struct net *net);
>+
>+/*
>+ * Initialize a batch to zero before use. A non-empty batch owns @sk's socket
>+ * lock and the reference returned by vsock_find_connected_socket_net(). The
>+ * caller retains both until it calls virtio_transport_rx_batch_finish(). An
>+ * empty batch owns neither.
>+ */
>+struct virtio_transport_rx_batch {
>+	struct sock *sk;
>+	unsigned int pkts;
>+	size_t bytes;
>+};
>+
>+static inline bool
>+virtio_transport_rx_batch_empty(const struct virtio_transport_rx_batch *batch)
>+{
>+	return !batch->sk;
>+}
>+
>+void virtio_transport_recv_pkt_batch(struct virtio_transport *t,
>+				     struct sk_buff *skb, struct net *net,
>+				     struct virtio_transport_rx_batch *batch);
>+void virtio_transport_rx_batch_finish(struct virtio_transport_rx_batch *batch);
> void virtio_transport_inc_tx_pkt(struct virtio_vsock_sock *vvs, struct sk_buff *skb);
> u32 virtio_transport_get_credit(struct virtio_vsock_sock *vvs, u32 wanted);
> void virtio_transport_put_credit(struct virtio_vsock_sock *vvs, u32 credit);
>diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
>index 4f9aa9c4c3aa5..9af85712bd387 100644
>--- a/net/vmw_vsock/virtio_transport.c
>+++ b/net/vmw_vsock/virtio_transport.c
>@@ -631,6 +631,7 @@ virtio_transport_seqpacket_allow(struct vsock_sock *vsk, u32 remote_cid)
>
> static void virtio_transport_rx_work(struct work_struct *work)
> {
> 	struct virtio_vsock *vsock =
> 		container_of(work, struct virtio_vsock, rx_work);
>+	struct virtio_transport_rx_batch batch = {};
> 	struct virtqueue *vq;
>@@ -666,6 +667,7 @@ static void virtio_transport_rx_work(struct work_struct *work)
> 			/* Drop short/long packets */
> 			if (unlikely(len < sizeof(*hdr) ||
> 				     len > virtio_vsock_skb_len(skb))) {
>+				virtio_transport_rx_batch_finish(&batch);
> 				kfree_skb(skb);
> 				continue;
> 			}
>@@ -673,6 +675,7 @@ static void virtio_transport_rx_work(struct work_struct *work)
> 			hdr = virtio_vsock_hdr(skb);
> 			payload_len = le32_to_cpu(hdr->len);
> 			if (unlikely(payload_len > len - sizeof(*hdr))) {
>+				virtio_transport_rx_batch_finish(&batch);
> 				kfree_skb(skb);
> 				continue;
> 			}
>@@ -685,11 +688,13 @@ static void virtio_transport_rx_work(struct work_struct *work)
> 			/* Force virtio-transport into global mode since it
> 			 * does not yet support local-mode namespacing.
> 			 */
>-			virtio_transport_recv_pkt(&virtio_transport, skb, NULL);
>+			virtio_transport_recv_pkt_batch(&virtio_transport, skb,
>+							NULL, &batch);
> 		}
> 	} while (!virtqueue_enable_cb(vq));
>
> out:
>+	virtio_transport_rx_batch_finish(&batch);
> 	if (vsock->rx_buf_nr < vsock->rx_buf_max_nr / 2)
> 		virtio_vsock_rx_fill(vsock);
> out_nofill:
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index 2a9cfed085515..f83e5b2edce35 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -33,6 +33,15 @@
> #define MAX_COLLAPSE_LEN \
> 	SKB_MAX_ORDER(VIRTIO_VSOCK_SKB_HEADROOM, PAGE_ALLOC_COSTLY_ORDER)
>
>+/*
>+ * Bound the interval that an RX worker owns a socket lock. One maximum packet
>+ * buffer (64 KiB) bounds payload in one uninterrupted ownership interval.
>+ * Small and zero-length packets need a packet limit to bound per-packet work;
>+ * the 64-packet policy uses VHOST_NET_BATCH as a reference.
>+ */
>+#define VIRTIO_TRANSPORT_RX_BATCH_MAX_PKTS	64
>+#define VIRTIO_TRANSPORT_RX_BATCH_MAX_BYTES	VIRTIO_VSOCK_MAX_PKT_BUF_SIZE
>+
> static void virtio_transport_cancel_close_work(struct vsock_sock *vsk,
> 					       bool cancel_timeout);
> static s64 virtio_transport_has_space(struct virtio_vsock_sock *vvs);
>@@ -1793,13 +1802,94 @@ virtio_transport_find_socket(struct sockaddr_vm *src,
> 	return sk;
> }
>
>+static void
>+virtio_transport_trace_recv_pkt(const struct virtio_vsock_hdr *hdr,
>+				const struct sockaddr_vm *src,
>+				const struct sockaddr_vm *dst)
>+{
>+	trace_virtio_transport_recv_pkt(src->svm_cid, src->svm_port,
>+					dst->svm_cid, dst->svm_port,
>+					le32_to_cpu(hdr->len),
>+					le16_to_cpu(hdr->type),
>+					le16_to_cpu(hdr->op),
>+					le32_to_cpu(hdr->flags),
>+					le32_to_cpu(hdr->buf_alloc),
>+					le32_to_cpu(hdr->fwd_cnt));
>+}
>+
>+static bool
>+virtio_transport_recv_pkt_set_owner(struct sk_buff *skb, struct sock *sk)
>+{
>+	if (skb_set_owner_sk_safe(skb, sk))
>+		return true;
>+
>+	WARN_ONCE(1, "receiving vsock socket has sk_refcnt == 0\n");
>+	return false;
>+}
>+
>+static bool
>+virtio_transport_sock_has_psock(const struct sock *sk)
>+{
>+	return (uintptr_t)rcu_access_pointer(__sk_user_data(sk)) &
>+	       SK_USER_DATA_PSOCK;
>+}
>+
>+/* The caller holds sk's socket lock. */
>+static bool
>+virtio_transport_rx_batch_can_continue(struct virtio_transport *t,
>+				       struct sock *sk, u32 len)
>+{
>+	struct virtio_vsock_sock *vvs;
>+	struct vsock_sock *vsk;
>+
>+	vsk = vsock_sk(sk);
>+	vvs = vsk->trans;
>+
>+	/*
>+	 * Keep a connected lookup reference only for the native, established
>+	 * STREAM path. Sockets outside ESTABLISHED can change table membership;
>+	 * a completed or reassigned socket must resume the per-packet path.
>+	 */
>+	if (sk->sk_state != TCP_ESTABLISHED ||
>+	    sk->sk_type != SOCK_STREAM ||
>+	    sock_flag(sk, SOCK_DONE) ||
>+	    vsk->transport != &t->transport || !vvs)
>+		return false;
>+
>+	/*
>+	 * Do not admit a packet that would hit an existing RX limit while the
>+	 * worker owns the socket lock. The caller holds that lock, so no reader can
>+	 * dequeue until the batch is released.
>+	 */
>+	return (u64)vvs->buf_used + len <= vvs->buf_alloc &&
>+	       !virtio_transport_rx_buf_full(vvs);

I don't understand this. We recently introduce the collapse, so when we 
will call virtio_transport_recv_enqueue(), all the queue will be 
collapsed, including packets in the batch.

Or am I missing something?

Thanks,
Stefano


  parent reply	other threads:[~2026-11-05  8:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03  4:11 [PATCH net-next v5 0/5] vsock/virtio: reduce RX per-packet socket overhead Jia Jia
2026-11-03  4:11 ` [PATCH net-next v5 1/5] vsock/virtio: split socket lookup from locked RX processing Jia Jia
2026-11-05  9:04   ` Stefano Garzarella
2026-11-03  4:11 ` [PATCH net-next v5 2/5] vsock/virtio: factor RX skb metadata budget check Jia Jia
2026-11-05  9:06   ` Stefano Garzarella
2026-11-03  4:11 ` [PATCH net-next v5 3/5] vsock/virtio: amortize RX socket locking for stream packets Jia Jia
2026-11-04 19:26   ` Bobby Eshleman
2026-11-05  8:16     ` Jia Jia
2026-11-05  8:57   ` Stefano Garzarella [this message]
2026-11-03  4:11 ` [PATCH net-next v5 4/5] vsock/virtio: coalesce native RX write-space notifications Jia Jia
2026-11-05  9:21   ` Stefano Garzarella
2026-11-03  4:11 ` [PATCH net-next v5 5/5] vsock/virtio: defer native RX readiness notifications until batch unlock Jia Jia
2026-11-05  9:38   ` Stefano Garzarella
  -- strict thread matches above, loose matches on Subject: below --
2026-10-23  7:51 [PATCH net-next v5 0/5] vsock/virtio: reduce RX per-packet socket overhead Jia Jia
2026-10-23  7:51 ` [PATCH net-next v5 3/5] vsock/virtio: amortize RX socket locking for stream packets Jia Jia

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=auxDWISLHB8Ln1x7@sgarzare-redhat \
    --to=sgarzare@redhat.com \
    --cc=bobbyeshleman@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=horms@kernel.org \
    --cc=jasowangio@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=physicalmtea@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /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