From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4DB213B29D for ; Tue, 8 Nov 2022 10:45:10 -0500 (EST) Received: by mail-ed1-x52f.google.com with SMTP id a67so23077563edf.12 for ; Tue, 08 Nov 2022 07:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jackrabbitwireless.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u35bq3v4FY5/8TFAyPjjnLXjtMJXFJ4ESxv9VJaiI5c=; b=XropNdluJy6PVV8meOF3QPdWBi61pxAtvToYMsAWQXbtMEFXINmqGjXQKKk9akrjTQ J2FeqAFWqaEIStmIfXnH9iyZcD25916fwcNkzrJIYie2/1cXpzxh4PUHjaZxIZbcPKZd R0JO/lJi0NQ/LY5GgflAKG00tR71IcYmZOtWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to: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=u35bq3v4FY5/8TFAyPjjnLXjtMJXFJ4ESxv9VJaiI5c=; b=H1vAH8YaWVAEHUJhbv3y8aiIBLW4fJUYpehvBMGuy35OCAAQAw/f/khnr1Ga0ByX06 jNsUYi40UPKpPk7Hd3JMuFINacT1RRp/9JyWSp7HN5qI2BzazJMp/dXeSrYUEXIgce64 JjmG17BU0GR6LBtR6GYgCqc92PDXBdVUE0Gm7keaPlRKkSPcL0ydgmFAtaw4fedqpqU/ p6MDiVTWBTzHsmJ2eVnhhPAcCIo49HF6EQPbidFvx3TVT73R36re3rnaCjD+15za2XOp 736lHLFohTxUMUCLcbz8fObY7Yvry4rOjzGENmLTSxXJ9tZsRZGX5aoGpky2OJec71ed pEGA== X-Gm-Message-State: ACrzQf3Potn+K4gVwqcBEjNA66EuYF+htlnL2MxT+7hE2zwpm4GJMrW1 DwKn4gShhqyuC02/Qp4J842vjO5SGQGE5iQxID4pAvMawPoo9w== X-Google-Smtp-Source: AMsMyM58ME61fkZvUt2ablWmP5WZBZYnUrUwcCV4juAJ+pPG+6Egw2gNZPNqMEDHTTaf+nQLVhEmmHHZXu9C+aK3OFc= X-Received: by 2002:aa7:d44b:0:b0:464:2fa2:3359 with SMTP id q11-20020aa7d44b000000b004642fa23359mr28939930edr.409.1667922309078; Tue, 08 Nov 2022 07:45:09 -0800 (PST) MIME-Version: 1.0 References: <877d05v825.fsf@toke.dk> In-Reply-To: <877d05v825.fsf@toke.dk> From: =?UTF-8?Q?Robert_Chac=C3=B3n?= Date: Tue, 8 Nov 2022 08:44:58 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: libreqos Content-Type: multipart/alternative; boundary="000000000000befcd005ecf76c99" 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 15:45:10 -0000 --000000000000befcd005ecf76c99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 "turni= ng > > on" LibreQoS, ideally before v1.3 release. This way operators can reall= y > > 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 approac= h > 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 slightly > > 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 > --=20 Robert Chac=C3=B3n CEO | JackRabbit Wireless LLC Dev | LibreQoS.io --000000000000befcd005ecf76c99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Point taken!

Before receivin= g this email I had started work on it. It's on a branch = on GitHub now.
It uses cpumap-pping and keeps HTB, but overri= des all HTB class and leaf rates to be 10Gbps so that borrowing isn't t= aking place anywhere - so we can be as transparent as possible.

I'll try again another shot at monitoring-mode with e= PPing instead.

On Tue, Nov 8, 2022 at 7:23 AM Toke H=C3=B8iland-J= =C3=B8rgensen <toke@to= ke.dk> wrote:
Robert Chac=C3=B3n via LibreQoS <libreqos@lists.bufferbloat.net> wr= ites:

> 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>
--000000000000befcd005ecf76c99--