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

[Simon Schippers]

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