Re: [Cake] Testing wanted: Statistics API rework

On Tue, Apr 24, 2018 at 11:30:35PM +0200, Toke Høiland-Jørgensen wrote: > Hey everyone > > As you have probably seen, the posting of CAKE to netdev resulted in > feedback saying that versioned structs are a no-go. Well, I've just > pushed a change to both the cake and tc repos that changes the >

Re: [Cake] Testing variants of the MTU latency scaling

Hi Jonas, > On Apr 24, 2018, at 22:27, Jonas Mårtensson > wrote: > > > > On Tue, Apr 24, 2018 at 9:22 PM, Kevin Darbyshire-Bryant > wrote: > Assuming you’re using luci to configure then enabling both show and use > advanced

Re: [Cake] Testing variants of the MTU latency scaling

--- Begin Message --- Assuming you’re using luci to configure then enabling both show and use advanced configuration & show and use dangerous configurations… then enter ‘ingress’ in the ‘advanced option string to pass to ingress queuing’ will enable ingress mode. Maybe that helps? > On 24 Apr

Re: [Cake] Testing variants of the MTU latency scaling

On Tue, Apr 24, 2018 at 1:45 PM, Toke Høiland-Jørgensen wrote: > Jonas Mårtensson writes: > > > One thing that is still not clear to me from these results: if I run > > cake on an IFB without ingress mode (i.e. the default?), does the MTU > > scaling

