On 1/24/2018 5:09 PM, Eric Dumazet wrote:
On Wed, 2018-01-24 at 16:42 +0200, Tal Gilboa wrote:
Hi Eric,
My choice of words in my comment was misplaced, and I apologies. It
completely missed the point. I understand, of course, the importance of
optimizing real-life scenarios.
We are currently evaluating this patch and if/how it might affect our
customers. We would also evaluate your suggestion below.
We will contact you if and when we have a real concern.
Thanks.
Sure, I am curious how a 50% regression can be possible as a matter of
fact, so please update even if this caused by some specific synthetic
test conditions.
Thanks.
Sorry for the delay in the response. I ran super_netperf for 64B, 128B,
256B and 512B and 500, 1000, 2000 and 4000 streams and compared these
(consecutive) commits:
Base - f331981 tcp: pass previous skb to tcp_shifted_skb()
rb_tree - 75c119a tcp: implement rb-tree based retransmit queue
I got lower BW with rb-tree for all cases.
Example - 2000 streams results (in Gb/s):
size | Base | rb-tree | degradation
64 | 25.6 | 23.3 | -9%
128 | 52.8 | 44.43 | -16%
256 | 89.8 | 66.1 | -26.5%
512 | 87.7 | 67.8 | -22.7%
I'm currently working on improving our CPU utilization in TX flow (by
better utilizing payload aggregation mechanisms). It somewhat improves
the rb-tree results when applied on top of it, but not for all cases and
not to the "base" results.
