summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2026-08-07 17:29:17 -0700
committerJakub Kicinski <kuba@kernel.org>2026-08-07 17:29:18 -0700
commitd6f97dd88be8cf655f5074e08edd7964122317bd (patch)
treeaff54156bc4c5510ebbcb7fdb5911cf400269248 /tools/perf/scripts/python/bin/stackcollapse-report
parentd4e359b3608a0e184bbe8d61a5c3b50d0831c44a (diff)
parentd00c7369ef24ac8e0383de0fd8ef3384de20bcfa (diff)
Merge branch 'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops'
Simon Schippers says: ==================== tun/tap & vhost-net: apply qdisc backpressure on full ptr_ring to reduce TX drops This patch series deals with tun/tap & 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, but only when the new IFF_BACKPRESSURE flag is set and a qdisc is attached. Without the flag, or if no qdisc is present, the existing behavior is preserved. The XDP transmit path is not affected. This patch series touches tun/tap and vhost-net, as they share common logic and must be updated together. Modifying only one of them would break the other. By applying proper backpressure, this change allows the connected qdisc to operate correctly, as reported in [1], and significantly improves performance in real-world scenarios, as demonstrated in our paper [2]. For example, we observed a 36% TCP throughput improvement for an OpenVPN connection between Germany and the USA. The previous version of this work was applied and then reverted in 7.2, because the backpressure was unconditional: it caused a significant throughput drop in an IPv6 multicast testcase with multiple iperf3 TCP threads sending on Brett Sheffield's librecast testbed [3]. This version therefore makes the behavior opt-in via IFF_BACKPRESSURE from the very first patch, so that a tun/tap device which does not set the flag behaves exactly as before. The series is ordered so that no patch changes how packets are handled unless the flag is set: - Patch 1 adds the flag only. It has no effect yet: TUNSETIFF silently masks it off, as it does for any flag outside TUN_FEATURES, until patch 5 adds it there. - Patches 2 and 3 add the consumer side, which wakes a stopped netdev queue. __tun_wake_queue() returns early unless IFF_BACKPRESSURE is set, and no queue is stopped at this point anyway. - Patch 4 is a pure ptr_ring refactor required by patch 5. - Patch 5 adds the queue stopping, gated on IFF_BACKPRESSURE, together with the wake needed when the flag is cleared again, and only there is the flag added to TUN_FEATURES. That way no intermediate commit changes the behavior of an existing tun/tap user beyond the added checks, and bisecting inside the series can not hit the regression that led to the revert. [1] https://unix.stackexchange.com/questions/762935/traffic-shaping-ineffective-on-tun-device [2] https://cni.etit.tu-dortmund.de/storages/cni-etit/r/Research/Publications/2025/Gebauer_2025_VTCFall/Gebauer_VTCFall2025_AuthorsVersion.pdf [3] https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ ==================== Link: https://patch.msgid.link/20260803183641.96882-1-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions