On Fri, 2018-07-27 at 21:58 +0300, Jonathan Morton wrote:
> >
> > We have some deployments with multiple access technologies (eg
> > DOCSIS,
> > DSL and wireless) behind the same box so per customer overhead
> > would be
> > useful.
>
> The design I presently have in mind would allow setting the
Looks like even big ISPs could potentially benefit from this sort of thing:
https://www.youtube.com/watch?v=b3U-sSADYYY
- Jonathan Morton
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
Pete Heist writes:
>> On Jul 30, 2018, at 1:28 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>>> Couldn’t it still be made so now? Not sure of the performance impact
>>> though.
>>
>> It could, but it would take some care. There's the issue of
>> power-of-two-ness and avoidin
> On Jul 30, 2018, at 1:28 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
>> Couldn’t it still be made so now? Not sure of the performance impact
>> though.
>
> It could, but it would take some care. There's the issue of
> power-of-two-ness and avoiding divides that Jonathan point
Pete Heist writes:
>> On Jul 30, 2018, at 12:55 PM, Toke Høiland-Jørgensen wrote:
>>>
>>> I believe all you needto do is change the following in scg_cake.c:
>>> #define CAKE_QUEUES (1024)
>>>
>>> Now I heard reports that above a certain number this breaks, but it
>>> might be enough for 32K or
The big thing to note here is that it needs to be a power of two, so that
the modulo operation on the hash table is really a mask operation, not a
divide. It's easy to tell the compiler that if it's a compile time
constant. Needs a lot more finesse if it's not.
But it could reasonably be configu
> On Jul 30, 2018, at 12:55 PM, Toke Høiland-Jørgensen wrote:
>>
>> I believe all you needto do is change the following in scg_cake.c:
>> #define CAKE_QUEUES (1024)
>>
>> Now I heard reports that above a certain number this breaks, but it
>> might be enough for 32K or even 64k, or ~32 to 64 que
Sebastian Moeller writes:
> Hi Pete
>
>> On Jul 30, 2018, at 11:14, Pete Heist wrote:
>>
>>
>>> On Jul 29, 2018, at 9:14 PM, Toke Høiland-Jørgensen wrote:
Caveats that I know of:
- Limited to 1024 members
- No fairness between flows
>>>
>>> You could assign more than one
> On Jul 30, 2018, at 12:09 PM, Sebastian Moeller wrote:
>>>
>>> You could assign more than one queue per customer and hash traffic
>>> between them in BPF…
>>
>> True. There will always be that limit of 1024 (in my case I’ll need 800).
>
> I believe all you needto do is change the following
Hi Pete
> On Jul 30, 2018, at 11:14, Pete Heist wrote:
>
>
>> On Jul 29, 2018, at 9:14 PM, Toke Høiland-Jørgensen wrote:
>>>
>>> Caveats that I know of:
>>> - Limited to 1024 members
>>> - No fairness between flows
>>
>> You could assign more than one queue per customer and hash traffic
>> b
> On Jul 29, 2018, at 9:14 PM, Toke Høiland-Jørgensen wrote:
>>
>> Caveats that I know of:
>> - Limited to 1024 members
>> - No fairness between flows
>
> You could assign more than one queue per customer and hash traffic
> between them in BPF…
True. There will always be that limit of 1024 (in
On Sat, Jul 28, 2018 at 10:38 AM Pete Heist wrote:
>
>
> On Jul 28, 2018, at 10:56 AM, Toke Høiland-Jørgensen wrote:
>
> Note that with the existing tc classifier stuff we already added to
> Cake, we basically have this already (eBPF can map traffic to tin and
> flow however it pleases).
>
>
> So
Pete Heist writes:
>> On Jul 28, 2018, at 8:12 PM, Toke Høiland-Jørgensen wrote:
>>
>> Priority field sets tin, class sets flow. Both need the qdisc is as its
>> major number, iirc. And both can be set from the same bpf filter which can
>> be run in direct action mode...
>
> This works for me
> On Jul 28, 2018, at 8:12 PM, Toke Høiland-Jørgensen wrote:
>
> Priority field sets tin, class sets flow. Both need the qdisc is as its major
> number, iirc. And both can be set from the same bpf filter which can be run
> in direct action mode...
This works for me. :)
I only tested so far b
On 28 July 2018 19:53:58 CEST, Jonathan Morton wrote:
>>> Note that with the existing tc classifier stuff we already added to
>>> Cake, we basically have this already (eBPF can map traffic to tin
>and
>>> flow however it pleases).
>>
>> Sorry, this just jostled in my brain now that I may be abl
Priority field sets tin, class sets flow. Both need the qdisc is as its major
number, iirc. And both can be set from the same bpf filter which can be run in
direct action mode...
-Toke
On 28 July 2018 19:56:35 CEST, Dave Taht wrote:
>https://github.com/iovisor/bcc/blob/master/src/cc/compat/lin
On Sat, Jul 28, 2018 at 10:54 AM Jonathan Morton wrote:
>
> >> Note that with the existing tc classifier stuff we already added to
> >> Cake, we basically have this already (eBPF can map traffic to tin and
> >> flow however it pleases).
> >
> > Sorry, this just jostled in my brain now that I may b
https://github.com/iovisor/bcc/blob/master/src/cc/compat/linux/bpf.h#L
says you can get at the priority field.
On Sat, Jul 28, 2018 at 10:52 AM Dave Taht wrote:
>
> On Sat, Jul 28, 2018 at 10:38 AM Pete Heist wrote:
> >
> >
> > On Jul 28, 2018, at 10:56 AM, Toke Høiland-Jørgensen wrote:
> >
>> Note that with the existing tc classifier stuff we already added to
>> Cake, we basically have this already (eBPF can map traffic to tin and
>> flow however it pleases).
>
> Sorry, this just jostled in my brain now that I may be able to implement
> member fairness today, based on what you wrot
On Sat, Jul 28, 2018 at 10:38 AM Pete Heist wrote:
>
>
> On Jul 28, 2018, at 10:56 AM, Toke Høiland-Jørgensen wrote:
>
> Note that with the existing tc classifier stuff we already added to
> Cake, we basically have this already (eBPF can map traffic to tin and
> flow however it pleases).
>
>
> So
> On Jul 28, 2018, at 10:56 AM, Toke Høiland-Jørgensen wrote:
>
> Note that with the existing tc classifier stuff we already added to
> Cake, we basically have this already (eBPF can map traffic to tin and
> flow however it pleases).
Sorry, this just jostled in my brain now that I may be able t
> On Jul 28, 2018, at 5:04 PM, Dave Taht wrote:
>
> I'm lovin this discussion.
>
> a couple notes:
>
> 1) IF you go the full monty and create an isp oriented qdisc, for
> gawd's sake come up with a googleable name.
> Things like pie, cake, bobbie, tart are good codenames, fq_codel
> horrific,
> On Jul 28, 2018, at 10:06 AM, Jonathan Morton wrote:
>
> This sounds like a relatively complex network topology, in which there are a
> lot of different potential bottlenecks, depending on the dynamic state of the
> network.
It is, which is the argument from those who want a more centralized
On Sat, Jul 28, 2018 at 9:19 AM Jonathan Morton wrote:
>
> > On 28 Jul, 2018, at 6:04 pm, Dave Taht wrote:
> >
> > for gawd's sake come up with a googleable name.
> > Things like pie, cake, bobbie, tart are good codenames, fq_codel
> > horrific, "streamboost" is a canonical example of a great nam
On Sat, Jul 28, 2018 at 9:11 AM Jonathan Morton wrote:
>
> > On 28 Jul, 2018, at 6:51 pm, Dave Taht wrote:
> >
> > That's also pretty low end. On the high end nowadays there's stuff like
> > this:
> >
> > https://www.amazon.com/Intel-Xeon-E5-2698-Hexadeca-core-Processor/dp/B00PDD1QES
>
> Intel i
> On 28 Jul, 2018, at 6:04 pm, Dave Taht wrote:
>
> for gawd's sake come up with a googleable name.
> Things like pie, cake, bobbie, tart are good codenames, fq_codel
> horrific, "streamboost" is a canonical example of a great name.
Suggestions on a postcard.
- Jonathan Morton
___
> On 28 Jul, 2018, at 6:51 pm, Dave Taht wrote:
>
> That's also pretty low end. On the high end nowadays there's stuff like this:
>
> https://www.amazon.com/Intel-Xeon-E5-2698-Hexadeca-core-Processor/dp/B00PDD1QES
Intel is no longer high-end for x86 CPUs. Not all of the market has realised
th
On Thu, Jul 26, 2018 at 11:07 AM Dan Siemon wrote:
>
> On Thu, 2018-07-26 at 08:48 -0700, Dave Taht wrote:
> > On Thu, Jul 26, 2018 at 8:46 AM Dan Siemon wrote:
> > >
> > > Tiny bit of self promotion here but Preseem (
> > > https://www.preseem.com)
> > > is a transparent bridge that leverages HT
I'm lovin this discussion.
a couple notes:
1) IF you go the full monty and create an isp oriented qdisc, for
gawd's sake come up with a googleable name.
Things like pie, cake, bobbie, tart are good codenames, fq_codel
horrific, "streamboost" is a canonical example of a great name. At the
moment I
Jonathan Morton writes:
> Yes, eBPF does seem to be a good fit for that.
>
> So in summary, the logical flow of a packet should be:
>
> 1: Map dst or src IP to subscriber (eBPF).
> 2: Map subscriber to speed/overhead tier (eBPF).
> 3: (optional) Classify Diffserv (???).
> 4: Enqueue per flow, han
> There are some older backhaul routers still with 2.6.26.8(!) although those
> are being phased out so don’t count them. More current ones use 3.16.7 and
> there’s some discussion but I’m not sure what/when the upgrade plan is. I
> think the Internet router uses a more modern Debian 9 which is
> On Jul 26, 2018, at 11:38 PM, Jonathan Morton wrote:
>
> It would also be valuable to have a firmer handle on the actual requirements
> in the field. For example, if it is feasible to focus only on current Linux
> kernels, then a lot of backwards compatibility cruft can be excised when
> im
> On 27 Jul, 2018, at 5:04 pm, Dan Siemon wrote:
>
> Obviously I can't speak for other potential users but we follow the
> upstream kernel very aggressively and have no interest in porting
> something like this to older kernels.
That's a useful data point. Honestly it shouldn't be too difficult
On Fri, 2018-07-27 at 00:38 +0300, Jonathan Morton wrote:
> It would also be valuable to have a firmer handle on the actual
> requirements in the field. For example, if it is feasible to focus
> only on current Linux kernels, then a lot of backwards compatibility
> cruft can be excised when import
> On Jul 26, 2018, at 11:38 PM, Jonathan Morton wrote:
>
>> On 27 Jul, 2018, at 12:09 am, Toke Høiland-Jørgensen wrote:
>>
>> Cool. No promises as to when (or even if) I get around to looking at
>> this; but will ping you when/if I do :)
>
> Alternatively, I could look into it. I have time,
> On 27 Jul, 2018, at 12:09 am, Toke Høiland-Jørgensen wrote:
>
I haven't had time to try Cake in this context yet but hope to get to
that in the next couple months. I believe this will require one Cake
instance per-subscriber like we do with FQ-CoDel today.
>>>
>>> Yup, currently
Dan Siemon writes:
> On Thu, 2018-07-26 at 19:42 +0200, Toke Høiland-Jørgensen wrote:
>> Dan Siemon writes:
>>
>> > I haven't had time to try Cake in this context yet but hope to get
>> > to
>> > that in the next couple months. I believe this will require one
>> > Cake
>> > instance per-subscri
On Thu, 2018-07-26 at 19:42 +0200, Toke Høiland-Jørgensen wrote:
> Dan Siemon writes:
>
> > I haven't had time to try Cake in this context yet but hope to get
> > to
> > that in the next couple months. I believe this will require one
> > Cake
> > instance per-subscriber like we do with FQ-CoDel t
On Thu, 2018-07-26 at 08:48 -0700, Dave Taht wrote:
> On Thu, Jul 26, 2018 at 8:46 AM Dan Siemon wrote:
> >
> > Tiny bit of self promotion here but Preseem (
> > https://www.preseem.com)
> > is a transparent bridge that leverages HTB/FQ-CoDel to make
> > subscriber plan enforcement provide much b
Dan Siemon writes:
> Tiny bit of self promotion here but Preseem (https://www.preseem.com)
> is a transparent bridge that leverages HTB/FQ-CoDel to make subscriber
> plan enforcement provide much better QoE. Leaving enforcement up to
> the deep queues in most network equipment has comparably very
On Thu, Jul 26, 2018 at 8:46 AM Dan Siemon wrote:
>
> Tiny bit of self promotion here but Preseem (https://www.preseem.com)
> is a transparent bridge that leverages HTB/FQ-CoDel to make subscriber plan
> enforcement provide much better QoE. Leaving enforcement up to the deep
> queues in most net
Tiny bit of self promotion here but Preseem (https://www.preseem.com)
is a transparent bridge that leverages HTB/FQ-CoDel to make subscriber plan
enforcement provide much better QoE. Leaving enforcement up to the deep queues
in most network equipment has comparably very bad results. We focus on W
On Tue, Jul 17, 2018 at 12:24 AM Felix Resch wrote:
>
> since commercial interest is involved, see here
> https://lists.bufferbloat.net/pipermail/cake/2018-June/003861.html
I grew that list substantially in the ending talk. It was motivating.
:) I am thinking of doing something similar (with edi
since commercial interest is involved, see here
https://lists.bufferbloat.net/pipermail/cake/2018-June/003861.html
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
I asked the same not long ago. It's currently limited to a global speed
shared by all IP address so you must use a veth with cake config by ip
address.
I would like to eventually see a option in cake with src, dst, src-dual and
dst-dual host mode with bandwidith by ip-address and use a veth with
d
> On 16 Jul, 2018, at 9:39 pm, Mike wrote:
>
> Is it possible to use cake on one server to provide shaping and QOS to 1000’s
> of users through a transparent bridge with various speed plans. I know one
> company is doing it using fq_codel but I have been unable to locate any
> resources on ho
Is it possible to use cake on one server to provide shaping and QOS to 1000’s
of users through a transparent bridge with various speed plans. I know one
company is doing it using fq_codel but I have been unable to locate any
resources on how to get it to work on more than one speed plan. Any h
47 matches
Mail list logo
