Re: [Cake] triple flow isolation

On 11/01/16 18:16, moeller0 wrote: > Hi Kevin, > > I agree the triple mode seems under-documented ;) Yes that's true but it is experimental after all - and I'm experimenting with it :-) >> On Jan 11, 2016, at 18:40 , Kevin Darbyshire-Bryant >> <ke...@darbyshire-bryant.m

Re: [Cake] Possible BUG - parent backlog incorrectly updated in case of NET_XMIT_CN

On 07/06/16 15:50, Jonathan Morton wrote: On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: I had a nose at CAKE but couldn't quit work out if a similar issue is present but I suspect it is. Certainly if Eric can't get it right "My prior att

Re: [Cake] CAKE upstream in LEDE

On 07/06/16 18:00, Dave Taht wrote: possibly 1. tc - 4.4.0-1 - Traffic control utility is what I have. Yes, you peaked too soon :-) Should be tc 4.4.0-2 :-) KDB ___ Cake mailing list Cake@lists.bufferbloat.net

Re: [Cake] Possible BUG - parent backlog incorrectly updated in case of NET_XMIT_CN

On 07/06/16 16:05, Kevin Darbyshire-Bryant wrote: On 07/06/16 15:50, Jonathan Morton wrote: On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: I had a nose at CAKE but couldn't quit work out if a similar issue is present but I s

Re: [Cake] New to cake. Some questions

On 09/06/16 21:58, Dennis Fedtke wrote: Hi Currently im running lede + cake + sqm_scripts and i have some questions: 1. What is considered the "optimal" setup atm for cake? e.g. which cake script should i use piece or layer cake? Piece of cake doesn't use diffserv hence doesn't 'soft shape'

