<div dir="ltr"><div>Point taken!</div><div><br></div><div>Before receiving this email I had started work on it. It's on <a href="https://github.com/LibreQoE/LibreQoS/tree/monitor-mode/v1.3" target="_blank">a branch on GitHub now</a>.</div><div>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.<br></div><div><br></div><div>I'll try again another shot at monitoring-mode with ePPing instead.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 8, 2022 at 7:23 AM Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Robert Chacón via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> writes:<br>
<br>
> I was hoping to add a monitoring mode which could be used before "turning<br>
> on" LibreQoS, ideally before v1.3 release. This way operators can really<br>
> see what impact it's having on end-user and network latency.<br>
><br>
> The simplest solution I can think of is to implement Monitoring Mode using<br>
> cpumap-pping as we already do - with plain HTB and leaf classes with no<br>
> CAKE qdisc applied, and with HTB and leaf class rates set to impossibly<br>
> high amounts (no plan enforcement). This would allow for before/after<br>
> comparisons of Nodes (Access Points). My only concern with this approach is<br>
> that HTB, even with rates set impossibly high, may not be truly<br>
> transparent. It would be pretty easy to implement though.<br>
><br>
> Alternatively we could use ePPing<br>
> <<a href="https://github.com/xdp-project/bpf-examples/tree/master/pping" rel="noreferrer" target="_blank">https://github.com/xdp-project/bpf-examples/tree/master/pping</a>> but I worry<br>
> about throughput and the possibility of latency tracking being slightly<br>
> different from cpumap-pping, which could limit the utility of a comparison.<br>
> We'd have to match IPs in a way that's a bit more involved here.<br>
><br>
> Thoughts?<br>
<br>
Well, this kind of thing is exactly why I think concatenating the two<br>
programs (cpumap and pping) into a single BPF program was a mistake:<br>
those are two distinct pieces of functionality, and you want to be able<br>
to run them separately, as your "monitor mode" use case shows. The<br>
overhead of parsing the packet twice is trivial compared to everything<br>
else those apps are doing, so I don't think the gain is worth losing<br>
that flexibility.<br>
<br>
So I definitely think using the regular epping is the right thing to do<br>
here. Simon is looking into improving its reporting so it can be<br>
per-subnet using a user-supplied configuration file for the actual<br>
subnets, which should hopefully make this feasible. I'm sure he'll chime<br>
in here once he has something to test and/or with any questions that pop<br>
up in the process.<br>
<br>
Longer term, I'm hoping all of Herbert's other improvements to epping<br>
reporting/formatting can make it into upstream epping, so LibreQoS can<br>
just use that for everything :)<br>
<br>
-Toke<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr">Robert Chacón<br><div>CEO | <a href="http://jackrabbitwireless.com" target="_blank">JackRabbit Wireless LLC</a></div><div>Dev | <a href="http://LibreQoS.io" target="_blank">LibreQoS.io</a><br></div><br></div></div>