> On 7 Jan, 2018, at 10:19 am, Sebastian Moeller wrote:
>
> We really need this "behave like all other qdiscs" mode so that cake can be
> used with "tc stab" exactly as awkward as all other qdiscs, it would be
> really unfortunate if cake would require different "tc stab" magic than say
> HTB+
Hi Jonathan,
> On Jan 7, 2018, at 01:33, Jonathan Morton wrote:
>
>> On 7 Jan, 2018, at 12:46 am, Sebastian Moeller wrote:
>>
>> I thibk cake should offer a mode in which it behaves as all other qdiscs
>> currently do and not do auto correction at all and a mode where it corrects
>> for the
> On 7 Jan, 2018, at 12:46 am, Sebastian Moeller wrote:
>
> I thibk cake should offer a mode in which it behaves as all other qdiscs
> currently do and not do auto correction at all and a mode where it corrects
> for the right amount, but keeping the current ake cbehavior will not help
> anybo
Hi Jonathan,
> On Jan 6, 2018, at 21:44, Jonathan Morton wrote:
>
>> On 23 Dec, 2017, at 11:03 pm, Sebastian Moeller wrote:
>>
>> just had a look for hard_header_len in the linux kernel:
>> linux/include/linux/netdevice.h:
>> * @hard_header_len: Maximum hardware header length.
>> * @
> On 23 Dec, 2017, at 11:03 pm, Sebastian Moeller wrote:
>
> just had a look for hard_header_len in the linux kernel:
> linux/include/linux/netdevice.h:
> * @hard_header_len: Maximum hardware header length.
> * @min_header_len: Minimum hardware header length
>
> this seems to corrobor
Hi Kevin, hi all,
On December 24, 2017 11:46:31 AM GMT+01:00, Kevin Darbyshire-Bryant
wrote:
>
>
>> On 24 Dec 2017, at 10:39, Jonathan Morton
>wrote:
>>
>> If you combine the 'raw' keyword with an overhead spec, that disables
>the hard_header_len compensation.
>>
>> - Jonathan Morton
>
>Indee
Hi Kevin,
On December 24, 2017 11:34:15 AM GMT+01:00, Kevin Darbyshire-Bryant
wrote:
>
>
>> On 23 Dec 2017, at 21:03, Sebastian Moeller wrote:
>>
>> Hi All,
>>
>> just had a look for hard_header_len in the linux kernel:
>> linux/include/linux/netdevice.h:
>> * @hard_header_len: Maximum h
> On 24 Dec 2017, at 10:39, Jonathan Morton wrote:
>
> If you combine the 'raw' keyword with an overhead spec, that disables the
> hard_header_len compensation.
>
> - Jonathan Morton
Indeed. I think all I’m proving is ‘make something idiot proof…..they’ll only
go and improve the idiot’… i.
If you combine the 'raw' keyword with an overhead spec, that disables the
hard_header_len compensation.
- Jonathan Morton
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
> On 23 Dec 2017, at 21:03, Sebastian Moeller wrote:
>
> Hi All,
>
> just had a look for hard_header_len in the linux kernel:
> linux/include/linux/netdevice.h:
> * @hard_header_len: Maximum hardware header length.
> * @min_header_len: Minimum hardware header length
>
> this seems
> On 23 Dec, 2017, at 11:03 pm, Sebastian Moeller wrote:
>
> just had a look for hard_header_len in the linux kernel:
> linux/include/linux/netdevice.h:
> * @hard_header_len: Maximum hardware header length.
> * @min_header_len: Minimum hardware header length
>
> this seems to corrobor
Hi All,
just had a look for hard_header_len in the linux kernel:
linux/include/linux/netdevice.h:
* @hard_header_len: Maximum hardware header length.
* @min_header_len: Minimum hardware header length
this seems to corroborate our observation that hard_header_len is not a
veridical re
Hi Ryan,
> On Dec 23, 2017, at 14:11, Ryan Mounce wrote:
>
> On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE
> interfaces,
That is the traditional indicator, that the kernel does not automatically add
overhead for ppp interfaces, and that still seems valid.
> for both egress (har
On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE
interfaces, for both egress (hard_header_len = 26) and ingress via ifb
(hard_header_len = 14). At least this issue had been offset by the
double-overhead bug for a little while :)
Regards,
Ryan Mounce
On 23 December 2017 at 23:25, Sebas
> On Dec 23, 2017, at 10:59, Andy Furniss wrote:
>
> Sebastian Moeller wrote:
>
>>> qdisc cake 1: dev enp6s0 root refcnt 2 bandwidth 19690Kbit diffserv3
>>> triple-isolate rtt 100.0ms noatm overhead 48 via-ethernet total_overhead 48
>>> hard_header_len 14
>> This looks like expected, the
Sebastian Moeller wrote:
qdisc cake 1: dev enp6s0 root refcnt 2 bandwidth 19690Kbit diffserv3
triple-isolate rtt 100.0ms noatm overhead 48 via-ethernet total_overhead 48
hard_header_len 14
This looks like expected, the in-kernel overhead is added to the
specified overhead, just like
Hi Andy,
> On Dec 23, 2017, at 00:38, Andy Furniss wrote:
>
> 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 cake_overhead.
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 cake_overhead.
skb_ack_filter variable replaced with ack
Fixed. At one point cake_advance_sh
Thx andy and jon for the bisect and the fix. I am deep in the jungles
of nicaragua at the moment, and won't be doing much with any codebases
until I get out in mid january - the internet is terrible here, and
where I am hasn't had power in a couple days, either!
Expect sparse emails from me til th
> On 22 Dec 2017, at 10:00, Jonathan Morton wrote:
>
> Git seems to regularly get confused when similar code changes occur in
> parallel in different branches. In this case, I had the original version of
> ingress mode while the public tree had the reconstructed version - almost
> identical
Git seems to regularly get confused when similar code changes occur in
parallel in different branches. In this case, I had the original version
of ingress mode while the public tree had the reconstructed version -
almost identical, but still constituting a merge conflict. I really don't
know why
> 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 cake_overhead.
>> skb_ack_filter variable replaced wi
> 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 cake_overhead.
>skb_ack_filter variable replaced with ack
Fixed. At one point cake_advance_shaper() was still
Andy Furniss wrote:
Been running a cake cobolt from april for some time using
tc qdisc add dev ppp0 handle 1:0 root cake bandwidth 19690kbit raw
overhead 34 diffserv4 dual-srchost nat rtt 200ms
tc -s qdisc ls dev ppp0 (ppp0 is pppoe)
qdisc cake 1: root refcnt 2 bandwidth 19690Kbit diffserv4
Been running a cake cobolt from april for some time using
tc qdisc add dev ppp0 handle 1:0 root cake bandwidth 19690kbit raw
overhead 34 diffserv4 dual-srchost nat rtt 200ms
tc -s qdisc ls dev ppp0 (ppp0 is pppoe)
qdisc cake 1: root refcnt 2 bandwidth 19690Kbit diffserv4 dual-srchost
nat rtt
25 matches
Mail list logo