Re: [Cake] [lede-project/source] Add support for cake qdisc (#72)

On 01/06/16 12:41, moeller0 wrote: Hi Toke, I'm guessing this was probably discussed before and I've simply forgotten; but why does this (rewriting dscp bits) need to be part of the qdisc when you can do it with iptables? Well, cake looks at the DSCP bits already, if it can do the

Re: [Cake] [Codel] Proposing COBALT

On 27/06/16 04:56, Jonathan Morton wrote: On 4 Jun, 2016, at 22:55, Jonathan Morton wrote: COBALT should turn out to be a reasonable antidote to sender-side cheating, due to the way BLUE works; the drop probability remains steady until the queue has completely

Re: [Cake] [Codel] Proposing COBALT

On 28/06/16 03:51, Jonathan Morton wrote: On 27 Jun, 2016, at 18:18, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: How do you feel about switching that package to the cobalt variant for wider stress testing? I think the best way to do that would be to merge the

Re: [Cake] cake, codel5.h, ecn marking & dropping. Confused

On 04/05/16 12:41, Jonathan Morton wrote: >> On 4 May, 2016, at 12:57, Kevin Darbyshire-Bryant >> <ke...@darbyshire-bryant.me.uk> wrote: >> >> In essence my (mis)understanding of this code is something like: We've >> got here because we've been dropping

[Cake] cake, codel5.h, ecn marking & dropping. Confused

Hi All, As a result of Eric's recent change to fq_codel which, to use an analogy, when being subject to loads of sh*t, it's better to use a shovel to get rid of it rather than a teaspoon, I started having a nose deeper into cake than I've ever gone before. I was also interested to note that one

Re: [Cake] Beating bufferbloat

Hi Alec, I don't use that build, I roll my own so I don't know if there's anything particularly clever with it. However: I assume your clients are getting IPs via DHCP. The DHCP server on Openwrt is the truly wonderful dnsmasq. By default, dnsmasq advertises itself as the local dns

Re: [Cake] UDP floods and taking advantage of egress signalling at ingress

016 at 12:29 AM, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk<mailto:ke...@darbyshire-bryant.me.uk>> wrote: Hi All, My brain woke up with this idea rattling around in it this morning...obviously the subconscious has been busy. So here it is: Is there any way to use the egress drop

[Cake] Cake strange behaviour

Hi guys, Encountering some behaviour that I don't understand. Line is a 40/10 cake limited to 39000/9840. Overheads 12, 'dual-dsthosts' in ingress, 'dual-srcshosts' on engress - limiting the on the WAN line. Take a look at my ping response graph

Re: [Cake] [Codel] Proposing COBALT

On 28/06/16 16:33, Jonathan Morton wrote: On 28 Jun, 2016, at 11:40, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: Would you like me to split out 'sparse_flows' and 'decaying_flows'? No. A flow with BLUE active won’t be in “decaying flows” continuously until t

Re: [Cake] flow dissector idea/enhancement - help

On 02/06/16 13:29, Jonathan Morton wrote: On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: Cake uses the flow dissector API to do flow hashing...including per host flows for dual/triple isolation. The unfortunate bit is that the qdisc inev

Re: [Cake] [Codel] Proposing COBALT

On 29/06/16 16:22, Kevin Darbyshire-Bryant wrote: Ok, so the above is done: cobalt merged into mainline cake/master. cobalt branch rebased/fast-forwarded to the same place, so don't forget to 'git pull' (or fetch & merge) your own repos. Patches for LEDE to point at those latest upd

Re: [Cake] flow dissector idea/enhancement - help

On 30/06/16 20:23, Kevin Darbyshire-Bryant wrote: On 30/06/16 11:27, Jonathan Morton wrote: On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: +#ifdef CONFIG_NET_SCH_ESFQ_NFCT + enum ip_conntrack_info ctinfo; + struct nf_co

Re: [Cake] [Codel] Proposing COBALT

On 28/06/16 18:37, Kevin Darbyshire-Bryant wrote: Ok, so I've pushed the 'split u32 last_len into 2 u16' tweaks to tc-adv & sch_cake. I will push a corresponding change into LEDE for the iproute2 (tc) package. The push of sch_cake itself will happen after I've merged co

Re: [Cake] flow dissector idea/enhancement - help

On 01/07/16 09:11, Kevin Darbyshire-Bryant wrote: I'm beginning to think there's a reason why enhanced sfq which is where I found that code never made it upstream :-/ It's been/being an interesting little diversion...and I've modified a kernel module that so far doesn't crash :-) KDB

Re: [Cake] Configuring cake for VDSL2 bridged connection

The 'less wrong' overhead figure is 12. The incumbent telco BT who provide access to the 'last mile' (or the bit from the nearest FTTC cabinet and the property) use a VLAN tag, adding another 4 bytes to each frame going over the wire. The above guesswork based on SIN498

Re: [Cake] Configuring cake for VDSL2 bridged connection

On 14/09/16 21:06, techic...@gmail.com wrote: I'm back again, been quite busy so lost track of this. I'm using LEDE now too. Is there an easy way to see cake is actually working? A command or something I can type in just to get clarification? You can prove that cake is being used as the

[Cake] de-natting & host fairness

Greetings! A while back I started on a quest to make cake 'nat' aware as the lack of host fairness in a typical home router environment was the only thing that prevented cake from being the ultimate qdisc in my opinion. This involves dealing with conntrack which on egress is easy (the kernel

Re: [Cake] BUG_ON vs WARN_ON

On 05/10/16 16:53, Dave Taht wrote: I did test this version of cake yesterday, had no major problems, aside from: 1) it seeming not to register drops under some circumstances in the statistics. (could be flent) 2) switching stuff like this tc qdisc add dev eth0 root cake bandwidth 700mbit

Re: [Cake] BUG_ON vs WARN_ON

On 05/10/16 16:42, Jonathan Morton wrote: On 5 Oct, 2016, at 18:24, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: How amenable are you to changing all 4 BUG_ON instances in cake to WARN_ON? Linus isn't a complete fan and I'm thinking that producing a stack trace and

Re: [Cake] BUG_ON vs WARN_ON

