From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EE25A3B29E for ; Thu, 17 May 2018 07:23:18 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1526556198; bh=myuHbMd0AqCO1cAGxQ2hlAFg6YK/fceltPSCGfEhWPo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JYS/85Mgvgnnf0RkFEVWM+n9yDrPv/uCwlyRSyVjIMLDbWq1jF58aWhjSBV4Is5h9 jE0aaekkMe6X3l6C1cj+K7QlgekyKezPGylihDCu/h0B+9LnfefJh1RNKjwK5006on 1UQtjexnX8Tl/x6xnEJUBQlI+l5j+68/0vPo9J11lTxLgCka0jypiAkCeBbjxf8DSD GhtV/aNdh8ebuUdxY5N3e7pr9KV3yiVrTa5nLtqd8E3TjCg2pU7JxMlIh1Cl6iZKuM IH41Xw5ju42Ag9hksl1xsEd+yOb4Pfotwn//tILnuS0Y0JN6aGC6wxQoM5P+jUxVlr nLBA/2idq94/w== To: Eric Dumazet , netdev@vger.kernel.org Cc: cake@lists.bufferbloat.net In-Reply-To: References: <152650253056.25701.10138252969621361651.stgit@alrua-kau> <152650254614.25701.1377066681230937234.stgit@alrua-kau> Date: Thu, 17 May 2018 13:23:17 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in7my196.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 11:23:19 -0000 Eric Dumazet writes: > On 05/16/2018 01:29 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> The ACK filter is an optional feature of CAKE which is designed to impro= ve >> performance on links with very asymmetrical rate limits. On such links >> (which are unfortunately quite prevalent, especially for DSL and cable >> subscribers), the downstream throughput can be limited by the number of >> ACKs capable of being transmitted in the *upstream* direction. >>=20 > > ... > >>=20 >> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen >> --- >> net/sched/sch_cake.c | 260 +++++++++++++++++++++++++++++++++++++++++++= +++++++ >> 1 file changed, 258 insertions(+), 2 deletions(-) >>=20 >> > > I have decided to implement ACK compression in TCP stack itself. Awesome! Will look forward to seeing that! > First step is to take care of SACK, which are the main source of the > bloat, since we send one SACK for every incoming out-of-order packet. > > These SACK are not only causing pain on the network, they also cause > the sender to send one MSS at a time (TSO auto defer is not engaged in > this case), thus starting to fill its RTX queue with pathological skbs > (1-MSS each), increasing processing time. > > I see that your ACK filter does not take care of this common case :) We don't do full parsing of SACKs, no; we were trying to keep things simple... We do detect the presence of SACK options, though, and the presence of SACK options on an ACK will make previous ACKs be considered redundant. > Doing the filtering in TCP has the immense advantage of knowing the > RTT and thus be able to use heuristics causing less damage. Quite so. I'll be quite happy if the CAKE ACK filter can be delegated to something only relevant for the poor sods stuck on proprietary operating systems :) Are you satisfied that the current version of the filter doesn't mangle the skbs or crash the kernel? -Toke