I have my RPi4 setup to use SQM, fd_codel/simple.qos and it works to reduce bufferbloat, however, I am seeing errors in logread output indicating that I am missing missing modules. Is this a false positive? Which package even provides these? I did not see them when searching in the build system's make nconfig tree.
Mon Sep 6 11:54:03 2021 daemon.err modprobe: failed to find a module named act_ipt
Mon Sep 6 11:54:03 2021 daemon.err modprobe: failed to find a module named sch_fq_codel
Mon Sep 6 11:54:03 2021 daemon.err modprobe: failed to find a module named act_ipt
Mon Sep 6 11:54:03 2021 daemon.err modprobe: failed to find a module named sch_fq_codel
Well, the question is, will this still complain if a required functionality is neither built-in nor found as a module. Because unconditionally silencing this seems worse than having a few false positives in logread, at least IMHO (but then I had my fingers in getting the verbose version implemented, so I am hardly objective here).
These errors can be either:
a) false positives, for example if a qdisc is built into the kernel instead of as a module, like fq_codel
b) true positives, if a required module does not exist at all
The second case seems worth causing an error, after all the end-user should know to remedy this. But that job might be deferred to verify_qdisc(), by including a "; qdisc was neither built-in nor found as module" into the error message.
In the case of the second error (which I also experienced), I'm not entirely sure what it is down to - it relates to the act_ipt module, but I assume this is pulled in as a result of something else, and assume it is sqm related given the surrounding context. Though as far as I can tell everything else works, and I can't see an obvious package that is missing between 19 and 21
So SQM already checks whether a module is loaded already and will not complain or attempt to reload it in that case, but it will try to find/load modules not already loaded. And if act_ipt functionality was built into the kernel and not configured as a module, the act_ipt module does not exist and con not be loaded, so modprobe rightfully complains. BUT on OpenWrt the kmodloader binary insists on injecting that error into the log, and there is no easy way to redirect that into SQM's private log (as for all built-ins this error is going to come up on every sqm (re-)start, so quite often during normal uptimes of OpenWrt routers).
Well, then at least some of the scripts will not work, so this seems like a true error report... @tohojo, this is one of the cases where the error reporting seems to be worth its while.
I will have a go at prototyping something later this month.
But that's just iptables rules? act_ipt is a TC action to interface with iptables, which I don't think we're using? AFAICT we only use action mirred for TC?
Good point, I guess it is time to try whether excluding act_ipt from loading causes actual regressions in sqm's functionality.... I do not remember when and why act_ipt was added to the list of modules to load.
If that statement is correct, perhaps there is a dependency issues with the package? Meaning it should also want to pull in whatever package provides that module... is it kmod-sched? Open a ticket upstream?