On 05/10/16 19:53, Jonathan Morton wrote: I wonder what it was that caused yesterday's issues? I really must try again when I've more time to get proper access. I’m having trouble reproducing it here. I know one of my boxes froze the very first time I loaded it, but it’s been running fine

Re: [Cake] BUG_ON vs WARN_ON

On 07/10/16 14:35, Jonathan Morton wrote: On 7 Oct, 2016, at 16:27, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: It's now ok...so far :-) Okay. I think I’ve found a couple of other things to improve, so stand by… I'm not sure I can take all this excitement yo

[Cake] de NATting on older kernels

Greetings, Guido Sarducci has very kindly done the work to backport de-natting to <4.4.0 kernels (commit 70169dba14daa6ef7907af9c1e922ef9f797993a) This is now merged into cake/master. For those following the tree, don't forget to pull :-) JM - I've not yet cherry-picked that into cobalt

Re: [Cake] Master branch updated

On 04/10/16 08:22, Jonathan Morton wrote: I’ve just merged the NAT, PTM and Linux-4.8 compatibility stuff into the master branch of Cake. It’s stable code and a definite improvement. This frees up the Cobalt branch for more experimentation, such as the rewrite of triple-isolate that I also

Re: [Cake] Configuring cake for VDSL2 bridged connection

On 14/09/16 21:48, Sebastian Moeller wrote: Whilst in this section of the LuCi GUI, I noticed "Which linklayer adaptation mechanism to use; for testing only", has a "cake" option? Should this be enabled? Yes it should be enabled. This really depends... Tc's stab (size table) method

Re: [Cake] de-natting & host fairness

: On 28 Sep, 2016, at 05:56, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: Does this need to be another variable/parameter or could it be the next bit along in the flow type? I’ve already pushed it to the ‘cobalt’ branch, so you can see how I’ve done it and start testing.

Re: [Cake] de-natting & host fairness

On 28/09/16 00:08, Jonathan Morton wrote: On 26 Sep, 2016, at 06:20, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: Another github user 'tegularius' presented some beautifully crafted code that did the lookups in a much neater way. Originally it too had an 'ingress'

Re: [Cake] de-natting & host fairness

On 28/09/16 07:07, Kevin Darbyshire-Bryant wrote: Two buglets found: in sch_cake - the atm/ptm flag options are not passed back to tc userspace correctly - ptm isn't sent back. Just fixed that & pushed don't forget to pull :-) ___

Re: [Cake] de-natting & host fairness

, Noah Causin On 9/26/2016 10:32 PM, Kevin Darbyshire-Bryant wrote: Easy fix. See the added DEPENDS line in the attached patch for the package Makefile :-) I'm guessing you've updated the git checkout hash to point at a suitable place. Cheers, Kevin On 27/09/16 02:52, Noah Causin wrote

Re: [Cake] de-natting & host fairness

measure as cake will not simply reduce the available bandwidth when running out of CPU cycles but first will allow the latency to increase. Best Regards Sebastian On Sep 26, 2016, at 05:20 , Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: Greetings! A while back I star

Re: [Cake] de-natting & host fairness

On 26/09/16 14:28, moeller0 wrote: Hi Kevin, This really needs to be tested. As I mentioned the 'ingress' side of things is harder work because the kernel hasn't filled in the conntrack pointer for us. There are some remaining concerns over how reliable our own lookup actually is. The

Re: [Cake] de-natting & host fairness

: Package kmod-sched-cake is missing dependencies for the following libraries: nf_conntrack.ko >From 2d0d549f072379da20be70535c14b40496d42dfb Mon Sep 17 00:00:00 2001 From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> Date: Thu, 30 Jun 2016 16:09:32 +0100 Subject: [PATCH 1/3] k

Re: [Cake] Choosing a tin to work on

