From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org
Cc: cake@lists.bufferbloat.net, Dave Taht <dave.taht@gmail.com>
Subject: Re: [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
Date: Wed, 25 Apr 2018 17:22:29 +0200 [thread overview]
Message-ID: <878t9b5n0q.fsf@toke.dk> (raw)
In-Reply-To: <e27a6618-3a68-fa60-53a0-109b4df70482@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 04/25/2018 06:42 AM, Toke Høiland-Jørgensen 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.
>>
>
> * 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 size.
>
> 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-40g-2 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 18840.40
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 24804.77
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
next prev parent reply other threads:[~2018-04-25 15:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 13:42 [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc Toke Høiland-Jørgensen
2018-04-25 13:42 ` [PATCH ipruote2-next v4] Add support for cake qdisc Toke Høiland-Jørgensen
2018-04-25 14:52 ` [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc Eric Dumazet
2018-04-25 15:22 ` Toke Høiland-Jørgensen [this message]
2018-04-25 15:48 ` Eric Dumazet
2018-04-25 15:51 ` Eric Dumazet
2018-04-25 16:06 ` Toke Høiland-Jørgensen
2018-04-25 16:29 ` Eric Dumazet
2018-04-25 16:52 ` [Cake] " Jonathan Morton
2018-04-25 16:57 ` Eric Dumazet
2018-04-25 18:34 ` Toke Høiland-Jørgensen
2018-04-25 18:48 ` David Miller
2018-04-25 19:02 ` Eric Dumazet
2018-04-25 19:15 ` Toke Høiland-Jørgensen
2018-04-25 17:54 ` Sebastian Moeller
2018-04-25 16:55 ` Toke Høiland-Jørgensen
2018-04-25 16:59 ` Eric Dumazet
2018-04-25 16:00 ` Eric Dumazet
2018-04-25 16:17 ` Toke Høiland-Jørgensen
2018-04-25 17:43 ` Eric Dumazet
2018-04-25 18:35 ` Toke Høiland-Jørgensen
2018-04-25 18:39 ` David Miller
2018-04-25 18:46 ` Toke Høiland-Jørgensen
2018-04-27 10:54 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878t9b5n0q.fsf@toke.dk \
--to=toke@toke.dk \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.