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: <0d6ba40c-8c17-5d43-f4a1-359ce65d961f@mellanox.com>
Date:   Sun, 21 Jan 2018 22:52:56 +0200
From:   Tal Gilboa <talgi@...lanox.com>
To:     David Miller <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>
Cc:     "ncardwell@...gle.com" <ncardwell@...gle.com>,
        "ycheng@...gle.com" <ycheng@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "eric.dumazet@...il.com" <eric.dumazet@...il.com>,
        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

Hi Eric,
We have noticed a degradation on both of our drivers (mlx4 and mlx5) 
when running TCP. Exact scenario is single stream TCP with 1KB packets. 
The degradation is a steady 50% drop.
We tracked the offending commit to be:
75c119a ("tcp: implement rb-tree based retransmit queue")

Since mlx4 and mlx5 code base is completely different and by looking at 
the changes in this commit, we believe the issue is external to the 
mlx4/5 drivers.

I see in the comment below you anticipated some overhead, but this may 
be a too common case to ignore.

Can you please review and consider reverting/fixing it?

Thanks,

Tal G.

On 10/7/2017 2:31 AM, David Miller wrote:
> From: Eric Dumazet <edumazet@...gle.com>
> Date: Thu,  5 Oct 2017 22:21:20 -0700
> 
>> This patch series implement RB-tree based retransmit queue for TCP,
>> to better match modern BDP.
> 
> Indeed, there was a lot of resistence to this due to the overhead
> for small retransmit queue sizes, but with today's scale this is
> long overdue.
> 
> So, series applied, nice work!
> 
> Maybe we can look into dynamic schemes where when the queue never
> goes over N entries we elide the rbtree and use a list.  I'm not
> so sure how practical that would be.
> 
> Thanks!
>