Re: [Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

Georgios Amanakis writes: > On Tue, Apr 24, 2018 at 11:47 AM, Georgios Amanakis > wrote: >>> >>> Does anyone know if there is a way to do this so the module/builtin >>> split doesn't bite us? >>> >> #ifdef CONFIG_NF_CONNTRACK ?? That is basically what

Re: [Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

On Tue, Apr 24, 2018 at 11:47 AM, Georgios Amanakis wrote: >> >> Does anyone know if there is a way to do this so the module/builtin >> split doesn't bite us? >> > #ifdef CONFIG_NF_CONNTRACK ?? ___ Cake mailing list

Re: [Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

Georgios Amanakis writes: > On Tue, 24 Apr 2018 13:44:06 +0200 > Toke Høiland-Jørgensen wrote: > >> +config NET_SCH_CAKE >> + tristate "Common Applications Kept Enhanced (CAKE)" >> + help >> + Say Y here if you want to use the Common

Re: [Cake] [PATCH iproute2-next v3] Add support for cake qdisc

Stephen Hemminger writes: > On Tue, 24 Apr 2018 16:52:57 +0200 > Toke Høiland-Jørgensen wrote: > >> Well, this is leftover from keeping track of different versions of the >> out-of-tree patch, and we already broke compatibility pretty thoroughly >> as a

Re: [Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

On Tue, 24 Apr 2018 13:44:06 +0200 Toke Høiland-Jørgensen wrote: > +config NET_SCH_CAKE > + tristate "Common Applications Kept Enhanced (CAKE)" > + help > + Say Y here if you want to use the Common Applications Kept Enhanced > + (CAKE) queue management

Re: [Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

On Tue, 24 Apr 2018 13:44:06 +0200 Toke Høiland-Jørgensen wrote: > +static const u8 precedence[] = {0, 0, 0, 0, 0, 0, 0, 0, > + 1, 1, 1, 1, 1, 1, 1, 1, > + 2, 2, 2, 2, 2, 2, 2, 2, > + 3, 3, 3, 3, 3,

Re: [Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

On Tue, 24 Apr 2018 13:44:06 +0200 Toke Høiland-Jørgensen wrote: > +struct tc_cake_xstats { > + __u16 version; > + __u16 tin_stats_size; /* == sizeof(struct tc_cake_tin_stats) */ > + __u32 capacity_estimate; > + __u32 memory_limit; > + __u32 memory_used; > +

Re: [Cake] [PATCH iproute2-next v3] Add support for cake qdisc

On Tue, 24 Apr 2018 16:52:57 +0200 Toke Høiland-Jørgensen wrote: > Well, this is leftover from keeping track of different versions of the > out-of-tree patch, and we already broke compatibility pretty thoroughly > as a preparation for upstreaming. So I'm fine with dropping the

Re: [Cake] Pre-print of Cake paper available

On Tue, Apr 24, 2018 at 4:17 AM, Sebastian Moeller wrote: > That is true to some degree, but the overall algorithm is not that hard: Set the shaper at 50% of contracted rate and measure the bufferbloat (depending on the expertise of the user either via flent or the dslreports

Re: [Cake] [PATCH iproute2-next v3] Add support for cake qdisc

Stephen Hemminger writes: > On Tue, 24 Apr 2018 14:30:46 +0200 > Toke Høiland-Jørgensen wrote: > >> +static void cake_print_json_tin(struct tc_cake_tin_stats *tst, uint version) >> +{ >> +open_json_object(NULL); >> +print_uint(PRINT_JSON,

Re: [Cake] [PATCH iproute2-next v3] Add support for cake qdisc

On Tue, 24 Apr 2018 14:30:46 +0200 Toke Høiland-Jørgensen wrote: > diff --git a/tc/q_cake.c b/tc/q_cake.c > new file mode 100644 > index ..12263361 > --- /dev/null > +++ b/tc/q_cake.c > @@ -0,0 +1,778 @@ > +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ > +/* > +

[Cake] [PATCH iproute2-next v3] Add support for cake qdisc

sch_cake 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. Example of use on a cable ISP uplink: tc qdisc add dev eth0 cake bandwidth 20Mbit nat docsis ack-filter To shape

Re: [Cake] Testing variants of the MTU latency scaling

Jonas Mårtensson writes: > One thing that is still not clear to me from these results: if I run > cake on an IFB without ingress mode (i.e. the default?), does the MTU > scaling have any impact on TCP download throughput? Odds are that not using ingress mode will

[Cake] [PATCH net-next v2] Add Common Applications Kept Enhanced (cake) qdisc

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. Example of use on a cable ISP uplink: tc qdisc add dev eth0 cake bandwidth

[Cake] [PATCH iproute2-next v2] Add support for cake qdisc

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. Example of use on a cable ISP uplink: tc qdisc add dev eth0 cake bandwidth

Re: [Cake] Pre-print of Cake paper available

Sebastian Moeller writes: >> Looking at those threads, they seem to be increasing the number of >> queues. Not sure they need to, but, well, there's nothing in principle >> that says this couldn't be configurable (it is in FQ-CoDel). It would >> need a bit of a reorg of the

Re: [Cake] Pre-print of Cake paper available

Hi Toke, > On Apr 24, 2018, at 11:30, Toke Høiland-Jørgensen wrote: > > Sebastian Moeller writes: > [...] >>> >>> I don't think we can make assumptions on ISP deployments. >> >> Sure we do not really need to: >>

Re: [Cake] Pre-print of Cake paper available

> On Apr 24, 2018, at 11:15 AM, Toke Høiland-Jørgensen wrote: > > Well, you could use it on an ISP backhaul by having a separate CAKE > instance per customer, and having another mechanism to assign customer > traffic to each. Yep, am aware of that possibility, and the setup fun

Re: [Cake] Pre-print of Cake paper available

Sebastian Moeller writes: > Hi Toke, > > > >> On Apr 24, 2018, at 10:47, Toke Høiland-Jørgensen wrote: >> >> Sebastian Moeller writes: >> On Apr 24, 2018, at 01:01, Pete Heist wrote: > On Apr 23, 2018, at

Re: [Cake] Pre-print of Cake paper available

Hi Toke, > On Apr 24, 2018, at 10:47, Toke Høiland-Jørgensen wrote: > > Sebastian Moeller writes: > >>> On Apr 24, 2018, at 01:01, Pete Heist wrote: >>> >>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen wrote:

Re: [Cake] Pre-print of Cake paper available

Pete Heist writes: >> On Apr 24, 2018, at 10:50 AM, Jonathan Morton wrote: >> >>> I think, if we wanted to support the ISP case, that a per-customer *shaper* >>> is more useful. >> >> Yes, I think the technology can be recoded to better suit a >>

Re: [Cake] Pre-print of Cake paper available

> On Apr 24, 2018, at 10:50 AM, Jonathan Morton wrote: > >> I think, if we wanted to support the ISP case, that a per-customer *shaper* >> is more useful. > > Yes, I think the technology can be recoded to better suit a multi-subscriber > environment; it would no longer

Re: [Cake] [PATCH] Remove plain pkt_sched.h dependency

Georgios Amanakis writes: > I just tried an in-tree built using net-next. Aside from that line it > compiles on x86_64 successfully. I will give it a try on my router > later on. Yeah, I was getting to that; but removing that include means the changes have to be imported

Re: [Cake] Pre-print of Cake paper available

> I think, if we wanted to support the ISP case, that a per-customer *shaper* > is more useful. Yes, I think the technology can be recoded to better suit a multi-subscriber environment; it would no longer be Cake, but would use some of the same key algorithms. - Jonathan Morton

Re: [Cake] Pre-print of Cake paper available

Sebastian Moeller writes: >> On Apr 24, 2018, at 01:01, Pete Heist wrote: >> >> >>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen wrote: >>> >>> Last week we submitted an academic paper describing Cake. A pre-print is >>> now available

Re: [Cake] Pre-print of Cake paper available

Pete Heist writes: >> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen wrote: >> >> Last week we submitted an academic paper describing Cake. A pre-print is >> now available on arXiv: https://arxiv.org/abs/1804.07617 >> >> Comments welcome, of course :) > >

Re: [Cake] Testing variants of the MTU latency scaling

--- Begin Message --- > On 24 Apr 2018, at 09:14, Jonathan Morton wrote: > >> So in egress mode the first part of the OR statement will always be true >> (p->mtu_time * bulk_flows (0) * 2) is always 0, > > Yeah, that's what happens when I get rushed. Let me see if I

Re: [Cake] Testing variants of the MTU latency scaling

> So in egress mode the first part of the OR statement will always be true > (p->mtu_time * bulk_flows (0) * 2) is always 0, Yeah, that's what happens when I get rushed. Let me see if I can fix the logic. - Jonathan Morton ___ Cake mailing list

Re: [Cake] Testing variants of the MTU latency scaling

--- Begin Message --- > On 23 Apr 2018, at 11:50, Jonathan Morton wrote: > >> Right. Pushed the patch to the cobalt branch, feel free to fix it up :) > > Given that I basically had to revert 80% of it and start again, perhaps not > the best policy. Ha :-)