linux-kernel - [PATCH net-next v4 0/4] TUN/TAP & vhost_net: netdev queue flow control to avoid ptr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e7a2e703-f618-48c0-8de2-637c178207f4@tu-dortmund.de>
Date: Wed, 3 Sep 2025 20:55:24 +0200
From: Simon Schippers <simon.schippers@...dortmund.de>
To: Jason Wang <jasowang@...hat.com>
Cc: willemdebruijn.kernel@...il.com, mst@...hat.com, eperezma@...hat.com,
        stephen@...workplumber.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
        kvm@...r.kernel.org
Subject: [PATCH net-next v4 0/4] TUN/TAP & vhost_net: netdev queue flow
 control to avoid ptr_ring tail drop

Jason Wang wrote:
> On Tue, Sep 2, 2025 at 4:10 PM Simon Schippers
> <simon.schippers@...dortmund.de> wrote:
>>
>> This patch series deals with TUN/TAP and vhost_net which drop incoming
>> SKBs whenever their internal ptr_ring buffer is full. Instead, with this
>> patch series, the associated netdev queue is stopped before this happens.
>> This allows the connected qdisc to function correctly as reported by [1]
>> and improves application-layer performance, see benchmarks.
>>
>> This patch series includes TUN, TAP, and vhost_net because they share
>> logic. Adjusting only one of them would break the others. Therefore, the
>> patch series is structured as follows:
>> 1. New ptr_ring_spare helper to check if the ptr_ring has spare capacity
>> 2. Netdev queue flow control for TUN: Logic for stopping the queue upon
>> full ptr_ring and waking the queue if ptr_ring has spare capacity
>> 3. Additions for TAP: Similar logic for waking the queue
>> 4. Additions for vhost_net: Calling TUN/TAP methods for waking the queue
>>
>> Benchmarks ([2] & [3]):
>> - TUN: TCP throughput over real-world 120ms RTT OpenVPN connection
>> improved by 36% (117Mbit/s vs 185 Mbit/s)
>> - TAP: TCP throughput to local qemu VM stays the same (2.2Gbit/s), an
>> improvement by factor 2 at emulated 120ms RTT (98Mbit/s vs 198Mbit/s)
>> - TAP+vhost_net: TCP throughput to local qemu VM approx. the same
>> (23.4Gbit/s vs 23.9Gbit/s), same performance at emulated 120ms RTT
>> (200Mbit/s)
>> - TUN/TAP/TAP+vhost_net: Reduction of ptr_ring size to ~10 packets
>> possible without losing performance
>>
>> Possible future work:
>> - Introduction of Byte Queue Limits as suggested by Stephen Hemminger
>> - Adaption of the netdev queue flow control for ipvtap & macvtap
> 
> Could you please run pktgen on TUN as well to see the difference?
> 
> Thanks
>

Yes, I will look into it :)