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:

quoted

On 2026-07-06 11:42, Simon Schippers wrote:

quoted

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 <redacted>

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/ (local)

quoted

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