netdev - Re: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iK6CMAefxZDZ4eD1DJbtr-NUHfRhCsbtz02TsMgipnd=A@mail.gmail.com>
Date:   Tue, 6 Feb 2018 06:19:58 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Tal Gilboa <talgi@...lanox.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        David Miller <davem@...emloft.net>,
        "ncardwell@...gle.com" <ncardwell@...gle.com>,
        "ycheng@...gle.com" <ycheng@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Amir Ancel <amira@...lanox.com>
Subject: Re: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

On Tue, Feb 6, 2018 at 5:51 AM, Tal Gilboa <talgi@...lanox.com> wrote:
> 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.


Hi

Please give exact details.
Sending 64, 128, 256 or 512 bytes at a time on TCP_STREAM makes little sense.
We are not optimizing stack for pathological cases, sorry.

If you are using MSG_EOR to force silly skbs in the rtx queue, then
you should not do that ...

Thanks.