From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] #17
Date: Mon, 13 Apr 2015 02:15:01 +0200 [thread overview]
Message-ID: <DDF1BCFA-17DA-441A-B0E1-96F92549EC10@gmx.de> (raw)
In-Reply-To: <68E872EE-C0D3-4091-97C9-19596BF98AEB@gmail.com>
Hi Jonathan,
On Apr 13, 2015, at 01:55 , Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 13 Apr, 2015, at 02:50, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> As mentioned above, as long as cake can work with tc’s stab option all framing and overhead handling should be available to whoever needs it.
>
> Remind me to look into how to use that, then.
basically you add:
stab mtu 2047 tsize 512 mpu 0 overhead 40 linklayer atm
to the top level qdisc invocation, it fudges the size variable in the SKB? just as the kernels internal accounting for the ethernet header does, and all qdisc will see the fudged value, this is unlike HTB private implementation of basically the same (TB’s version has some advantages with GRO though).
e.g.:
$TC qdisc add dev $DEV root handle 1: stab mtu 2047 tsize 512 mpu 0 overhead 40 linklayer atm htb default 12
Note: mtu in the stab context only defines the upper bound for which the size table gets created (this is the limit up to which stab works reliable), tsize gives the number of entries in the table, for ATM all increases are at multiples of 16, so 2048/512 = 4bits is enough, and mpu allows to specify a minimum packet size. All in all stab gives more freedom than strictly needed for atm ,link layer accounting...
> If there’s a better way than manually calculating ceil(len/48)*53, so much the better.
Well, “stab” is so much better than statically accounting for the ~9% ATM cell overhead tax that it is just not funny anymore. Due to the AAL5’s? weird idea that each payload package has to fill an integer number of ATM cells, small packets can get an obscene amount of additional overhead: worst case is something like 1 ATM cell with of data + 1 byte, which will drag in another ATM cell with 47 bytes padding… increasing the overhead by 100% on top of the 9% cell tax and the normal per packet overhead gunk ISPs force unto the unlucky ATM users…
Best Regards
Sebastian
>
> - Jonathan Morton
>
next prev parent reply other threads:[~2015-04-13 0:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-12 19:18 Sebastian Moeller
2015-04-12 21:59 ` Dave Taht
2015-04-12 23:50 ` Sebastian Moeller
2015-04-12 23:55 ` Jonathan Morton
2015-04-13 0:15 ` Sebastian Moeller [this message]
2015-04-13 0:23 ` Sebastian Moeller
2015-04-13 0:45 ` Jonathan Morton
2015-04-13 6:51 ` Sebastian Moeller
2015-04-13 14:45 ` Sebastian Moeller
2015-04-14 10:13 ` Jonathan Morton
2015-04-14 10:34 ` Sebastian Moeller
2015-04-13 14:59 ` Sebastian Moeller
2015-04-13 17:06 ` Jonathan Morton
2015-04-13 19:45 ` Sebastian Moeller
2015-04-13 20:08 ` Jonathan Morton
2015-04-13 20:10 ` Sebastian Moeller
2015-04-14 0:58 ` Jonathan Morton
2015-04-14 1:24 ` Dave Taht
2015-04-14 7:03 ` Sebastian Moeller
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=DDF1BCFA-17DA-441A-B0E1-96F92549EC10@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
/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