Dave Taht <[email protected]> writes: > Sebastian Gottschall <[email protected]> writes: > >> Am 21.08.2019 um 18:21 schrieb Sebastian Moeller: >>> >>> On August 21, 2019 6:12:03 PM GMT+02:00, Sebastian Gottschall >>> <[email protected]> wrote: >>>> thats rather old. i rewrote all the qos code in the last 4 or 5 days. >>>> so >>>> things might be changed. next phase is bringing all the link level >>>> detail configuration stuff into the gui which will be done >>>> tomorrow or at least still within this week. >>>> i also added now cake to some smaller low budged routers with limited >>>> resources, so see how it runs. i had bad experiences with fq_codel in >>>> the past due some high memory usage. >>>> especially since its hard coded somewhat into the wireless ath9k >>>> driver. >>>> so i already modded it for more efficient handling. 4 mb max per queue >>>> is simply too much for a 32 mb ram based router. >>> This is why I'm sqm we reduced the queued packet maximum m to around 1000, >>> and also why cake has an explicit memlimit keyword. >> yeah but does this help if fq_codel is hardcoded into mac80211? >> fq_codel has a memlimit keyword too btw. its fixed to 4MB. i reduced >> it to 256kb on low memory architectures. no other way to get around >> OOM problems >> mac80211 does always make use of fq_codel. it has a own build in >> implementation > > Certainly memory limits are a huge problem throughout complex qdiscs, > especially when stacked up (eg hfsc 1 -> qdiscx hfsc 2 -> qdisc x), > and > > OOMs suck. Particularly as few test packet flooding their devices > after setting up a complex qdisc system. > > Bytes = time. It doesn't matter how many queues you have. This > to me has always been one of the biggest flaws of the tc subsystem > in general is that the total amount of memory in use on > a given physical interface should be managed by the topmost layer. > > Same problem for wifi in multiple SSIDs... it's still just one device. > > However we do need enough bytes to keep the device busy and there > are other problems with per packet limits leading me to prefer > using just memory limits. One is, that your typical ack packet > coming off the rx ring is actually 2k in size, not 64 bytes. > I had at one point (in openwrt) something that took small packets > and copied them to a smaller allocation which took pressure off the > memory allocator. > > I've kind of lost track, did the ath9k wifi stuff use 1 allocation for > all 4 hw queues? I'm afraid to look this morning... (and I'm not big > on the 4 hw queues either)
The memory limit in mac80211 is global per phy. -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