On 11/04/17 14:59, George Amanakis wrote: Hi Jonathan, I have some questions regarding the algorithm to choose a tin to dequeue from in sch_cake.c: ---8< int oi, best_tin=0; s64 best_time = 0xUL; for(oi=0; oi < q->tin_cnt; oi++) {

Re: [Cake] Questions on Cake/cobalts experiment ingress mode

Ahh, cheers Jonathan, understand! (and thanks for the really quick reply) Kevin (much less confused) On 06/04/17 10:19, Jonathan Morton wrote: On 6 Apr, 2017, at 12:17, Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> wrote: Can I now apply two qdiscs to eth0 di

[Cake] Questions on Cake/cobalts experiment ingress mode

Hi All, I've been out of the loop for a while and just noticed the 'ingress' mode for cake in the cobalt experimental branch. Colour me confused on how to use this. My (typical) situation is I've 'eth0' as my WAN port connected to an ISP VDSL2 modem - this is naturally asymmetric in

Re: [Cake] cake status & forks

On 27/06/17 19:41, Adrian Popescu wrote: Hello, I've been reading the code for a while. I'll experiment and send any useful patches. The technical docs would have been extremely useful in the process. The CakeTechnical page is useful, but it lacks descriptions of the algorithms. Is cake

Re: [Cake] Cake on LEDE - package maintainer required

On 28/06/17 00:58, Outback Dingo wrote: Ill take it Thank you, appreciated. I can update my patch into LEDE where I drop maintainer to change to you, or you can generate your own patch to take over up to you. The PKG_MAINTAINER field does require a real name though. Cheers,

Re: [Cake] overhead and mpu

On 05/09/17 15:37, Ryan Mounce wrote: +1 It would also be nice for tc to know whether the overhead has been explicitly configured and report appropriately. In my case I use cake on a VLAN sub-interface that happens to have a hard_header_len of 18 after the 802.1q tag, and then use the

Re: [Cake] allocate_src allocate_dst

> On 25 Nov 2017, at 16:41, Jonathan Morton wrote: > > Not quite. The "dual" enums have more than one bit set, so you have to test > them for equality. > > - Jonathan Morton Here you go

Re: [Cake] RFC: allocate without the gotos

> On 26 Nov 2017, at 10:00, Jonathan Morton wrote: > > On a purely theoretical basis, it probably isn't as fast, because now the > 'found' condition has to be tested multiple times on the fast and slow paths > alike. Only if the compiler is smart enough to transform

Re: [Cake] allocate_src allocate_dst

Have to say, my perception is that I’ve a small cpu usage improvement for my use case with these changes. Then I would expect that ‘cos I use ‘dual-srchost’ on egress and ‘dual-dsthost’ on ingress, so I’m saving running the dst/src host allocation code on egress/ingress respectively. Of

Re: [Cake] allocate_src allocate_dst

https://github.com/dtaht/sch_cake/pull/74 Once again, sorry about the screwup. > On 25 Nov 2017, at 20:49, Kevin Darbyshire-Bryant > <ke...@darbyshire-bryant.me.uk> wrote: > > [This sender failed our fraud detection checks and may not be who they appear > to be. Learn a

Re: [Cake] allocate_src allocate_dst

> On 25 Nov 2017, at 16:41, Jonathan Morton wrote: > > Not quite. The "dual" enums have more than one bit set, so you have to test > them for equality. > > - Jonathan Morton Oh dammit, yes they are dual bit flags, rats. good catch. v2 shortly he he :-)

Re: [Cake] allocate_src allocate_dst

> On 25 Nov 2017, at 15:19, Jonathan Morton wrote: > > I think I originally intended to make them individually conditional on the > src/dest host flags, but that idea evidently got forgotten. > > - Jonathan Morton Ahh, is this

Re: [Cake] allocate_src allocate_dst

