Cake on openwrt - falling behind
kevin at darbyshire-bryant.me.uk
Sat Jun 30 04:29:05 EDT 2018
I’m concerned that cake on openwrt is falling behind. Due to strange behaviour at least on MIPS since commit https://github.com/dtaht/sch_cake/commit/af1d7cde7046af55ec867b29854d754816b64bc8 Switch rates to 64bit, openwrt has been ‘stuck’ on the prior commit. I personally have hack patches in my that effectively reverts the conversion to 64 netlink values in cake & tc and I’m pleased to say that works, however the wider community are a) not so lucky b) not actually running our latest code, there are a number of tweaks to the ack filter code that openwrt users are not benefitting from.
Toke & myself dug into this a bit and we don’t, so far, think this is a bug in cake but is rather exposing an issue in netlink handling. But we’ve hit an information vacuum, in essence I’m only seeing this on MIPS/Openwrt *BUT* that’s the only thing I can actually test on. So is this 32bit MIPS only? Is it Openwrt only? Is it MIPS & Openwrt only? Is it 32bit archs only? And so on.
This really needs to be investigated & solved, so that a) openwrt’s cake can be bumped and b) Someone can get on with backporting the class handling code (which is being sent upstream) to 4.14/4.9 (maybe earlier)
If *you* have the means of compiling the latest cake & tc code on your platform could you please do so and report architecture etc if you do/do not see cake’s tin stats from ‘tc -s qdisc’ (that’s the biggest indicator of the issue)
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the Cake