From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 A6C713B29D for ; Tue, 8 Nov 2022 11:04:28 -0500 (EST) Received: by mail-pg1-x530.google.com with SMTP id s196so13787859pgs.3 for ; Tue, 08 Nov 2022 08:04:28 -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=j2DmI208gEseq5CmX9+pjKCE9IIrqJFUE+096oQgBg8=; b=SiQ2VF66729LEDnsu39ppDpZnAIARG50TVgImBlKX73wsBkp9cNbMaScOz/Axfr4rS ho4wU4iD+2jawqQbARyiASrsdpgDiMlxywU81cWq9DYfH+J7hjrho77iOtrmsQhlBsU6 Dvnh1Rib39YYyPnYJg8WzyvJz71lLnaMkBqEbeyGbhuwJwZsw3oN//mIzp9Ps1X3lvYJ hF8CnV7Lblhn5JnqqZXtIpa3FSVRZ98WOM2B3/sAtlhhctqYJoZC+6XQgTrV6Fin/P8o ZcOlqJP+YjQsPmGr3NonUlPsXsHqfNMXvuEGJuZJHK3q+UlrvK7RScm16t3Mg+fK5bgd b56g== 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=j2DmI208gEseq5CmX9+pjKCE9IIrqJFUE+096oQgBg8=; b=vJmeulX78W0lwbg1Sfse22jhsBFni6PRBLJ6+j+Q4bymybbRsahu2jZ67Z5Q4Q81m7 txCToq3isW7PpxVIUK+aX+SDrSd/AYT2VzZSUlIEZKKqNOlhA4NXibCmKfVIyR1cTfpb Iv+37nJ/u2KL7nGBomfN0Z8EA9o4qwIUQQSEgB+AAayTReC3E8JmW+wMnnI+puUJW1U6 YARzT+/nnoH4hNRCmQLyLjwzoIWwqhsUMCAod8QV60Hx/nqM3jG2FUg1LucDh37v29qs 00ulYDfgaVDu4rtQERsgkRQqoEqjJswVAk3gOtJf1DQaSgQ3mKPzbNmrCQmVf2hUXDNv vKAw== X-Gm-Message-State: ACrzQf1CdWyND8xLLIxElmThmaRtDVJDA36P6rqfJs6RQsdRCcihw8+8 Ba5dUiUNmmCb2CvR9NZMncCW5BRa7hWg0mkqcfugvtAf X-Google-Smtp-Source: AMsMyM6oB8bx33MrfSwgIdxmbHaETcEVkGnGF7/9V27jdfEJH4AmYkoEEhbt1GqyHUHMNJxxEHyrUdYsy60zLSEjTBA= X-Received: by 2002:a65:6e0e:0:b0:434:59e0:27d3 with SMTP id bd14-20020a656e0e000000b0043459e027d3mr46815498pgb.185.1667923467224; Tue, 08 Nov 2022 08:04:27 -0800 (PST) MIME-Version: 1.0 References: <877d05v825.fsf@toke.dk> In-Reply-To: From: Herbert Wolverson Date: Tue, 8 Nov 2022 10:04:16 -0600 Message-ID: Cc: libreqos Content-Type: multipart/alternative; boundary="000000000000c6d91605ecf7b10f" 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 16:04:28 -0000 --000000000000c6d91605ecf7b10f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Glancing at that, I love how simple it is. :-) I'll see if I can try it out soon (I'm diving back into book writing for the day) On Tue, Nov 8, 2022 at 9:45 AM Robert Chac=C3=B3n via LibreQoS < libreqos@lists.bufferbloat.net> wrote: > Point taken! > > Before receiving this email I had started work on it. It's on a branch on > GitHub now . > It uses cpumap-pping and keeps HTB, but overrides all HTB class and leaf > rates to be 10Gbps so that borrowing isn't taking place anywhere - so we > can be as transparent as possible. > > I'll try again another shot at monitoring-mode with ePPing instead. > > On Tue, Nov 8, 2022 at 7:23 AM Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > >> 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 real= ly >> > 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 n= o >> > CAKE qdisc applied, and with HTB and leaf class rates set to impossibl= y >> > 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 >> worry >> > about throughput and the possibility of latency tracking being slightl= y >> > different from cpumap-pping, which could limit the utility of a >> comparison. >> > 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 >> > > > -- > Robert Chac=C3=B3n > CEO | JackRabbit Wireless LLC > Dev | LibreQoS.io > > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos > --000000000000c6d91605ecf7b10f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Glancing at that, I love how simple it is. :-) I'll se= e if I can try it out soon (I'm diving back into book writing for the d= ay)

On Tue, Nov 8, 2022 at 9:45 AM Robert Chac=C3=B3n via LibreQoS <<= a href=3D"mailto:libreqos@lists.bufferbloat.net">libreqos@lists.bufferbloat= .net> wrote:
Point taken!

Before rece= iving this email I had started work on it. It's on a bra= nch on GitHub now.
It uses cpumap-pping and keeps HTB, but ov= errides all HTB class and leaf rates to be 10Gbps so that borrowing isn'= ;t taking place anywhere - so we can be as transparent as possible.

I'll try again another shot at monitoring-mode wi= th ePPing instead.

On Tue, Nov 8, 2022 at 7:23 AM Toke H=C3=B8il= and-J=C3=B8rgensen <to= ke@toke.dk> wrote:
Robert Chac=C3=B3n via LibreQoS <libreqos@lists.bufferbloat.net&= gt; 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 u= sing
> cpumap-pping as we already do - with plain HTB and leaf classes with n= o
> CAKE qdisc applied, and with HTB and leaf class rates set to impossibl= y
> high amounts (no plan enforcement). This would allow for before/after<= br> > comparisons of Nodes (Access Points). My only concern with this approa= ch 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
> <https://github.com/xdp-project= /bpf-examples/tree/master/pping> but I worry
> about throughput and the possibility of latency tracking being slightl= y
> different from cpumap-pping, which could limit the utility of a compar= ison.
> We'd have to match IPs in a way that's a bit more involved her= e.
>
> 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. Th= e
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 eppi= ng
reporting/formatting can make it into upstream epping, so LibreQoS can
just use that for everything :)

-Toke


--
Robert Chac=C3=B3n

<= /div>
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
--000000000000c6d91605ecf7b10f--