Ooops, sorry, dodge merge on my part from my work tree back to cobalt. A fix & PR will be with you shortly…. apologies. Kevin > On 25 Nov 2017, at 20:03, George Amanakis wrote: > > I think we missed an "allocate_host" in cake_hash(), line ~810: > > if (allocate_host) {

Re: [Cake] cobalt through checkpatch

> On 21 Nov 2017, at 21:59, Dave Taht wrote: > > > You will want to pull and rebase on top of this. > > Are there any other patches still lying out of tree worth considering? Just did a PR for turning max_skblen (or whatever it is) to a u32….since there *are* super packets

Re: [Cake] cobalt through checkpatch

> On 23 Nov 2017, at 17:07, Dave Taht <d...@taht.net> wrote: > > Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: >> >> Just did a PR for turning max_skblen (or whatever it is) to a u32….since >> there *are* super packets out there

Re: [Cake] Cake tree unreadable

> On 28 Nov 2017, at 18:48, Dave Taht wrote: > > > > It sounds like your git-foo is stronger than ours! I'm not even trying > to get head to work, tho my intent would be to promote cobalt to it. git checkout master git pull (does the equivalent of git fetch origin; git

Re: [Cake] options for shrinking cake xstats

This didn’t seem to generate any response so I’ll have a go :-) > On 6 Dec 2017, at 00:06, Dave Taht wrote: > > as 1400+ bytes on the parisc stack, is a bit much. That said, I don't > see much possibility for shrinkage overall. How much over do you happen to know? I see a

Re: [Cake] overhead for double nat VDSL2 connection

> On 17 Dec 2017, at 15:23, Sebastian Moeller wrote: > > Hi Mark, > >> On Dec 17, 2017, at 11:45, Mark Captur wrote: >> >> My setup is as follows >> >> vdsl2 modem doing pppoe itself and nat to 10.x.x.x -> lede master eth0.2 >> (wan static ip in

Re: [Cake] [Fwd: Re: RHODIUM - nuking blue (for testing)]

> On 7 Dec 2017, at 02:19, Jonathan Morton wrote: > > > It would be nice to have a test showing blue being useful. > > To do that, you would need to have a saturating unresponsive load, such as a > UDP flood, which drives Cake's queue to the memory limit. Even then, I

Re: [Cake] cake vs fqcodel with 1 client, 4 servers

> On 7 Dec 2017, at 08:21, Jonathan Morton wrote: > > Okay, I found that the parameters used were suspicious and didn't prevent > Cake from dropping packets. I've pushed a tc-adv update to fix that, so you > should try that again. > > Other RTT keywords are

Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter

> On 18 May 2018, at 05:27, Cong Wang wrote: > > On Thu, May 17, 2018 at 4:23 AM, Toke Høiland-Jørgensen wrote: >> Eric Dumazet writes: >> >>> On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote: The ACK filter is an

Re: [Cake] tc not showing detailed stats

> On 20 May 2018, at 14:23, Georgios Amanakis wrote: > > Hi All, > > I am running latest tc-adv (r4227) and sch-cake/cobalt (r500), and "tc > -s qdisc show" doesn't show detailed stats anymore. Latest known > working revisions for me were tc-adv:r4226 sch-cake:r494. > >

Re: [Cake] overheads or rate calculation changed?

> On 22 Dec 2017, at 06:38, Jonathan Morton wrote: > >> On 21 Dec, 2017, at 2:54 am, Andy Furniss wrote: >> >> refactor cake_advance_shaper and ack_filter >> >> cake_advance_shaper now returns a modified len argument to >> reflect

Re: [Cake] CAKE related iproute2 & kernel patches - keeping things in sync

> On 30 Jul 2018, at 00:42, Dave Taht wrote: > > On Sun, Jul 29, 2018 at 3:05 AM Kevin Darbyshire-Bryant > wrote: >> >> To whom it may concern (Dave) ;-) >> >> This is a general plea that when patches are submitted to upstream please >> can we a

[Cake] CAKE related iproute2 & kernel patches - keeping things in sync

To whom it may concern (Dave) ;-) This is a general plea that when patches are submitted to upstream please can we also commit them to our current development repositories. 4.19 isn’t even released yet, so most people, including Openwrt, get cake via our 'out of tree’ repositories. This is

Re: [Cake] Removing kmod-sched-cake package from openwrt

> On 19 Jul 2018, at 17:08, Toke Høiland-Jørgensen wrote: > > Yeah, considered doing a backport patch to the kernel in openwrt. But I > concluded it was not worth the trouble, since we already have a working > module from the main repo. I’m coming to a similar conclusion. The motivation came

Re: [Cake] Backporting 'tc class' support

> On 14 Jul 2018, at 22:50, Toke Høiland-Jørgensen wrote: > > Now that CAKE has been accepted upstream, I figured it was a good time > to backport the 'tc class' support. So I did, back to kernel v4.9. > > This is in the master branch; anyone feel like testing? With this, the > version of

Re: [Cake] Backporting 'tc class' support

> On 15 Jul 2018, at 10:48, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > >>> On 14 Jul 2018, at 22:50, Toke Høiland-Jørgensen wrote: >>> >>> Now that CAKE has been accepted upstream, I figured it was a good time >>> to

Re: [Cake] cake in lede-17.01

> On 15 Jul 2018, at 14:32, Georgios Amanakis wrote: > > Dear All, > > I backported cake as of commit c91b94f and tc-adv as of 3968731 > (latest). I tested in a TP-Link WR-941NDv3 and everything looks ok, > including the stats. > > Could someone take a look at the pull requests? >

Re: [Cake] cake in lede-17.01

> On 15 Jul 2018, at 17:13, Georgios Amanakis wrote: > > I am not sure we need this in 4.4. > In the patch we check for "d->tail->nla_type == padattr". > However, all gnet_stats_copy*() are defined without a padding attribute. Hmm, I wonder how they handle attribute alignment on MIPS….or

Re: [Cake] I figure lede is a bit out of sync at the moment

> On 15 Jul 2018, at 16:03, Dave Taht wrote: > > https://forum.lede-project.org/t/sqm-works-with-fq-codel-but-not-cake-18-06rc1/17083 Which links to https://forum.lede-project.org/t/sqm-doesnt-seem-to-be-working-in-18-06-0-rc1/16915/17 that says it’s fixed. I’d be very interested to know

Re: [Cake] Backporting 'tc class' support

> On 15 Jul 2018, at 21:23, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > >>> On 15 Jul 2018, at 10:48, Toke Høiland-Jørgensen wrote: >>> >>> Kevin Darbyshire-Bryant writes: >>> >>>>> On 14 Jul

Re: [Cake] Flent & Mac OS

install new packages into > apple's python version. > I am pretty sure that is also doable with homebrew or any other porting > system on the mac. > > Best Regards > > > > > >> On Jul 21, 2018, at 20:58, Kevin Darbyshire-Bryant >> wrote: >> >

[Cake] Flent & Mac OS

Hi Chaps Would love to help Dave with his flent run request. Is there anyone who can hand hold me through mac os installation? Having a battle and on the losing side :-/ Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with

Re: [Cake] Flent & Mac OS

was sudo pip install > flent > > But that might have been easy because I've done it before. > > On 21 July 2018 at 20:40, Kevin Darbyshire-Bryant > wrote: > Hi Chaps > > Would love to help Dave with his flent run request. Is there anyone who can > hand hold

[Cake] Removing kmod-sched-cake package from openwrt

Hiya Chaps, Bet that subject woke you up! This is one for the back burner but I’d like to do it at some point, mainly ‘cos my name is in the maintainer field :-) Ideally I’d like to introduce cake as a kernel patch backport to openwrt instead of as an additional module. I’ve started out but

Re: [Cake] Backporting 'tc class' support

> On 16 Jul 2018, at 13:28, Toke Høiland-Jørgensen wrote: > > Georgios Amanakis writes: > >> On Mon, 2018-07-16 at 12:18 +0200, Toke Høiland-Jørgensen wrote: >>> Right, pushed an update to this effect. Will submit it upstream as >>> well >>> once someone has verified that it does what it's

[Cake] Wikipedia & CAKE

Hi All, I’ve been gently dabbling with wikipedia and as I was playing with ECN on a NAS box decided to look at https://en.wikipedia.org/wiki/Explicit_Congestion_Notification The CAKE bit now has a citation and slightly more flashing lights around it (it’s in CAPITALS) at least. It would be

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

> On 7 Mar 2018, at 18:27, Kevin Darbyshire-Bryant > <ke...@darbyshire-bryant.me.uk> wrote: > > > >> On 7 Mar 2018, at 12:59, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >> >>> qdisc cake 8004: root refcnt 4486780 bandwidth 199

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

> On 8 Mar 2018, at 00:49, Jonathan Morton wrote: > >> On 7 Mar, 2018, at 11:34 pm, Toke Høiland-Jørgensen wrote: >> >> Ah, totally missed that those were wrong as well. The values for >> dropped, overlimits and requeues are not printed by the

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

> On 8 Mar 2018, at 10:57, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: > >> Archer c7 v2. master branch of openwrt > > Ah, great; I actually have one of those sitting on my desk that I

Re: [Cake] [PATCH 2/2] tc print_uint format fixes

> On 11 Mar 2018, at 20:50, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> writes: > >> Signed-off-by: Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> >> --- >&

[Cake] [PATCH 2/2] tc print_uint format fixes

Signed-off-by: Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> --- tc/tc_qdisc.c | 3 ++- tc/tc_util.c | 24 2 files changed, 14 insertions(+), 13 deletions(-) diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c index 70279b9d..3ec74a1c 100644 --- a/tc/tc_qdisc.c

[Cake] [PATCH 1/2] cake: print_uint format fixes

Signed-off-by: Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> --- tc/q_cake.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/tc/q_cake.c b/tc/q_cake.c index 44cadb63..f888bd2a 100644 --- a/tc/q_cake.c +++ b/tc/q_cake.c @@ -47,6 +47,7 @@ #i

Re: [Cake] [PATCH 1/2] cake: print_uint format fixes

> On 12 Mar 2018, at 15:38, Toke Høiland-Jørgensen wrote: > > Stephen Hemminger writes: > Using the ‘PRId64’ macro won’t work because print_int is using ‘int’ type internally whereas print_uint uses ‘uint64_t’ internally. So the format

Re: [Cake] [PATCH 1/2] cake: print_uint format fixes

formats you should use the relevant PRIdN or PRIuN formats as defined in inttypes.h e.g. print_uint64(PRINT_ANY, "refcnt", "refcnt %" PRIu64 " ", t->tcm_info) Signed-off-by: Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> --- include/json_print.h | 6 +-

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

> On 8 Mar 2018, at 11:21, Toke Høiland-Jørgensen wrote: > >> >> Oh and curiously the bad values go away if you ask for json output >> it’s much better. Which rather points at a ‘feature’ of the >> ‘print_string’ behaviour. > > Right. Well, the print_* functions are behind

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

> On 7 Mar 2018, at 10:31, Toke Høiland-Jørgensen wrote: > >> > > Please don't put something different into LEDE than what we're working > on upstreaming. It is difficult enough to keep track of the different > versions as they are. The tc-adv repo is already rebased on the

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

There were some useful stats column re-alignment changes as well, wonder if you got those? > On 7 Mar 2018, at 10:36, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Toke Høiland-Jørgensen <t...@toke.dk> writes: > >> Kevin Darbyshire-Bryant <ke...@darbyshire

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

<t...@toke.dk> wrote: > > Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: > >> There were some useful stats column re-alignment changes as well, >> wonder if you got those? > > Probably not, as that code is not longer directly diff

Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

Hi All, > On 7 Mar 2018, at 08:50, Toke Høiland-Jørgensen wrote: > > Jonathan Morton writes: > >>> On 6 Mar, 2018, at 11:06 pm, Toke Høiland-Jørgensen wrote: >>> >>> ...on the iproute2 side the only >>> thing missing before we can attempt

Re: [Cake] act_conndscp

It looks like act_conndscp has been shot down by the kernel people, at least in its current form. Setting a conntrack mark from tc is regarded as “not sure if it is a good idea”. The other way (conntrack to skb) is fine. That’s sort of good news in that ingress is the hard bit as it’s

