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

[Brett A C Sheffield <bacs@librecast.net>]

On 2026-07-06 17:33, Simon Schippers wrote:
> 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.

I didn't mean to suggest 150x slower. It would have been more correct if I'd
simply said "the test normally takes <2s but fails to complete with the
patchset". The 5min timeout was irrelevant detail.

The iperf3 tests give a much better picture of the performance impact.

I thought a simple TCP test with a familar tool might be easier than explaining
the ways in which we're torturing multicast ;-)

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

The test synchronizes two blobs of data. The amount of data that needs syncing
is fixed, but the amount sent will vary as it is encoded with RaptorQ.

The test sends on several multicast groups simultaneously. Each group is a
stream of RaptorQ encoded symbols and the receiver listens on that group until
is has enough symbols to decode. In practice, on a local tap interface, the
packet loss is normally zero, so the amount of data sent is more or less fixed.



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