From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 612823B29D for ; Tue, 8 Nov 2022 09:23:48 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1667917426; bh=kbep9XmNHp2RsGJ3axbbvsCkMyEgcSpCEFNdruGI4vg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ckc3o/lF5es3wbeC8EDUDOXQYrrLDlYFDfRm4SfLJFUmKXYfbuzlATt58jVz+Gw5B X9xJqJrLdDa8wwzuHbVNUM9tM/vzMeG6JpW1wX8PtAF5qab5q8nPHgN/fa37G04p25 GuIfVAQlz2Vd1ApnvZQX+ifPqV4Aq6i3TByrx5uEPfVOXNknqRfLQgqsYWxv+q3Wa+ DU82+M9J2CuvhbQtQxktez1jfkg84vwaHrqKyJKTmxz0Iy8OM/4RSYXlPYJCfhcDJ0 lk3GfWATLsA+m3/G/nEVj/n13mENy4+Vl/P6JhVjGNW2N+FNH1U4SIx9j40RdFUHoX n1MyezyKbm9WA== To: Robert =?utf-8?Q?Chac=C3=B3n?= , libreqos In-Reply-To: References: Date: Tue, 08 Nov 2022 15:23:46 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877d05v825.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 08 Nov 2022 14:23:48 -0000 Robert Chac=C3=B3n via LibreQoS writes: > I was hoping to add a monitoring mode which could be used before "turning > on" LibreQoS, ideally before v1.3 release. This way operators can really > see what impact it's having on end-user and network latency. > > The simplest solution I can think of is to implement Monitoring Mode using > cpumap-pping as we already do - with plain HTB and leaf classes with no > CAKE qdisc applied, and with HTB and leaf class rates set to impossibly > high amounts (no plan enforcement). This would allow for before/after > comparisons of Nodes (Access Points). My only concern with this approach = is > that HTB, even with rates set impossibly high, may not be truly > transparent. It would be pretty easy to implement though. > > Alternatively we could use ePPing > but I wor= ry > about throughput and the possibility of latency tracking being slightly > different from cpumap-pping, which could limit the utility of a compariso= n. > We'd have to match IPs in a way that's a bit more involved here. > > Thoughts? Well, this kind of thing is exactly why I think concatenating the two programs (cpumap and pping) into a single BPF program was a mistake: those are two distinct pieces of functionality, and you want to be able to run them separately, as your "monitor mode" use case shows. The overhead of parsing the packet twice is trivial compared to everything else those apps are doing, so I don't think the gain is worth losing that flexibility. So I definitely think using the regular epping is the right thing to do here. Simon is looking into improving its reporting so it can be per-subnet using a user-supplied configuration file for the actual subnets, which should hopefully make this feasible. I'm sure he'll chime in here once he has something to test and/or with any questions that pop up in the process. Longer term, I'm hoping all of Herbert's other improvements to epping reporting/formatting can make it into upstream epping, so LibreQoS can just use that for everything :) -Toke