Seriously though even with a gigabyte of ARP traffic a month and say 20 bytes per packet it's only 20 packets per second and 3kbps. Negligible On even a 20 Mbps download line. Fully negligible on your line.
I should clarify this is only the case if my ISP is actually giving you the DSLITE nightmare...
I got this info from a forum (unofficial isp forum).
In my case only the mtu was crippled, port forwards worked fine.
yes the arp will have not that much of an impact but it still bugs me x)
some offtopic...
" LRO should not operate on machines acting as routers, as it breaks the [end-to-end principle]and can significantly impact performance" Wikipedia...
I know the "cake guys" x) recommend to disable offloads anyway.
But when i think about it on how many devices lro is active by default?
Why is there no generic way to disable all offloads in linux? Through sysctl or something...
Ah great that this is settled now. But also a bit sad, as I have questions about whether only accounting for 18 bytes of overhead is correct for ds-lite links for (tunneled) IPv4 packets....
Well actually cake will accept large packets and will slice them into their constituting "normal-size" packets which for egress probably means one still harvests the cpu saving for actually doing all the routing lookup not for every packet. It probably will not help on ingress. Please note by default cake will do this splitting up to 1Gbps shaper rate (it might also be overridable with the no-split-gso keyword). I am not 100% sure whether the newer GRO cod paths actually still violates the e2e principle that much (the issue really is that the outgoing packets might not be exactly as the incoming ones and hence there is a user-observable difference between GRO/GSO and normal packet size handling). If one's hardware is fast enough disabling all ofthis seems the best option, but it can give a nice opportunistic performance boost (then again this depends on the pattern of incoming packets so it is not guaranteed to help at all).
Now to put things into perspective, modern router performance and bandwidth, IMHO, make handling ~64KB packets (the maximum size for suer-packets AFAICT) not worse than having a 1990 vintage machine handling 1500Byte packets... (this assumes that performance and badwidths increased more the 46 fold over the last 28 years, but I digress).
Well LRO should probably not the default, as those hardware approaches typically are deployed and never again touched/fixed, but the software GRO/UFO approaches IMHO make decent defaults...
Answering that question requires someone with a higher "paygrade" than me 
(I have a hunch that maybe the answer is, nobody ever posted a patch).
Best Regards
This solved my SQM issues on my Zyxel Armor Z2 (NBG6817). I'm on a 230mbit downstream connection and just moved from firmware 19.07.7 to 21.02.0-rc3.
- On 19.07.7 using Cake, my downstream lowered to about 160mbits.
- After upgrading to 21.02.0-rc3 using Cake, my downstream lowered to 100mbits.
- After switching to fq_codel and my downstream shot up to 210mbps.
Quite an improvement.
3 Likes
I've incurred a large drop in download cake SQM performance on MT7621 (an ER-X) going from from 19.07 (~185 Mbps) to 21.02RCx and current snapshot (~130 Mbps).
This suggestion from 2018 (fq_codel and simple.qos) did improve my download to ~170 Mbps, but it degraded sustained upload speed from ~9 Mbps to ~7 Mbps and made upload speed far more inconsistent. Strange that.
Without SQM I get ~230Mbps down and ~12Mbps up from my ISP, but with a "C" bufferbloat rating from DSLReports. Something has definitely made cake quite a bit slower, that is for sure. It has me eyeing a Bananapi R2 to replace my ER-X gateway, but I plan to wait a bit to see if things improve in snapshot first.
The best way would be to git-bisect the kernel to figure out roughly what commit changed the performance for the worse.