Re A) - we could all benefit from switching to French, where "libre" and "livre" are
different words, with different connotations. English has really mangled this one.
"Free" can be "freedom" or "no cost", liberty somehow became "freedom" in a
lot of minds (to the chagrin of those of us with Political Science degrees), and "open"
can mean anything from "look but don't touch" to "public domain". Ugh.
We're stuck with the language we have, Libre works for me.

Less code is generally a good thing. It can be a balance; e.g. more code fleshing
out an API usually means much less code using it.

Qosify:

I gave Qosify a once-over, very quickly (short on time). It'll be worth going over it
again in more detail.
The lack of comments makes it heavy-going. It seems to be focused on a smaller
router at home, building a simple queue (assuming local NAT) and attaching a Cake
qdisc?
The "magic" I'm seeing is that the BPF program looks at flows to change
DSCP flags by connection bytes (I thought Cake was already classifying
by reading ConnTrack data?). I get the feeling I'm missing something.

Re B) - I've been wondering that, too. It's not an easy one to profile, kernel-side
profiling is hard enough without adding in eBPF! It's definitely worth digging
into.

C) is a whole other future discussion, and I feel I've talked enough about D).

On Thu, Nov 10, 2022 at 4:10 PM Dave Taht <dave.taht@gmail.com> wrote:
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...