Re: [PATCH net v2] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE

[Michael S. Tsirkin]

On Wed, Jul 08, 2026 at 05:12:19PM +0200, Simon Schippers wrote:
> On 7/7/26 22:05, Brett A C Sheffield wrote:
> > On 2026-07-07 08:52, Simon Schippers wrote:
> >> Brett, can you try the two attached patches here with iperf3?
> >> I think testing with 8 and 16 threads is enough, so where there is a
> >> regression.
> >>
> >> The two patches are about time when to wake:
> >> Currently we wake after consuming half the internal ring buffer.
> >> One of the attached patches wakes after 2 cachelines (128 of 1000
> >> packets) and the other one just wakes once the ring buffer is empty.
> >>
> >> This would really help :)
> > 
> > Sure...
> > 
> > 
> 
> The reverted results for reference:
> 7.2.0-rc1 reverted:
> 
> threads 1
> [  5]   0.00-10.00  sec  15.3 GBytes  13.1 Gbits/sec  368            sender
> [  5]   0.00-10.00  sec  2.00 GBytes  1.72 Gbits/sec                  receiver
> 
> threads 2
> [SUM]   0.00-10.00  sec  15.9 GBytes  13.7 Gbits/sec  1567             sender
> [SUM]   0.00-10.00  sec  4.00 GBytes  3.43 Gbits/sec                  receiver
> 
> threads 4
> [SUM]   0.00-10.00  sec  16.5 GBytes  14.1 Gbits/sec  6701             sender
> [SUM]   0.00-10.00  sec  8.00 GBytes  6.87 Gbits/sec                  receiver
> 
> threads 8
> [SUM]   0.00-10.00  sec  16.2 GBytes  14.0 Gbits/sec  19319             sender
> [SUM]   0.00-10.00  sec  15.7 GBytes  13.5 Gbits/sec                  receiver
> 
> threads 16
> [SUM]   0.00-10.00  sec  14.4 GBytes  12.4 Gbits/sec  43593             sender
> [SUM]   0.00-10.00  sec  14.4 GBytes  12.4 Gbits/sec                  receiver
> 
> 
> > 7.2.0-rc2 (unpatched)
> > 
> > threads 1
> > [  5]   0.00-10.00  sec  20.4 GBytes  17.5 Gbits/sec    0            sender
> > [  5]   0.00-10.00  sec  2.00 GBytes  1.72 Gbits/sec                  receiver
> > 
> > threads 2
> > [SUM]   0.00-10.00  sec  12.7 GBytes  10.9 Gbits/sec    0             sender
> > [SUM]   0.00-10.00  sec  4.00 GBytes  3.43 Gbits/sec                  receiver
> > 
> > threads 8
> > [SUM]   0.00-10.00  sec  11.5 GBytes  9.85 Gbits/sec    0             sender
> > [SUM]   0.00-10.01  sec  11.4 GBytes  9.83 Gbits/sec                  receiver
> > 
> > threads 16
> > [SUM]   0.00-10.00  sec  11.6 GBytes  9.95 Gbits/sec    0             sender
> > [SUM]   0.00-10.01  sec  11.5 GBytes  9.91 Gbits/sec                  receiver
> > 
> > 
> > 7.2.0-rc2 with 0001-tun-set-waking-threshold-to-ptr_ring_empty.patch
> > 
> > threads 1
> > [  5]   0.00-10.00  sec  19.6 GBytes  16.8 Gbits/sec    0            sender
> > [  5]   0.00-10.00  sec  2.00 GBytes  1.72 Gbits/sec                  receiver
> > 
> > threads 2
> > [SUM]   0.00-10.00  sec  11.1 GBytes  9.50 Gbits/sec    0             sender
> > [SUM]   0.00-10.00  sec  4.00 GBytes  3.43 Gbits/sec                  receiver
> > 
> > threads 8
> > [SUM]   0.00-10.00  sec  10.8 GBytes  9.25 Gbits/sec    0             sender
> > [SUM]   0.00-10.01  sec  10.7 GBytes  9.23 Gbits/sec                  receiver
> > 
> > threads 16
> > [SUM]   0.00-10.00  sec  10.9 GBytes  9.34 Gbits/sec    0             sender
> > [SUM]   0.00-10.01  sec  10.8 GBytes  9.30 Gbits/sec                  receiver
> > 
> > 
> > 7.2.0-rc2 with 0001-tun-set-waking-threshold-to-tx_ring.batch.patch
> > 
> > threads 1
> > [  5]   0.00-10.00  sec  19.6 GBytes  16.9 Gbits/sec    2            sender
> > [  5]   0.00-10.00  sec  2.00 GBytes  1.72 Gbits/sec                  receiver
> > 
> > threads 2
> > [SUM]   0.00-10.00  sec  13.9 GBytes  11.9 Gbits/sec    0             sender
> > [SUM]   0.00-10.00  sec  4.00 GBytes  3.43 Gbits/sec                  receiver
> > 
> > threads 8
> > [SUM]   0.00-10.00  sec  12.7 GBytes  10.9 Gbits/sec    0             sender
> > [SUM]   0.00-10.01  sec  12.3 GBytes  10.6 Gbits/sec                  receiver
> > 
> > threads 16
> > [SUM]   0.00-10.00  sec  12.5 GBytes  10.7 Gbits/sec    0             sender
> > [SUM]   0.00-10.00  sec  12.4 GBytes  10.7 Gbits/sec                  receiver
> > 
> > 
> > 
> > HTH,
> > 
> > 
> > Brett
> 
> Thank you again!
> 
> These results show that waking earlier performs better in this case:
> For 8 threads we get 10.6 Gbit/s instead of 9.83 Gbit/s when waking early
> but we are still *far* from the 13.5 Gbit/s when we revert everything
> (see above I pasted the reverted results there).
> 
> So I come to the conclusion:
> 
> 1. Waking earlier/later will not fix the performance issues. It may
>    improve the performance slightly.
>    Apart from that we introduce smp_mb__after_atomic() for the re-check
>    on producer side (noop on x86) and a full smp_mb() for the re-check on
>    consumer side.
>    Nothing else stands out to me apart from the overheads of
>    netif_tx_stop_queue() and netif_tx_wake_queue(). But we must use
>    those 2 functions one way or another.
> 
> 2. Users may depend on the dropping. Without backpressure tun/tap acts
>    like a pfifo qdisc which tail-drops. Some users may require this.
> 
> --> I would merge this opt-in patchset, it should be fine (it is not
>     flagged by Sashiko anymore btw). I would not be mad if it would not
>     get merged but I am out of ideas on how to improve.
> 
> Thanks,
> Simon

I am fine with it being opt in, but we IMHO, need to be more clear, for users,
opt in to what this is.

-- 
MST