Cake on openwrt - falling behind

Cake on openwrt - falling behind

[Kevin Darbyshire-Bryant]

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

Hi Chaps,

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)


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]