On 1/9/26 07:04, Jason Wang wrote:

On Thu, Jan 8, 2026 at 3:48 PM Simon Schippers
[off-list ref] wrote:

quoted

On 1/8/26 05:38, Jason Wang wrote:

quoted

On Thu, Jan 8, 2026 at 5:06 AM Simon Schippers
[off-list ref] wrote:

quoted

Replace the direct use of ptr_ring in the vhost-net virtqueue with
tun/tap ring wrapper helpers. Instead of storing an rx_ring pointer,
the virtqueue now stores the interface type (IF_TUN, IF_TAP, or IF_NONE)
and dispatches to the corresponding tun/tap helpers for ring
produce, consume, and unconsume operations.

Routing ring operations through the tun/tap helpers enables netdev
queue wakeups, which are required for upcoming netdev queue flow
control support shared by tun/tap and vhost-net.

No functional change is intended beyond switching to the wrapper
helpers.

Co-developed-by: Tim Gebauer <redacted>
Signed-off-by: Tim Gebauer <redacted>
Co-developed by: Jon Kohler [off-list ref]
Signed-off-by: Jon Kohler <redacted>
Signed-off-by: Simon Schippers <redacted>
---
 drivers/vhost/net.c | 92 +++++++++++++++++++++++++++++----------------
 1 file changed, 60 insertions(+), 32 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 7f886d3dba7d..215556f7cd40 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c

@@ -90,6 +90,12 @@ enum {
        VHOST_NET_VQ_MAX = 2,
 };

+enum if_type {
+       IF_NONE = 0,
+       IF_TUN = 1,
+       IF_TAP = 2,
+};

This looks not elegant, can we simply export objects we want to use to
vhost like get_tap_socket()?

No, we cannot do that. We would need access to both the ptr_ring and the
net_device. However, the net_device is protected by an RCU lock.

That is why {tun,tap}_ring_consume_batched() are used:
they take the appropriate locks and handle waking the queue.

How about introducing a callback in the ptr_ring itself, so vhost_net
only need to know about the ptr_ring?

That would be great, but I'm not sure whether this should be the
responsibility of the ptr_ring.

If the ptr_ring were to keep track of the netdev queue, it could handle
all the management itself - stopping the queue when full and waking it
again once space becomes available.

What would be your idea for implementing this?

Thanks

quoted

quoted

Thanks