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øiland-Jørgensen <toke@toke.dk> wrote:Robert Chacón via LibreQoS <libreqos@lists.bufferbloat.net> 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
> <https://github.com/xdp-project/bpf-examples/tree/master/pping> 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
--_______________________________________________
LibreQoS mailing list
LibreQoS@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos