Y via Cake writes:
> From: Y
> Subject: Re: [Cake] Diffserv LLT mode
> To: cake@lists.bufferbloat.net
> Date: Sat, 21 Apr 2018 21:40:48 +0900
>
> Hi.
>
> mine stat doen't inclued more.
> sad.
Did you upgrade the kernel module without
Dave Taht writes:
> do we consider cake ready this time?
I'm not aware of anything outstanding, at least...
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
Jonathan Morton writes:
your solution significantly hurts performance in the common case
>>>
>>> I'm sorry - did someone actually describe such a case? I must have
>>> missed it.
>>
>> I started this whole thread by pointing out that this behaviour results
>> in
Is anyone actually using the LLT diffserv setting? The draft describing
it seems to have expired ages ago:
https://datatracker.ietf.org/doc/draft-you-tsvwg-latency-loss-tradeoff/
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
Pete Heist writes:
>> On Apr 18, 2018, at 7:43 AM, Pete Heist wrote:
>>
>> I also think I saw this happen at lower bandwidths as well, when the CPU
>> wasn’t loaded. What I’ll do is re-test on the current version I have at,
>> say, 50Mbit (or to where load
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
Pete Heist <p...@eventide.io> writes:
>> On Apr 24, 2018, at 11:30 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>
>> If someone has time to test it (especially on mips!), that would be
>> great; I think we still have a few days left of net-next being o
.
sch_cake replaces a combination of iptables, tc filter, htb and fq_codel
in the sqm-scripts, with sane defaults and vastly simpler configuration.
Cake's principal author is Jonathan Morton, with contributions from
Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller,
Ryan Mounce, Guido S
, with contributions from
Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller,
Ryan Mounce, Guido Sarducci, Dean Scarff, Nils Andreas Svee, Dave Täht,
and Loganaden Velvindron.
Testing from Pete Heist, Georgios Amanakis, and the many other members of
the cake@lists.bufferbloat.net
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 :)
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
I've started looking at what changes are needed before Cake can be
submitted upstream (see the upstream-4.18 branch of the repo).
While looking over the data structures I noticed that struct cake_flow
contains pointers to struct sk_buff instread of using the in-kernel
struct sk_buff_head queueing
Jonathan Morton writes:
>> Based on all this, I propose we change the scaling mechanism so that it
>> is only active in egress mode, and change it from 4 MTUs to 2. I'll
>> merge Kevin's patch to do this unless someone complains loudly :)
>
> I suppose that makes enough
Sebastian Moeller <moell...@gmx.de> writes:
> Hi Toke,
>
>
>
>> On Apr 24, 2018, at 10:47, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>
>> Sebastian Moeller <moell...@gmx.de> writes:
>>
>>>> On Apr 24, 2018, at 01:01, Pete
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
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
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
>>
Sebastian Moeller <moell...@gmx.de> writes:
>> On Apr 24, 2018, at 01:01, Pete Heist <p...@eventide.io> wrote:
>>
>>
>>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>>
>>> Last week we submitted an a
Pete Heist <p...@eventide.io> writes:
>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>
>> Last week we submitted an academic paper describing Cake. A pre-print is
>> now available on arXiv: https://arxiv.org/abs/1804.0761
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
, with contributions from
Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller,
Ryan Mounce, Guido Sarducci, Dean Scarff, Nils Andreas Svee, Dave Täht,
and Loganaden Velvindron.
Testing from Pete Heist, Georgios Amanakis, and the many other members of
the cake@lists.bufferbloat.net
r is Jonathan Morton, with contributions from
Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller,
Ryan Mounce, Guido Sarducci, Dean Scarff, Nils Andreas Svee, Dave Täht,
and Loganaden Velvindron.
Testing from Pete Heist, Georgios Amanakis, and the many other members of
the cake@lists.bufferbloat.net m
.
sch_cake replaces a combination of iptables, tc filter, htb and fq_codel
in the sqm-scripts, with sane defaults and vastly simpler configuration.
Cake's principal author is Jonathan Morton, with contributions from
Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller,
Ryan Mounce, Guido S
Stephen Hemminger <step...@networkplumber.org> writes:
> On Tue, 24 Apr 2018 14:30:46 +0200
> Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>
>> +static void cake_print_json_tin(struct tc_cake_tin_stats *tst, uint version)
>> +{
>> +open_json_obje
Stephen Hemminger <step...@networkplumber.org> writes:
> On Tue, 24 Apr 2018 16:52:57 +0200
> Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>
>> Well, this is leftover from keeping track of different versions of the
>> out-of-tree patch, and we already brok
Georgios Amanakis <gamana...@gmail.com> writes:
> On Tue, 24 Apr 2018 13:44:06 +0200
> Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>
>> +config NET_SCH_CAKE
>> + tristate "Common Applications Kept Enhanced (CAKE)"
>> + help
>
Eric Dumazet <eric.duma...@gmail.com> writes:
> On 04/25/2018 06:42 AM, Toke Høiland-Jørgensen wrote:
>> 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 pres
Pete Heist <p...@eventide.io> writes:
>> On Apr 25, 2018, at 11:15 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>
>> Pete Heist <p...@eventide.io> writes:
>>
>>> I requested a re-build over in the Ubiquiti EdgeOS forums. Between
>
Jonathan Morton writes:
>> On 29 Mar, 2018, at 1:30 am, Bret Towe wrote:
>>
>> ./include/linux/kernel.h:6:10: fatal error: stdarg.h: No such file or
>> directory
>
> I've started seeing the same error on my PowerPC box, running Gentoo.
> It seemed
Jonathan Morton writes:
>> On 30 Mar, 2018, at 11:05 am, Pete Heist wrote:
>>
>> So this mapping from member (subscriber) to their MACs or IPs would need to
>> be configurable somewhere
>
> Yes, I assumed something like that would be required to assign
Bret Towe writes:
> for anyone seeing a compile error like the below on Arch Linux
>
> CC [M] /root/sch_cake/sch_cake.o
> In file included from ./include/linux/list.h:9:0,
> from ./include/linux/module.h:9,
> from
Kevin Darbyshire-Bryant via Cake writes:
> From: Kevin Darbyshire-Bryant
> Subject: bufferbloat still misunderstood & ignored
> To: Cake List
> Date: Wed, 28 Mar 2018 15:46:47 +
>
>
Toke Høiland-Jørgensen <t...@toke.dk> writes:
> George Amanakis <gamana...@gmail.com> writes:
>
>> It seems the change was introduced here:
>> https://patchwork.kernel.org/patch/9671147/
>>
>> I drafted the following very simplistic patch, could someb
Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes:
>> On 12 Mar 2018, at 15:11, Stephen Hemminger <step...@networkplumber.org>
>> wrote:
>>
>> On Mon, 12 Mar 2018 10:56:09 +0100
>> Toke Høiland-Jørgensen <t...@toke.dk> wrote:
&
George Amanakis writes:
> It seems the change was introduced here:
> https://patchwork.kernel.org/patch/9671147/
>
> I drafted the following very simplistic patch, could somebody take a
> look at it?
LGTM. We may want to actually use the extack feature at some point, but
Georgios Amanakis writes:
> #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 12, 0)
> err = nla_parse_nested(tb, TCA_CAKE_MAX, opt, cake_policy);
> -#else
> +#elif LINUX_VERSION_CODE < KERNEL_VERSION(4, 16, 0)
> err = nla_parse_nested(tb, TCA_CAKE_MAX, opt, cake_policy,
Dave Taht writes:
> fprintf(f, " pkts");
> FOR_EACH_TIN(stnc, tst, i)
> - fprintf(f, " %12u", tst->sent.packets);
> + fprintf(f, " %12llu", tst->sent.packets);
> fprintf(f, "\n");
Presumably this can potentially break column
Dave Taht writes:
> the preceding space handles column alignment. the %12 is probably
> going to be misleading.
The space separates columns, the %12 aligns them. So it will break
alignment. But as I said, mostly a cosmetic issue, so probably not
something we should spend a
Toke Høiland-Jørgensen <t...@toke.dk> writes:
> Jonathan Morton <chromati...@gmail.com> writes:
>
>>> On 11 Feb, 2018, at 7:26 pm, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>>
>>> This updates tc to understand the updated cake x
David Miller <da...@davemloft.net> writes:
> From: Toke Høiland-Jørgensen <t...@toke.dk>
> Date: Wed, 25 Apr 2018 15:42:48 +0200
>
>> +static void *cake_zalloc(size_t sz)
>> +{
>> +void *ptr = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN);
>> +
>&
Eric Dumazet <eric.duma...@gmail.com> writes:
> On 04/25/2018 11:34 AM, Toke Høiland-Jørgensen wrote:
>> Eric Dumazet <eric.duma...@gmail.com> writes:
>>
>>> On 04/25/2018 09:52 AM, Jonathan Morton wrote:
>>>>> We can see here the high
David Lang <da...@lang.hm> writes:
> On Tue, 24 Apr 2018, Toke Høiland-Jørgensen wrote:
>
>> Pete Heist <p...@eventide.io> writes:
>>
>>>> On Apr 24, 2018, at 7:58 AM, Jonathan Morton <chromati...@gmail.com> wrote:
>>>>
>>>&g
Eric Dumazet writes:
> On 04/25/2018 09:52 AM, Jonathan Morton wrote:
>>> We can see here the high cost of forcing software GSO :/
>>>
>>> Really, this should be done only :
>>> 1) If requested by the admin ( tc gso )
>>>
>>> 2) If packet size is above a
For those who have not been following the discussion on the upstreaming
patches, here's an update:
- I've just pushed patches to only split GSO packets when shaping below
one gigabit; and hopefully made the overhead compensation code deal
gracefully with GSO packets if someone for some reason
...which means that CAKE is now officially in upstream Linux. Woohoo!
It's even listed at the top of the "Coolest features" list on the
kernelnewbies overview:
https://kernelnewbies.org/Linux_4.19#Better_networking_experience_with_the_CAKE_queue_management_algorithm
Congratulations, and thanks,
Dave Taht writes:
> Well, fq_codel does use a lot less cpu but everything seems slower
I don't suppose 18.06 enables any of the SPECTRE mitigations (was that
an issue on ARM)?
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
Jonathan Morton writes:
> I'm not familiar with precisely what mitigations are now in use on
> ARM. I am however certain that, on a device running only trustworthy
> code (ie. not running a Web browser), mitigating Spectre is
> unnecessary. If an attacker gets into a position to exploit it, he's
Jonathan Morton writes:
>> On 2 Sep, 2018, at 10:37 pm, Dave Taht wrote:
>>
>> Didn't know we had this now.
>>
>> https://www.spinics.net/lists/netdev/msg413986.html
>
> Does that automagically give Cake an idea of the IP addresses
> associated with the packet, for host-fairness purposes? If
We would like the existing community to be kept in the loop for any new
developments on CAKE; and I certainly plan to keep maintaining it. Reflect
this in MAINTAINERS.
Signed-off-by: Toke Høiland-Jørgensen
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b
Pete Heist writes:
>> On Jan 4, 2019, at 11:34 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>> This basically means that we can't use CAKE as a leaf qdisc with GSO
>> splitting as it stands currently. I *think* the solution is for CAKE to
> Jon, is there anything I can check by instrumenting the code somewhere
> specific?
Is there any way you could test with a bulk UDP flow? I'm wondering
whether this is a second-order effect where TCP ACKs are limited in a
way that cause the imbalance? Are you using ACK compression?
-Toke
Pete Heist writes:
> Ok, that fixes the compiler warnings, but I get this now. Same as
> before it’s repeated until reboot, stack sometimes changes but I
> always see sch_hfsc.c:1427 at the beginning:
Hmm, that's odd. Could you try adding this debugging line in
adjust_parent_qlen(), right
On 5 January 2019 11:44:44 CET, Jonathan Morton wrote:
>> On 5 Jan, 2019, at 12:34 am, Toke Høiland-Jørgensen
>wrote:
>>
>> This basically means that we can't use CAKE as a leaf qdisc with GSO
>> splitting as it stands currently. I *think* the solution is for CAK
Pete Heist writes:
>> On Jan 5, 2019, at 2:35 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>>>> On Jan 5, 2019, at 2:10 PM, Toke Høiland-Jørgensen wrote:
>>>>
>>>> Hmm, that's odd. Could you try adding this debug
Pete Heist writes:
> Quick update to the trace because I had to apply the patch manually
> and missed one line to remove (qdisc_tree_reduce_backlog...), just so
> it doesn’t through off the addresses for you, but it still does the
> same thing:
Ah, my bad; you need to replace
Pete Heist writes:
>> On Jan 5, 2019, at 2:10 PM, Toke Høiland-Jørgensen wrote:
>>
>> Hmm, that's odd. Could you try adding this debugging line in
>> adjust_parent_qlen(), right before the sch->q.qlen += n line:
>>
>> net_info_ratelimited(&q
Pete Heist writes:
> That first bug report looks decidedly similar to mine, but Toke would
> have to comment on the specifics. So far I see the patch to
> sch_codel.c you mentioned and another two-liner to remove the warning
> in hfsc.c (https://patchwork.ozlabs.org/patch/933611/). It would be
>
Pete Heist writes:
>> On Jan 5, 2019, at 9:10 PM, Toke Høiland-Jørgensen wrote:
>>
>> Well, it's the same WARN_ON(), and if that patch had been applied,
>> debugging our issue would have been a lot harder, I think.
>
> Yikes, this is what I mean. I’d
Pete Heist writes:
>> On Jan 5, 2019, at 11:27 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>>>> On Jan 5, 2019, at 9:10 PM, Toke Høiland-Jørgensen wrote:
>>>>
>>>> Well, it's the same WARN_ON(), and if that patc
Pete Heist writes:
> Lastly, is using cake as a leaf to htb risky until a fix is made? I’ve
> been doing that for a while without any apparent issues, though I’m
> hesitating now to try that in a production environment.
Hmm, that's a good question. I would expect so; but I would also expect
the
Jonathan Morton writes:
>>> Yes, exactly. Would be interesting to hear what Jonathan, Toke and
>>> others think. I want to see if fairness is preserved in this case with
>>> sparse flows only. Could flent do this?
>>
>> Well, sparse flows are (by definition) not building a queue, so it
>>
Sebastian Moeller writes:
> Hi Toke,
>
>> On Jan 18, 2019, at 14:33, Toke Høiland-Jørgensen wrote:
>>
>> Georgios Amanakis writes:
>>
>>> Yes, exactly. Would be interesting to hear what Jonathan, Toke and
>>> others think. I want to see if fa
George Amanakis writes:
> A better version of the patch for testing.
So basically, you're changing the host fairness algorithm to only
consider bulk flows instead of all active flows to that host, right?
Seems reasonable to me. Jonathan, any opinion?
-Toke
Georgios Amanakis writes:
> Yes, exactly. Would be interesting to hear what Jonathan, Toke and
> others think. I want to see if fairness is preserved in this case with
> sparse flows only. Could flent do this?
Well, sparse flows are (by definition) not building a queue, so it
doesn't really
Hey everyone
I'm defending my PhD thesis this Friday (Nov 23rd), which contains
content relevant to all three lists (hence the three-way cross post).
In case anyone is interested in watching, I'm setting up a live stream
on Youtube, see link below. The defence starts at 09:15 CET (UTC+1), but
Georgios Amanakis writes:
> Thank you very much for doing this, Toke! All the best of luck on
> Friday!!!
Thanks! :)
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
Fabian Ruffy writes:
> Hello,
>
> this is a somewhat esoteric question. I am trying to actually force
> bufferbloat
> in an emulation setup I am using. I set up a dumbbell topology and push
> traffic
> through it, causing congestion at the central link. I use this setup to
> compare
>
Pete Heist writes:
> Your patch in the latest kernels looks simpler. Bringing the patch
> back to prior kernel versions would be appreciated, but I can
> understand how 3.16 becomes less and less relevant as time goes on,
> although, it’s not at end of life yet. :)
Could you try the latest git
Pete Heist writes:
>> On Jan 6, 2019, at 9:56 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>>> Lastly, is using cake as a leaf to htb risky until a fix is made? I’ve
>>> been doing that for a while without any apparent is
From: Toke Høiland-Jørgensen
Parent qdiscs may dereference the pointer to the enqueued skb after
enqueue. However, both CAKE and TBF call consume_skb() on the original skb
when splitting GSO packets, leading to a potential use-after-free in the
parent. Fix this by avoiding dereferencing the skb
From: Toke Høiland-Jørgensen
To ensure parent qdiscs have the same notion of the number of enqueued
packets even after splitting a GSO packet, update the qdisc tree with the
number of packets that was added due to the split.
Signed-off-by: Toke Høiland-Jørgensen
---
net/sched/sch_cake.c | 5
From: Toke Høiland-Jørgensen
With GSO splitting in sch_cake, we can decrease as well as increase the
qlen. To make it possible to signal this up the qdisc tree, change
qdisc_tree_reduce_backlog() to accept signed integer values as the number
of packets and bytes to reduce the backlog by.
Signed
the report, I also noticed that several qdiscs would
dereference the skb pointer after dequeue, which is potentially
problematic since the GSO splitting code also frees the original skb.
See the individual patches in the series for details.
Toke Høiland-Jørgensen (4):
sched: Avoid dereferencing skb
Pete Heist writes:
>> On Jan 4, 2019, at 10:34 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>>> Ok, the lockup goes away if you use no-split-gso on the cake qdiscs for the
>>> default traffic (noted below in the drr and hfsc cases
Pete Heist writes:
>> On Jan 3, 2019, at 12:03 PM, Toke Høiland-Jørgensen wrote:
>>
>>> Jon, is there anything I can check by instrumenting the code somewhere
>>> specific?
>>
>> Is there any way you could test with a bulk UDP flow? I'm wondering
>
David Miller writes:
> From: Toke Høiland-Jørgensen
> Date: Mon, 7 Jan 2019 20:47:29 +0100
>
>> This series fixes a couple of issues exposed by running sch_cake as a
>> leaf qdisc in an HFSC tree, which were discovered and reported by Pete
>> Heist. The interaction b
Pete Heist writes:
>> On Jan 8, 2019, at 11:27 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>>> Your patch in the latest kernels looks simpler. Bringing the patch
>>> back to prior kernel versions would be appreciated, but I can
>
Cong Wang writes:
> On Mon, Jan 7, 2019 at 11:50 AM Toke Høiland-Jørgensen wrote:
>> @@ -1254,7 +1256,7 @@ static int qfq_enqueue(struct sk_buff *skb, struct
>> Qdisc *sch,
>> if (cl->qdisc->q.qlen != 1) {
>> if (unlikely(skb
Pete Heist writes:
> Ok, the lockup goes away if you use no-split-gso on the cake qdiscs for the
> default traffic (noted below in the drr and hfsc cases with "!!! must use
> no-split-gso here !!!"). Only I’d like my 600 μs back. :)
>
> This smells of a bug Toke fixed on Sep 12, 2018 in
>
Ruben writes:
> Hey guys,
>
> I've already mentioned this in a response to dtaht on GitHub, but here
> again for everyone:
>
> I was wondering if it's possible to extend the tin statistics by
> packets for backlog.
Why do you need packets when there's already bytes?
> Also I haven't found
On 13 September 2018 16:11:18 CEST, Eric Dumazet wrote:
>
>
>On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
>> When splitting a GSO segment that consists of encapsulated packets,
>the
>> skb->mac_len of the segments can end up being set wrong, causing
>pack
Pv4 and IPv6
gso_segment handlers, after they modify the network_header.
Many thanks to Eric Dumazet for his help in identifying the cause of
the bug.
Acked-by: Dave Taht
Reviewed-by: Eric Dumazet
Signed-off-by: Toke Høiland-Jørgensen
---
v2:
- Properly credit Eric for his help
- Add review and
Similar to the previous patch for no-split-gso, the negative keywords for
'nat', 'wash' and 'ack-filter' were not printed either. Add those well.
Signed-off-by: Toke Høiland-Jørgensen
---
tc/q_cake.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tc/q_cake.c b/tc
Ruben writes:
> Hey Toke,
>
> Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen :
>
>
> Ruben writes:
>
> > Hey Toke,
> >
> > Thanks for your fast response!
> >
> > Am 13.09.2018 12:27 schrieb Toke Høiland-Jø
Ruben writes:
> Hey Toke,
>
> Thanks for your fast response!
>
> Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen :
>
>
> Ruben writes:
>
> > Hey guys,
> >
> > I've already mentioned this in a response to dtaht on GitHub, but here
Kevin Darbyshire-Bryant writes:
> 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
This adds support for the newly added fwmark option to CAKE, which allows
overriding the tin selection from the per-packet firewall marks. The fwmark
field is a bitmask that is applied to the fwmark to select the tin.
Signed-off-by: Toke Høiland-Jørgensen
---
man/man8/tc-cake.8 | 16
We shouldn't be using skb->protocol directly as that will miss cases with
hardware-accelerated VLAN tags. Use the helper instead to get the right
protocol number.
Reported-by: Kevin Darbyshire-Bryant
Signed-off-by: Toke Høiland-Jørgensen
---
net/sched/sch_cake.c |2 +-
1 file changed
There is not actually any guarantee that the IP headers are valid before we
access the DSCP bits of the packets. Fix this using the same approach taken
in sch_dsmark.
Reported-by: Kevin Darbyshire-Bryant
Signed-off-by: Toke Høiland-Jørgensen
---
net/sched/sch_cake.c | 11 +++
1 file
if that's OK with you?
-Toke
---
Toke Høiland-Jørgensen (2):
sch_cake: Use tc_skb_protocol() helper for getting packet protocol
sch_cake: Make sure we can write the IP header before changing DSCP bits
net/sched/sch_cake.c | 13 -
1 file changed, 12 insertions(+), 1
Stephen Hemminger writes:
> On Thu, 04 Apr 2019 22:44:33 +0200
> Toke Høiland-Jørgensen wrote:
>
>> Stephen Hemminger writes:
>>
>> > On Thu, 04 Apr 2019 15:01:33 +0200
>> > Toke Høiland-Jørgensen wrote:
>> >
>> >>
Commit bbd669a868bba591ffd38b7bc75a7b361bb54b04 upstream.
We shouldn't be using skb->protocol directly as that will miss cases with
hardware-accelerated VLAN tags. Use the helper instead to get the right
protocol number.
Reported-by: Kevin Darbyshire-Bryant
Signed-off-by: Toke Høiland-Jørgen
Hi Greg
This series contains backports for a couple of fixes to sch_cake that was just
merged for 5.1. This series backports an earlier refactoring commit, which makes
the fixes themselves apply cleanly from upstream.
-Toke
---
Toke Høiland-Jørgensen (3):
sch_cake: Simplify logic
Greg Kroah-Hartman writes:
> On Fri, Apr 05, 2019 at 02:13:18PM +0200, Toke Høiland-Jørgensen wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Fri, Apr 05, 2019 at 12:28:21PM +0200, Toke Høiland-Jørgensen wrote:
>> >> Hi Greg
>> >>
>> &
Stephen Hemminger writes:
> On Thu, 04 Apr 2019 15:01:33 +0200
> Toke Høiland-Jørgensen wrote:
>
>> static u8 cake_handle_diffserv(struct sk_buff *skb, u16 wash)
>> {
>> +int wlen = skb_network_offset(skb);
>
> In theory this could be negative, you
> 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 impact is a
single check it might actually be acceptable
> actually I may
Kevin Darbyshire-Bryant writes:
> 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
Hmm, not
Kevin Darbyshire-Bryant writes:
>> 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, real
Kevin Darbyshire-Bryant writes:
>> On 3 Mar 2019, at 12:22, John Sager wrote:
>>
>> If you are going to do that, I would suggest using a few of the upper bits
>> of the 32-bit fwmark/connmark space available, rather than the lowest bits.
>> Then that would allow to use fwmarks other purposes,
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:
>>>
>>> The very bad idea:
>>>
>>> And it’s bad ‘cos it’s sort of incompatible with the existing fwmark
>>> implementation as described
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, at 08:39, Pete Heist wrote:
>>>>
>>>>
>>>>> On Mar 3, 2019, at
301 - 400 of 579 matches
Mail list logo