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

[Herbert Wolverson <herberticus@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

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...
>

[-- Attachment #2: Type: text/html, Size: 4609 bytes --]