<div dir="ltr"><div>Re A) - we could all benefit from switching to French, where "libre" and "livre" are</div><div>different words, with different connotations. English has really mangled this one.</div><div>"Free" can be "freedom" or "no cost", liberty somehow became "freedom" in a</div><div>lot of minds (to the chagrin of those of us with Political Science degrees), and "open"</div><div>can mean anything from "look but don't touch" to "public domain". Ugh.</div><div>We're stuck with the language we have, Libre works for me.</div><div><br></div><div>Less code is generally a good thing. It can be a balance; e.g. more code fleshing</div><div>out an API usually means much less code using it. </div><div><br></div><div>Qosify:<br></div><div><br></div><div>I gave Qosify a once-over, very quickly (short on time). It'll be worth going over it</div><div>again in more detail.</div><div>
<div>The lack of comments makes it heavy-going. It seems to be focused on a smaller <br></div><div>router at home, building a simple queue (assuming local NAT) and attaching a Cake <br></div><div>qdisc?</div><div>The "magic" I'm seeing is that the BPF program looks at flows to change</div><div>DSCP flags by connection bytes (I thought Cake was already classifying</div><div>by reading ConnTrack data?). I get the feeling I'm missing something.<br></div><div></div>

</div><div><br></div><div>Re B) - I've been wondering that, too. It's not an easy one to profile, kernel-side</div><div>profiling is hard enough without adding in eBPF! It's definitely worth digging</div><div>into.</div><div><br></div><div>C) is a whole other future discussion, and I feel I've talked enough about D).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 10, 2022 at 4:10 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A couple meta comments:<br>
<br>
A) Most of this new stuff is not "open source" but "free" (libre)<br>
software. I have kind of despaired at the degradation of the term<br>
"Open", and the phrase "open source". Free is a lousy word also, and<br>
"libre" the closest thing we have left to the original spirit of<br>
sharing and mutual respect that the culture that birthed the modern<br>
internet in the 90s, had.<br>
<br>
I have never been able to pay people (aside from vectoring grants in<br>
their direction), and am HUGE on always providing credit, because that<br>
was the only thing I had to give in exchange for huge amount of<br>
craftsmanship required to build truly great software.<br>
<br>
Sometimes, this means less code, rather than more! I'm rather proud of<br>
toke & felix & michal (and so many others) fq_codel for wifi<br>
implementation *removing* a net 200 lines of code. (<br>
<a href="https://lwn.net/Articles/705884/" rel="noreferrer" target="_blank">https://lwn.net/Articles/705884/</a> )<br>
<br>
I'd like us to be looking hard at qosify (<br>
<a href="https://forum.openwrt.org/t/qosify-new-package-for-dscp-marking-cake/111789/" rel="noreferrer" target="_blank">https://forum.openwrt.org/t/qosify-new-package-for-dscp-marking-cake/111789/</a><br>
) as well, long term.<br>
<br>
B) in trying to make tcp rtt sensing performant and always on, with<br>
+1% more cpu... I find myself wondering where the 24% of 16 cores<br>
we're spending at 11gbit is really going!! Cache bandwidth is<br>
enormous... Dick Sites' recent book on tracing well thumbed.<br>
<br>
C) There are a ton of things (long term) that will impact future<br>
processing, some merely interesting, others genuinely useful. Examples<br>
of this include - sensing frequency and location of icmp "too big"<br>
messages, quic's spin bit, feed forwarding the rtt stats into<br>
dynamically shaping an instance to compensate for in-home wifi (does<br>
anyone actually know wtf plume is measuring and doing for their 2.2B<br>
valuation??), checking for correct tcp responses to ecn marks, and<br>
detecting ddos attacks...<br>
<br>
D) I would like us to always "upstream first", like redhat, and<br>
openwrt. REALLY high on my list is being able to track and extend<br>
"drop_reason" support in the kernel...<br>
</blockquote></div>