Dave Taht writes:
> And now I can comment.
>
> I've added this version to a for_upstream branch in the hope that future
> commits can be kept in sync.
>
> Is there anything more that should be added to the commit message?
> Should I be less snarky?
>
>> while presenting an API simple enough that
The stats are a little bit unwieldy, true. Is there an example of the TLV
style of operation that I could study?
- Jonathan Morton
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
On 22 November 2017 at 11:25, Dave Taht wrote:
>
> And now I can comment.
>
> I've added this version to a for_upstream branch in the hope that future
> commits can be kept in sync.
>
> Is there anything more that should be added to the commit message?
> Should I be less snarky?
>
> Dave Taht wri
Stephen Hemminger writes:
> On Tue, 21 Nov 2017 16:09:40 -0800
> Dave Taht wrote:
>
>>
>> +/* CAKE */
>> +enum {
>> +TCA_CAKE_UNSPEC,
>> +TCA_CAKE_BASE_RATE,
>> +TCA_CAKE_DIFFSERV_MODE,
>> +TCA_CAKE_ATM,
>> +TCA_CAKE_FLOW_MODE,
>> +TCA_CAKE_OVERHEAD,
>> +TCA_CAKE_RT
And now I can comment.
I've added this version to a for_upstream branch in the hope that future
commits can be kept in sync.
Is there anything more that should be added to the commit message?
Should I be less snarky?
Dave Taht writes:
> sch_cake is intended to squeeze the most bandwidth and l
On Tue, 21 Nov 2017 16:09:40 -0800
Dave Taht wrote:
>
> +/* CAKE */
> +enum {
> + TCA_CAKE_UNSPEC,
> + TCA_CAKE_BASE_RATE,
> + TCA_CAKE_DIFFSERV_MODE,
> + TCA_CAKE_ATM,
> + TCA_CAKE_FLOW_MODE,
> + TCA_CAKE_OVERHEAD,
> + TCA_CAKE_RTT,
> + TCA_CAKE_TARGET,
> +
sch_cake is intended to squeeze the most bandwidth and lowest latency out
of even the slowest ISP links and routers, while presenting an API simple
enough that even an ISP can configure it.
Example of use on an ISP uplink:
tc qdisc add dev eth0 cake bandwidth 20Mbit nat docsis ack-filter
Cake ca
Hook up sch_cake to the build system.
---
net/sched/Kconfig | 11 +++
net/sched/Makefile | 1 +
2 files changed, 12 insertions(+)
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index c03d86a..3ea22e5 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -284,6 +284,17 @@ config
---
include/uapi/linux/pkt_sched.h | 58 ++
1 file changed, 58 insertions(+)
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index af3cc2f..ed7c111 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
sch_cake is intended to squeeze the most bandwidth and lowest latency out
of even the slowest ISP links and routers, while presenting an API simple
enough that even an ISP can configure it.
Example of use on an ISP uplink:
tc qdisc add dev eth0 cake bandwidth 20Mbit nat docsis ack-filter
Cake ca
You will want to pull and rebase on top of this.
Are there any other patches still lying out of tree worth considering?
* retired cobalt.c
* made checkpatch considerably less unhappy
(down to zero warnings and checks)
* I added a few comments as well.
__
Jonathan Morton writes:
> On 17/11/17 21:52, Dave Taht wrote:
>>> /* please try to keep this structure <= 64 bytes */
>
>> Is it?
>
> Assuming 'struct list_head' is two pointers, it's marginal on a 64-bit box but
> definitely less on 32-bit (where it's more likely to be important). The extra
> '
Jonathan Morton writes:
> On 17/11/17 21:52, Dave Taht wrote:
>> I think if (!drop && var->p_drop) would be more effecient here.
>
> But it is 'p_drop' that is more likely to be zero in practice. The BLUE logic
> rarely activates.
ok.
___
Cake mailing
Jonathan Morton writes:
> On 17/11/17 21:52, Dave Taht wrote:
>>> + schedule = now - vars->drop_next;
>
>> I don't understand the schedule concept that well. Kind of goes with not
>> understanding the overloading of the drop_next field.
>
> The 'schedule' variable simply records, in its
Jonathan Morton writes:
> On 17/11/17 21:52, Dave Taht wrote:
>>> +#define REC_INV_SQRT_CACHE (16)
>
>> Never been proven that this cache either improves cpu utiliziation, nor
>> that the added accuracy has any effect. I'd like to be able to
>> completely compile out the cache.
>
> CPU utilisatio
Jonathan Morton writes:
> On 17/11/17 21:52, Dave Taht wrote:
>> Actually using **to_free sanely (here, in qdisc_reduce_backlog, etc)
>> would be good. I like very much how fq_codel does bulk dropping now.
>>
>> I think, but am unsure, that the whole heap concept would just "go",
>> in that case.
Pete Heist writes:
> On Nov 19, 2017, at 9:41 PM, Dave Taht wrote:
>
>
>
> Yep with bql. I hadn’t thought about mq before. What my qos setup scripts
> are
> doing though is replacing the root qdisc (which now I see defaults to
> mq) with a
> sing
17 matches
Mail list logo
