From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tal Gilboa Subject: Re: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue Date: Wed, 24 Jan 2018 16:42:47 +0200 Message-ID: References: <20171006052127.19913-1-edumazet@google.com> <20171007.003134.133270352885522371.davem@davemloft.net> <0d6ba40c-8c17-5d43-f4a1-359ce65d961f@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Miller , "ncardwell@google.com" , "ycheng@google.com" , "netdev@vger.kernel.org" , "eric.dumazet@gmail.com" , Saeed Mahameed , Tariq Toukan , Amir Ancel To: Eric Dumazet Return-path: Received: from mail-ve1eur01on0073.outbound.protection.outlook.com ([104.47.1.73]:10304 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933688AbeAXOmz (ORCPT ); Wed, 24 Jan 2018 09:42:55 -0500 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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. On 1/22/2018 1:47 AM, Eric Dumazet wrote: > On Sun, Jan 21, 2018 at 12:52 PM, Tal Gilboa wrote: >> 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? >> > > Hi Tal > > You have to provide way more details than a simple mail, asking for a > " revert or a fix " ... > > On our GFEs, we got a win, while I was expecting a small overhead, > given the apparent complexity of dealing with RB tree instead of > linear list. > > And on the stress scenario described in my patch set, the win was > absolutely abysmal. > > A " single strean TCP with 1KB packets" is not something we need to optimize, > unless there is some really strange setup for one of your customers ? > > Here we deal with millions of TCP flows, and this is what we need to > take care of. > > Thanks. > >> Thanks, >> >> Tal G. >> >> >> On 10/7/2017 2:31 AM, David Miller wrote: >>> >>> From: Eric Dumazet >>> 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! >>> >>