Re: [Cake] Sce In cake testers wanted

and sent a github PR to get tc-adv to report sce enabled/disabled status correctly. > On 23 Mar 2019, at 21:28, Kevin Darbyshire-Bryant > wrote: > > Sent a github PR to make it build - not run it yet. > >> On 23 Mar 2019, at 19:15, Dave Taht wrote: >> >>

[Cake] SCE/CAKE coding curiosities

Ahoy there team Bufferboat :-) I’ve been looking at the new SCE related code and a few questions have fallen out of the brain cell. 1) https://github.com/dtaht/sch_cake/blob/47d821f89f39c1b2216d6f65b014f609e46fc57c/sce.h#L50 Curious as to why htons isn’t used here as per other instances in

Re: [Cake] act_conndscp

> On 23 Mar 2019, at 18:35, Kevin Darbyshire-Bryant > wrote: > > > >> On 22 Mar 2019, at 21:24, Kevin Darbyshire-Bryant >> wrote: >> >> It looks like act_conndscp has been shot down by the kernel people, at least >> in its current form.

Re: [Cake] act_conndscp

> On 22 Mar 2019, at 21:24, Kevin Darbyshire-Bryant > wrote: > > It looks like act_conndscp has been shot down by the kernel people, at least > in its current form. Setting a conntrack mark from tc is regarded as “not > sure if it is a good idea”. The other way (conntra

Re: [Cake] Sce In cake testers wanted

Sent a github PR to make it build - not run it yet. > On 23 Mar 2019, at 19:15, Dave Taht wrote: > > > On Sat, Mar 23, 2019, 8:09 PM Jonathan Morton wrote: > > On 23 Mar, 2019, at 4:33 pm, Pete Heist wrote: > > > >> Oddly, I think this is the fastest train I've yet ridden on this trip. >

Re: [Cake] Using firewall connmarks as tin selectors

> On 28 Feb 2019, at 09:54, Toke Høiland-Jørgensen wrote: > >> I also equally aware that this is ‘creeping featuritis’ and doing >> nothing to speed cake up… > > Yeah, this is the crux of the issue, really: it's a tradeoff between > ease of use and featuritis. Now in this case the actual

[Cake] Using firewall connmarks as tin selectors

How unpopular would the idea of having cake look at skb->mark directly be? https://github.com/ldir-EDB0/sch_cake/commit/64d0e6ac9368a271221db888ab91a367fcd37ae1 https://github.com/ldir-EDB0/tc-adv/commit/4f16ae5d588d44f8a5c83fe2f2b7dcad97843cbc I did the equivalent in eBPF here

Re: [Cake] Using firewall connmarks as tin selectors

> On 4 Mar 2019, at 08:39, Pete Heist wrote: > > >> On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant >> wrote: >> >> The very bad idea: >> >> And it’s bad ‘cos it’s sort of incompatible with the existing fwmark >> implementation as d

Re: [Cake] Using firewall connmarks as tin selectors

> On 4 Mar 2019, at 11:17, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > >>> On 4 Mar 2019, at 08:39, Pete Heist wrote: >>> >>> >>>> On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant >>>> wrote:

Re: [Cake] Using firewall connmarks as tin selectors

> On 4 Mar 2019, at 16:39, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > > [ ... snipping a bit of context here ... ] > >>>>>> +void cake_update_ct_mark(struct sk_buff *skb, u8 dscp) >>>>>> +{ >>>>

Re: [Cake] Using firewall connmarks as tin selectors

> On 4 Mar 2019, at 12:44, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > >>> On 4 Mar 2019, at 11:17, Toke Høiland-Jørgensen wrote: >>> >>> Kevin Darbyshire-Bryant writes: >>> >>>>> On 4 Mar 2019, a

Re: [Cake] act_connmark + dscp

> On 6 Mar 2019, at 15:21, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > >> Before I go too far down this road (and to avoid the horror of >> actually trying to code it) here’s what I’m trying to achieve. >> >> >> act_connm

  1   2   >