Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

[Alan Jenkins]

On 14/05/15 11:53, Jonathan Morton wrote:
>> On 14 May, 2015, at 13:50, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
>>
>> generic-receive-offload: on
> This implies that adding GRO peeling to cake might be a worthwhile priority.
>
>   - Jonathan Morton

Ah, not on my account, it seems.

# tc -stat qdisc |grep maxpacket
   maxpacket 590 drop_overlimit 0 new_flow_count 1 ecn_mark 0
   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
...
   maxpacket 1696 drop_overlimit 0 new_flow_count 305 ecn_mark 0
   maxpacket 1749 drop_overlimit 0 new_flow_count 274 ecn_mark 0

Alan

Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

[Jonathan Morton]

> On 14 May, 2015, at 16:09, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
> 
> On 14/05/15 11:53, Jonathan Morton wrote:
>>> On 14 May, 2015, at 13:50, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
>>> 
>>> generic-receive-offload: on

>> This implies that adding GRO peeling to cake might be a worthwhile priority.
>> 
>>  - Jonathan Morton
> 
> Ah, not on my account, it seems.
> 
> # tc -stat qdisc |grep maxpacket
>  maxpacket 590 drop_overlimit 0 new_flow_count 1 ecn_mark 0
>  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
> ...
>  maxpacket 1696 drop_overlimit 0 new_flow_count 305 ecn_mark 0
>  maxpacket 1749 drop_overlimit 0 new_flow_count 274 ecn_mark 0

A maxpacket of 1749 *does* imply that GRO or GSO is in use.  Otherwise I’d expect to see 1514 or less.

 - Jonathan Morton

Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

[Alan Jenkins]

On 14/05/15 14:14, Jonathan Morton wrote:
>
>>> This implies that adding GRO peeling to cake might be a worthwhile priority.
>>>
>>>   - Jonathan Morton
>> Ah, not on my account, it seems.
>>
>> # tc -stat qdisc |grep maxpacket
>>   maxpacket 590 drop_overlimit 0 new_flow_count 1 ecn_mark 0
>>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>> ...
>>   maxpacket 1696 drop_overlimit 0 new_flow_count 305 ecn_mark 0
>>   maxpacket 1749 drop_overlimit 0 new_flow_count 274 ecn_mark 0
> A maxpacket of 1749 *does* imply that GRO or GSO is in use.  Otherwise I’d expect to see 1514 or less.
>
>   - Jonathan Morton

Look at the exact difference between the two maxpackets :p (without 
getting into why it's there).  It must be including all the ATM 
estimation.  For GSO we should be seeing 2x or more... not a multiplier 
of 53/48.

Alan

Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

[Dave Taht]

On Thu, May 14, 2015 at 6:35 AM, Alan Jenkins
<alan.christopher.jenkins@gmail.com> wrote:
> On 14/05/15 14:14, Jonathan Morton wrote:
>>
>>
>>>> This implies that adding GRO peeling to cake might be a worthwhile
>>>> priority.

Strike "might".

I saw 64k sized packets out of the GRO implementation on the mvneta
driver on the linksys 1900ac.
I think this explains a lot about the performance of the qos system on
that box's native firmware, dropping
big chunks and not fq-ing well.

disabling GRO packets on all interfaces is hard to get right, and has
a significant cost if
you have more than one interface (as in the edgerouters).

So yes, peeling.

Also I note that at the higher inbound rates (e.g. 100mbit+) policing
is not horrible.
let me discuss that in a different mail.


>>>>
>>>>   - Jonathan Morton
>>>
>>> Ah, not on my account, it seems.
>>>
>>> # tc -stat qdisc |grep maxpacket
>>>   maxpacket 590 drop_overlimit 0 new_flow_count 1 ecn_mark 0
>>>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>> ...
>>>   maxpacket 1696 drop_overlimit 0 new_flow_count 305 ecn_mark 0
>>>   maxpacket 1749 drop_overlimit 0 new_flow_count 274 ecn_mark 0
>>
>> A maxpacket of 1749 *does* imply that GRO or GSO is in use.  Otherwise I’d
>> expect to see 1514 or less.
>>
>>   - Jonathan Morton
>
>
> Look at the exact difference between the two maxpackets :p (without getting
> into why it's there).  It must be including all the ATM estimation.  For GSO
> we should be seeing 2x or more... not a multiplier of 53/48.
>
> Alan
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Ah - looking at it from that perspective, your largest packet includes a
1500 byte payload, 40 bytes of PPPoE framing, and 44 more bytes of AAL5
padding, all wrapped up in 33 ATM cells. With even slightly less overhead
or a fractionally reduced payload, you'd go down to 32 cells.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 346 bytes --]

Re: [Cerowrt-devel] [Cake] openwrt build with latest cake and other qdiscs

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

A 64k aggregate would be broken up at any speed below half a gigabit. So
the 1ms heuristic seems sane from that perspective.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 183 bytes --]