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 472A93BA8E for ; Wed, 25 Apr 2018 11:22:31 -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=1524669749; bh=BvEMTmyV9/EbKAAaFg7tpc87SUfuonuJlv0VuBXZ8vE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NwS2w4A1gSdGkoVTORCaszIuRmsvpsZxIlQTW21lyDd/RV6ROc6RknYxQGcbwNAip cLb5rW5zRG9dxh/wi0Dsidw45NzdeHsyTYFoYpWzt+6uJkxFafi1AwXM3gbpmz/xq4 zmQDOS/tuEeCtVAHSXG0ty5ysGNJ6PJFdqtjQDg99jx2rX4AnMqNGqjeAJu6zYCnBq T6pGplzy5+4Q70zGqthOz9GjuV18w0H25saojBY5XgdYVFmPIiTCgOy0zO5sa7h2C8 x8bI/DyR9L6lJkTB6lG5+3h5cONrjygndngDgAHEjMAOKSEGyRHvvQQcg37da9Z3XJ oFAe5630vGz1w== To: Eric Dumazet , netdev@vger.kernel.org Cc: cake@lists.bufferbloat.net, Dave Taht In-Reply-To: References: <20180425134249.21300-1-toke@toke.dk> Date: Wed, 25 Apr 2018 17:22:29 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878t9b5n0q.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 v3] Add Common Applications Kept Enhanced (cake) qdisc 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: Wed, 25 Apr 2018 15:22:31 -0000 Eric Dumazet writes: > On 04/25/2018 06:42 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> sch_cake targets the home router use case and is intended to squeeze the >> most bandwidth and latency out of even the slowest ISP links and routers, >> while presenting an API simple enough that even an ISP can configure it. >>=20 > > * Support for ack filtering. > > Oh my god. Cake became a monster. Haha, you either die a hero or live long enough to see yourself become the villain, I guess? ;) We do realise there are lots of good reasons not to do ACK filtering; but it does make a difference on highly asymmetrical links (see http://blog.cerowrt.org/post/ack_filtering/), which sadly some people are still behind. > syzkaller will be very happy to trigger all kind of bugs in it. Heh, right. > Lack of any pskb_may_pull() is really concerning. By this you mean "check that the packet is long enough to contain the header we are looking for before trying to do ACK filtering", right? > How ack filter deals with reorders ? I think this will do the right thing? /* new ack sequence must be greater */ if (thisconn && (ntohl(tcph_check->ack_seq) > ntohl(tcph->ack_seq))) continue; > Also the forced GSO segmentation looks wrong to me. Wrong as in it's done wrong, or wrong as in you object to the whole concept? > This kills xmit_more gain we have when GSO is performed after > qdisc dequeue before hitting device. > > This should be driven by a parameter really, some threshold on the skb si= ze. > > What performance number do you get on a 10Gbit NIC for example ? Single-flow throughput through 2 hops on a 40Gbit connection (with CAKE in unlimited mode vs pfifo_fast on the router): MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-4= 0g-2 () port 0 AF_INET : demo Recv Send Send=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 Socket Socket Message Elapsed=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Size Size Size Time Throughput=20=20 bytes bytes bytes secs. 10^6bits/sec=20=20 87380 16384 16384 10.00 18840.40=20=20=20 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-4= 0g-2 () port 0 AF_INET : demo Recv Send Send=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 Socket Socket Message Elapsed=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Size Size Size Time Throughput=20=20 bytes bytes bytes secs. 10^6bits/sec=20=20 87380 16384 16384 10.00 24804.77=20=20=20 Note, however, that CAKE is explicitly targeted at home gateways, which generally run at speed a few orders of magnitude slower than this, and we have heavily optimised for lowest possible latency. So this is a conscious design choice, I guess you could say. > Also, how ack filter can suppress packets after skb_gso_segment() ? Hmm, because pure ACKs are not generally aggregated (sorry, I'm not quite clear on when exactly GSO will kick in)? -Toke