From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH v3 net-next 0/6] tcp: implement SACK compression Date: Fri, 18 May 2018 08:48:28 -0700 Message-ID: <9ef582b7-b148-0ee1-65bd-8a272bb85a4f@gmail.com> References: <20180517214729.186094-1-edumazet@google.com> <20180518.114238.2120564820986009221.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, toke@toke.dk, ncardwell@google.com, ycheng@google.com, soheil@google.com, eric.dumazet@gmail.com To: David Miller , edumazet@google.com Return-path: Received: from mail-pl0-f68.google.com ([209.85.160.68]:39957 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752153AbeERPsa (ORCPT ); Fri, 18 May 2018 11:48:30 -0400 Received: by mail-pl0-f68.google.com with SMTP id t12-v6so4806064plo.7 for ; Fri, 18 May 2018 08:48:30 -0700 (PDT) In-Reply-To: <20180518.114238.2120564820986009221.davem@davemloft.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 05/18/2018 08:42 AM, David Miller wrote: > This looks great, series applied, thanks Eric. > > So now we handle locally terminated traffic well, however we still need > something that handles traffic flowing through the system. And for that > reason the CAKE ACK filter still has merit. > > I completely agree with you that it has to be implemented properly, > parse all TCP options and the SACK blocks, and pass the ACKs through > when there are options it doesn't understand or the SACK/timestampe/etc. > update contains new information that must be passed along and not dropper. > > Thanks again. > Be assured I will carefully review Cake ACK filter ;) Thanks David !