[Cerowrt-devel] some kernel updates

[Sebastian Moeller]

Hi Jesper hi List,


On Aug 23, 2013, at 09:27 , Jesper Dangaard Brouer <jbrouer at redhat.com> wrote:

> On Thu, 22 Aug 2013 22:13:52 -0700
> Dave Taht <dave.taht at gmail.com> wrote:
> 
>> On Thu, Aug 22, 2013 at 5:52 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>>> Hi List, hi Jesper,
>>> 
>>> So I tested 3.10.9-1 to assess the status of the HTB atm link layer
>>> adjustments to see whether the recent changes resurrected this feature.
>>>        Unfortunately the htb_private link layer adjustments still is
>>> broken (RRUL ping RTT against Toke's netperf host in Germany of ~80ms, same
>>> as without link layer adjustments). On the bright side the tc_stab method
>>> still works as well as before (ping RTT around 40ms).
>>>        I would like to humbly propose to use the tc stab method in
>>> cerowrt to perform ATM link layer adjustments as default. To repeat myself,
>>> simply telling the kernel a lie about the packet size seems more robust
>>> than fudging HTB's rate tables.
> 
> After the (regression) commit 56b765b79 ("htb: improved accuracy at
> high rates"), the kernel no-longer uses the rate tables.  
> 
> My commit 8a8e3d84b1719 (net_sched: restore "linklayer atm" handling),
> does the ATM cell overhead calculation directly on the packet length,
> see psched_l2t_ns() doing (DIV_ROUND_UP(len,48)*53).
> Thus, the cell calc should actually be more precise now.... but see below
> 
>>> Especially since the kernel already fudges
>>> the packet size to account for the ethernet header and then some, so this
>>> path should receive more scrutiny by virtue of having more users?
> 
> As you mention, the default kernel path (not tc stab) fudges the packet
> size for Ethernet headers, AND I made a mistake (back in approx 2006,
> sorry) that the "overhead" cannot be a negative number.  Meaning that
> some ATM encap overheads simply cannot be configured correctly (as you
> need to subtract the ethernet header). (And its quite problematic to
> change the kABI to allow for a negative overhead)
> 
> Perhaps we should change to use "tc stab" for this reason.  But I'm not
> sure "stab" does the right thing either, and its accuracy is also
> limited as its actually also table based.  We could easily change the
> kernel to perform the ATM cell overhead calc inside "stab", and we
> should also fix the GSO packet overhead problem.
> (for now remember to disable GSO packets when shaping)
> 
>> It's my hope that the atm code works but is misconfigured. You can output
>> the tc commands by overriding the TC variable with TC="echo tc" and paste
>> here.
> 
> I also hope is a misconfig.  Please show us the config/script.

	I guess you nailed it. While I got no output whatsoever from echo "func __detect_linklayer +p" /sys/kernel/debug/dynamic_debug/control. I also followed Dave's advise to dump the tc commands to file (see earlier mail). I turns out that the script only added the HTB link layer adjustments to egress and not to ingress as well, fixing that pushed the ping RTT for ht.'s link layer adjustemtes (at 95% of linerate) down to ~45ms which is close enough to what stab delivers.


> 
> I would appreciate a link to the scripts you are using... perhaps a git tree?
> 
> 
>>>        Now, I have been testing this using Dave's most recent cerowrt
>>> alpha version with a 3.10.9 kernel on mips hardware, I think this kernel
>>> should contain all htb fixes including commit 8a8e3d84b17 (net_sched:
>>> restore "linklayer atm" handling) but am not fully sure.
>>> 
>> 
>> It does.
> 
> It have not hit the stable tree yet, but DaveM promised he would pass it along.
> 
> It does seem Dave Taht have my patch applied:
> http://snapon.lab.bufferbloat.net/~cero2/patches/3.10.9-1/685-net_sched-restore-linklayer-atm-handling.patch
> 
>>> While I am not able to build kernels, it seems that I am able to quickly
>>> test whether link layer adjustments work or not. SO aim happy to help where
>>> I can :)
> 
> So, what is you setup lab, that allow you to test this quickly?
> 
> 
> -- 
> Best regards,
>  Jesper Dangaard Brouer
>  MSc.CS, Sr. Network Kernel Developer at Red Hat
>  Author of http://www.iptv-analyzer.org
>  LinkedIn: http://www.linkedin.com/in/brouer