Thread (10 messages) 10 messages, 3 authors, 5d ago

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

From: Simon Schippers <hidden>
Date: 2026-07-07 06:56:08
Also in: linux-doc, lkml

On 7/6/26 19:10, Brett A C Sheffield wrote:
On 2026-07-06 17:33, Simon Schippers wrote:
quoted
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 ;-)
Yes :D
quoted
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.
Hmm seems like my theory does not really hold up :D


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 :)


BTW: I will try to get hands on a Ryzen 9 9950X soon (I think we have a
     machine at our chair) and then try to reproduce.

Thank you!

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help