[LibreQoS] Before/After Performance Comparison (Monitoring Mode)

[Dave Taht]

A couple meta comments:

A) Most of this new stuff is not "open source" but "free" (libre)
software. I have kind of despaired at the degradation of the term
"Open", and the phrase "open source". Free is a lousy word also, and
"libre" the closest thing we have left to the original spirit of
sharing and mutual respect that the culture that birthed the modern
internet in the 90s, had.

I have never been able to pay people (aside from vectoring grants in
their direction), and am HUGE on always providing credit, because that
was the only thing I had to give in exchange for huge amount of
craftsmanship required to build truly great software.

Sometimes, this means less code, rather than more! I'm rather proud of
toke & felix & michal (and so many others) fq_codel for wifi
implementation *removing* a net 200 lines of code. (
https://lwn.net/Articles/705884/ )

I'd like us to be looking hard at qosify (
https://forum.openwrt.org/t/qosify-new-package-for-dscp-marking-cake/111789/
) as well, long term.

B) in trying to make tcp rtt sensing performant and always on, with
+1% more cpu... I find myself wondering where the 24% of 16 cores
we're spending at 11gbit is really going!! Cache bandwidth is
enormous... Dick Sites' recent book on tracing well thumbed.

C) There are a ton of things (long term) that will impact future
processing, some merely interesting, others genuinely useful. Examples
of this include - sensing frequency and location of icmp "too big"
messages, quic's spin bit, feed forwarding the rtt stats into
dynamically shaping an instance to compensate for in-home wifi (does
anyone actually know wtf plume is measuring and doing for their 2.2B
valuation??), checking for correct tcp responses to ecn marks, and
detecting ddos attacks...

D) I would like us to always "upstream first", like redhat, and
openwrt. REALLY high on my list is being able to track and extend
"drop_reason" support in the kernel...