From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E54473CB37 for ; Fri, 11 Nov 2022 09:23:21 -0500 (EST) Received: by mail-pf1-x429.google.com with SMTP id g62so5012292pfb.10 for ; Fri, 11 Nov 2022 06:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=0Y/KzcSWIvvDJqS9j4hwVU49Qa7mt1YTZvCWzOJxwH4=; b=drMZn6VMZSrTnXx9GZYEn7He3n4DiS3LU9/k7ITkHlTWF5lNENdxMT86LtIKN1AFyC z4NGK/sPCe7arUjIEuCJm3VjJLOtfljmq4ZKFag7MPifIOPsAwuKqeNDeGA/wPzzy5Zk K7PAfIPUWfGz6AsLVAShojGMdmvT6q2PVe/zeR+o6MvWDHjcrtb9NNZGFmNeFQSyHLA2 x6DSVJldb/zzTuJS0+pACnh7ym3ApVBVsePtfibA/vnO9g73ExrhhAJM+iz1UC3fH/bh 6Rhc04XqZnYJdUzxu9jgxrz3iNxXUl5+VHr6WDLBlWAK21jGA84Cps1UslXiLQAQ3oi+ Vp7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0Y/KzcSWIvvDJqS9j4hwVU49Qa7mt1YTZvCWzOJxwH4=; b=LGBCZEj1mF06xtZUq0bqIdP6Q7tTrDzpni/qQDQ3se4C1wzSsZEaEgLu+g2TtwYNRv 9M3z42idX2hgceEYFVeWxLxamfKxkJ1t02KohWJgnZ1pRtdK9LgddwCtKKaiVmyjyr8W LH9c6+jPu4sbOZP/DV4tLFByNczQCPSh7T+UwA4rYywqcHpn3OFM2zgomYSP6CZ6tcdd q4odErWNDdk5M/+5uKmgFRlvvY9jbp7zGYrNS6zKueZmw+R96GsLYglqmzxGwFQ8z95E q2OogxOyZn2dK0vxx7wrgl/He/iNTKe/LSOQoMwxAkA6AYXUmiZC9qpwmmXnrzdbHZ81 pFcg== X-Gm-Message-State: ANoB5pklRtjjzenip1E/s/sBL8cmkmHJFAck8u2bPWgLmWcuFow5Mf4G V1LuaNAn/RZ/qM+LrRZUfscfOy/9Ag3e7nu4cA5+DQp4vUI= X-Google-Smtp-Source: AA0mqf6ympUNeem7vUPhfj26VmT5UFUWZ3gaRpX+lTxGEQAiPj1SeAB6/QPXIq33orGkT9n9YYTrcP1xstfGhLSoZ4U= X-Received: by 2002:a63:5115:0:b0:434:95b2:b4d2 with SMTP id f21-20020a635115000000b0043495b2b4d2mr1846630pgb.431.1668176600473; Fri, 11 Nov 2022 06:23:20 -0800 (PST) MIME-Version: 1.0 References: <877d05v825.fsf@toke.dk> <32f3097eecb67781c1beb2b5c197586624378787.camel@kau.se> In-Reply-To: From: Herbert Wolverson Date: Fri, 11 Nov 2022 08:23:09 -0600 Message-ID: Cc: "libreqos@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="000000000000b1a4eb05ed32a14e" Subject: Re: [LibreQoS] Before/After Performance Comparison (Monitoring Mode) X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2022 14:23:22 -0000 --000000000000b1a4eb05ed32a14e Content-Type: text/plain; charset="UTF-8" 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 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... > --000000000000b1a4eb05ed32a14e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re A) - we could all benefit from switching to French= , where "libre" and "livre" are
different wor= ds, with different connotations. English has really mangled this one.
=
"Free" can be "freedom" or "no cost", li= berty somehow became "freedom" in a
lot of minds (to th= e chagrin of those of us with Political Science degrees), and "open&qu= ot;
can mean anything from "look but don't touch" t= o "public domain". Ugh.
We're stuck with the langua= ge we have, Libre works for me.

Less code is gener= ally a good thing. It can be a balance; e.g. more code fleshing
o= ut an API usually means much less code using it.

= Qosify:

I gave Qosify a once-over, very quickl= y (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 l= ocal NAT) and attaching a Cake
qdisc?
The "ma= gic" I'm seeing is that the BPF program looks at flows to change
DSCP flags by connection bytes (I thought Cake was already classif= ying
by reading ConnTrack data?). I get the feeling I'm missi= ng something.

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

C) is a whole other future discussion, and I fee= l 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&quo= t; (libre)
software. I have kind of despaired at the degradation of the term
"Open", and the phrase "open source". Free is a lousy w= ord also, and
"libre" the closest thing we have left to the original spirit of<= br> 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<= br> 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.or= g/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...
--000000000000b1a4eb05ed32a14e--