From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net-next 2/3] tcp: implement coalescing on backlog queue Date: Thu, 22 Nov 2018 10:16:04 -0800 Message-ID: References: <20181121175240.6075-1-edumazet@google.com> <20181121175240.6075-3-edumazet@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: David Miller , netdev , Jean-Louis Dupond , Yuchung Cheng , Eric Dumazet To: Neal Cardwell Return-path: Received: from mail-io1-f67.google.com ([209.85.166.67]:37422 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727787AbeKWE4r (ORCPT ); Thu, 22 Nov 2018 23:56:47 -0500 Received: by mail-io1-f67.google.com with SMTP id a3so7175070ioc.4 for ; Thu, 22 Nov 2018 10:16:16 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 22, 2018 at 10:01 AM Neal Cardwell wrote: > > On Wed, Nov 21, 2018 at 12:52 PM Eric Dumazet wrote: > > > > In case GRO is not as efficient as it should be or disabled, > > we might have a user thread trapped in __release_sock() while > > softirq handler flood packets up to the point we have to drop. > > > > This patch balances work done from user thread and softirq, > > to give more chances to __release_sock() to complete its work. > > > > This also helps if we receive many ACK packets, since GRO > > does not aggregate them. > > Would this coalesce duplicate incoming ACK packets? Is there a risk > that this would eliminate incoming dupacks needed for fast recovery in > non-SACK connections? Perhaps pure ACKs should only be coalesced if > the ACK field is different? Yes, I was considering properly filtering SACK as a refinement later [1] but you raise a valid point for alien stacks that are not yet using SACK :/ [1] This version of the patch will not aggregate sacks since the memcmp() on tcp options would fail. Neal can you double check if cake_ack_filter() does not have the issue you just mentioned ?