From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Sebastian Gottschall <s.gottschall@newmedia-net.de>,
Dave Taht <dave.taht@gmail.com>
Cc: "cake\@lists.bufferbloat.net \>\> Cake List"
<cake@lists.bufferbloat.net>
Subject: Re: [Cake] cake in dd-wrt
Date: Tue, 20 Aug 2019 20:31:47 +0200 [thread overview]
Message-ID: <87r25fsn70.fsf@toke.dk> (raw)
In-Reply-To: <74bccc2b-b805-255f-b6a7-83ade9af6765@newmedia-net.de>
Sebastian Gottschall <s.gottschall@newmedia-net.de> writes:
>>> we are already using filters. yes. its just that cake is acting always
>>> as root and we have different sorts of qos configurations. so you have
>>> wan. but we may have multiple lan interfaces with individual qos
>>> settings. the same for mac / ip based user settings. so in fact we need
>>> to create a individual qdisc for each of these setting types in worst
>>> case, but in that case we cannot take in account the global available
>>> bandwidth anymore.
>> Ah, right, I see. So this is things like users wanting to limit a
>> specific type of traffic to a certain bandwidth?
> basicly yes. there are multiple ways. plain traffic shaping by local
> interface name, by local mac, by local ip/net
> and in addition there is shaping by port based or dpi based packet
> detection and since each instance of cake doesnt know of any other
> use of cake qdiscs its getting complicated. but we just started with
> working on it. i'm sure i find a solution for it
Do let us know if you do :)
However, I'd also point out that when running CAKE a lot of these kinds
of setups become simply redundant. For home networks most of the setups
I have seen with such rule-based shaping is simply there to paper over
the underlying bufferbloat issue. Once you solve that you don't really
need all the policy-based stuff.
Now, there are of course exceptions to this where a strict rule-based
shaping *is* really needed; but HTB already provides this in the kernel,
and we don't want to re-invent that, so I'm not sure we'll ever support
this properly in CAKE, sadly...
-Toke
next prev parent reply other threads:[~2019-08-20 18:31 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-18 16:33 Dave Taht
2019-08-20 12:08 ` Sebastian Gottschall
2019-08-20 16:24 ` Dave Taht
2019-08-20 16:47 ` Sebastian Gottschall
2019-08-20 16:58 ` Toke Høiland-Jørgensen
2019-08-20 17:29 ` Sebastian Gottschall
2019-08-20 17:47 ` Toke Høiland-Jørgensen
2019-08-20 18:10 ` Sebastian Gottschall
2019-08-20 18:31 ` Toke Høiland-Jørgensen [this message]
2019-08-20 18:39 ` Sebastian Gottschall
2019-08-20 18:49 ` Toke Høiland-Jørgensen
2019-08-21 7:25 ` Sebastian Gottschall
2019-08-20 19:07 ` Jonathan Morton
2019-08-20 23:43 ` Dave Taht
2019-08-21 10:21 ` Toke Høiland-Jørgensen
2019-08-21 11:03 ` Sebastian Moeller
2019-08-21 13:10 ` Dave Taht
2019-08-21 14:52 ` Jonathan Morton
2019-08-21 15:42 ` [Cake] pie " Dave Taht
2019-08-21 16:12 ` Sebastian Gottschall
2019-08-21 16:21 ` Sebastian Moeller
2019-08-21 16:28 ` Sebastian Gottschall
2019-08-21 16:50 ` Dave Taht
2019-08-21 21:40 ` Toke Høiland-Jørgensen
2019-08-21 21:53 ` Dave Taht
2019-08-22 9:18 ` Sebastian Gottschall
2019-08-22 13:15 ` [Cake] Wifi Memory limits in small platforms Dave Taht
2019-08-22 14:59 ` Dave Taht
2019-08-22 15:48 ` Sebastian Gottschall
2019-08-22 17:03 ` Dave Taht
2019-08-22 17:37 ` Sebastian Gottschall
2019-08-22 18:23 ` Toke Høiland-Jørgensen
2019-08-22 18:56 ` Dave Taht
2019-08-22 19:37 ` [Cake] [Battlemesh] " Toke Høiland-Jørgensen
2019-08-22 20:10 ` Sebastian Moeller
2019-08-22 20:30 ` [Cake] " Sebastian Gottschall
2019-08-22 23:39 ` Dave Taht
2019-08-23 6:25 ` Sebastian Gottschall
2019-08-23 6:48 ` Sebastian Moeller
2019-08-22 20:32 ` [Cake] fq_codel_fast crash/lockup Sebastian Gottschall
2019-08-21 21:39 ` [Cake] pie in dd-wrt Toke Høiland-Jørgensen
2019-08-22 9:17 ` Sebastian Gottschall
2019-08-22 10:12 ` Toke Høiland-Jørgensen
2019-08-21 7:30 ` [Cake] cake " Sebastian Gottschall
2019-08-20 18:05 ` Sebastian Gottschall
2019-08-20 23:43 ` Dave Taht
2019-08-20 23:34 ` Dave Taht
2019-08-21 7:44 ` Sebastian Gottschall
2019-08-21 7:44 ` Sebastian Moeller
2019-08-21 7:50 ` Sebastian Gottschall
2019-08-21 7:56 ` Sebastian Moeller
2019-08-21 9:04 ` Sebastian Gottschall
2019-08-21 9:17 ` Sebastian Moeller
2019-08-21 13:20 ` Dave Taht
2019-08-21 16:06 ` Sebastian Gottschall
2019-08-20 18:18 ` Sebastian Gottschall
2019-08-20 23:50 ` Dave Taht
2019-08-21 7:47 ` Sebastian Gottschall
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=87r25fsn70.fsf@toke.dk \
--to=toke@redhat.com \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=s.gottschall@newmedia-net.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