From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] openwrt build with latest cake and other qdiscs
Date: Thu, 14 May 2015 16:12:06 +0300 [thread overview]
Message-ID: <38FFDA3C-2F67-4831-B316-DF8CC7EF0167@gmail.com> (raw)
In-Reply-To: <FD941860-7D3E-4530-9E3C-2460F8E04A6E@gmx.de>
> On 14 May, 2015, at 13:58, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Peeling is on the agenda; that’ll make sure we are dealing with actual, individual packets when we need to.
>
> I agree, that sounds conceptually much cleaner, but peeling is going to be costlier than pushing the segmentation to the NIC, so bandwidth aficionados will not appreciate unconditional peeling, I would guess.
>
>> Certainly when dealing with cell-framing overhead, we *always* need to know individual packet sizes.
>
> Well that or the sum for an aggregate as long as the sum takes all fancy “celling” into account, all we really need to know to how many bits the data expands on the wire.
Since GRO and GSO are for Ethernet and thus *don’t* take cell-framing overhead into account, I really do have to break them up for that purpose if no other.
But beyond that, it can be conditional. I propose that peeling be done if either:
1) the ATM flag is set, or
2) the aggregate would occupy more than 1ms on the wire (at the shaped rate).
This would imply that pairs of 1500-byte packets would be separated at shaping rates up to 24Mbps, but smaller aggregates of smaller packets could still pass unhindered. Conveniently, 24Mbps is also the ADSL cap, although since that’s the downstream rate, it’s not quite so relevant.
Incidentally, GSO also interferes with my proposed ELR signalling, in a way that it doesn’t with ordinary ECN. ELR needs to consider packets individually in order to apply the correct signalling pattern to them. However, if the NIC did the signalling, that wouldn’t be an objection.
- Jonathan Morton
next prev parent reply other threads:[~2015-05-14 13:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-10 14:02 Alan Jenkins
2015-05-10 17:29 ` Alan Jenkins
2015-05-10 20:37 ` Dave Taht
2015-05-10 20:38 ` Dave Taht
2015-05-11 6:54 ` Sebastian Moeller
2015-05-10 21:46 ` Sebastian Moeller
2015-05-10 22:19 ` Dave Taht
2015-05-11 6:50 ` Sebastian Moeller
2015-05-11 7:01 ` Jonathan Morton
2015-05-13 6:43 ` Jonathan Morton
2015-05-14 9:19 ` Sebastian Moeller
2015-05-14 10:24 ` Jonathan Morton
2015-05-14 10:33 ` Alan Jenkins
2015-05-14 10:42 ` Jonathan Morton
2015-05-14 10:58 ` Sebastian Moeller
2015-05-14 13:12 ` Jonathan Morton [this message]
2015-05-14 14:57 ` Sebastian Moeller
2015-05-14 15:32 ` Jonathan Morton
2015-05-14 18:15 ` Sebastian Moeller
2015-05-14 22:06 ` Jonathan Morton
2015-05-15 2:27 ` Dave Taht
2015-05-15 21:49 ` Jonathan Morton
2015-05-14 9:50 ` Alan Jenkins
2015-05-18 0:49 ` [Cake] More overhead keywords Jonathan Morton
2015-05-18 7:27 ` Sebastian Moeller
2015-05-18 8:13 ` Jonathan Morton
2015-05-18 8:41 ` Sebastian Moeller
2015-05-18 19:41 ` David Lang
2015-05-18 19:57 ` Dave Taht
2015-05-19 10:14 ` Kevin Darbyshire-Bryant
2015-05-23 0:30 ` Dave Taht
2015-05-23 2:27 ` Jonathan Morton
-- strict thread matches above, loose matches on Subject: below --
2015-05-05 8:50 [Cake] openwrt build with latest cake and other qdiscs Dave Taht
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
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38FFDA3C-2F67-4831-B316-DF8CC7EF0167@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox