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

[Simon Schippers <simon.schippers@tu-dortmund.de>]

On 7/6/26 15:23, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2026 at 12:11:15PM +0200, Brett A C Sheffield wrote:
>> On 2026-07-06 11:42, Simon Schippers wrote:
>>> Commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop
>>> when a qdisc is present") did not show a relevant performance regression
>>> in my testing but on Brett Sheffield's librecast testbed it shows a
>>> significant performance drop in a IPv6 multicast testcase. The regression
>>> can be pinpointed when multiple iperf3 UDP threads are sending. For 8
>>> threads the performance dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is
>>> the reason why this patch makes the qdisc backpressure behavior opt-in.
>>
>> Your v1 commit message was correct.  The iperf3 tests were TCP, not UDP.
>>
>> The original failing test that alerted me to the problem was IPv6 multicast
>> (UDP), but the reproducer tests I provided stats for in the regression report
>> were TCP "To eliminate my code and any multicast weirdness" and also to verify
>> that this also affected TCP.
>>
>> Sorry for the confusion. The command lines used are in the regression report.
>>
>> I've tested the v2 patch (with IPv6 multicast), and verified the
>> previously failing test passes.
>>
>> Tested-by: Brett A C Sheffield <bacs@librecast.net>
>>
>> Cheers,
> 
> 
> Just to clarify, it's more of a work-around, not a fix.
> 
> It's not really great to have a flag that says "change something
> opaque in the internals of the device, it affects performance
> in some way, we can't predict how".

Yes, I agree, but in the end I am just using netif_tx_stop_queue() and
netif_tx_wake_queue()...

> 
> So maybe we really should revert for now, and work on something
> more coherent for the next linux.

But even if we could perfectly fix the performance issues, maybe users
even users rely on the dropping behavior. From Brett [1]:

"In our multicast use case data is sent by multiple threads to multiple
groups simultaneously, this just breaks things to the extent that a 
<2 second test times out after 5 minutes."

We are *not* factor 5min * 60sec/min / 2s = 150 times slower than without
the patchset. My theory is that the sender sends a fixed amount of data
of which most is dropped without backpressure, which is much faster then
the real processing, and so the test *relies* on the tail-dropping to
work.

@Brett can you maybe support this theory?

Thank you both very much! :)

[1] Link: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/

> 
> 
>>
>> Brett
>> -- 
>> Brett Sheffield (he/him)
>> Librecast - Decentralising the Internet with Multicast
>> https://librecast.net/
>> https://blog.brettsheffield.com/
>