<div dir="ltr"><div>Hey Herbert,</div><div><br></div><div>Wow. Awesome work! How exciting. We may finally get highly scalable TCP latency tracking in LibreQoS and BracketQoS.</div><div>Regarding how we receive the data, I suppose whatever is most efficient and scalable for networks with high subscriber counts.</div><div>In v1.1 we were just parsing some data from the console output:</div><div><ul><li>rtt1</li><li>IP address 1</li><li>IP address 2</li></ul><div></div></div><div>I am a big fan of having some sort of JSON structure to pull info from.<br></div><div>What do you recommend here for optimal efficiency?<br></div><div><br></div><div>Thanks,</div><div>Robert</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 15, 2022 at 7:59 PM Herbert Wolverson via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net">libreqos@lists.bufferbloat.net</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"><div dir="ltr"><div>Hey,</div><div><br></div><div>I've had some pretty good success with merging xdp-pping ( <a href="https://github.com/xdp-project/bpf-examples/blob/master/pping/pping.h" target="_blank">https://github.com/xdp-project/bpf-examples/blob/master/pping/pping.h</a> ) into xdp-cpumap-tc ( <a href="https://github.com/xdp-project/xdp-cpumap-tc" target="_blank">https://github.com/xdp-project/xdp-cpumap-tc</a> ).</div><div><br></div><div>I ported over most of the xdp-pping code, and then changed the entry point and packet parsing code to make use of the work already done in xdp-cpumap-tc (it's already parsed a big chunk of the packet, no need to do it twice). Then I switched the maps to per-cpu maps, and had to pin them - otherwise the two tc instances don't properly share data. Right now, output is just stubbed - I've still got to port the perfmap output code. Instead, I'm dumping a bunch of extra data to the kernel debug pipe, so I can see roughly what the output would look like.</div><div><br></div><div>With debug enabled and just logging I'm now getting about 4.9 Gbits/sec on single-stream iperf between two VMs (with a shaper VM in the middle). :-)</div><div><br></div><div>So my question: how would you prefer to receive this data? I'll have to write a daemon that provides userspace control (periodic cleanup as well as reading the performance stream), so the world's kinda our oyster. I can stick to Kathie's original format (and dump it to a named pipe, perhaps?), a condensed format that only shows what you want to use, an efficient binary format if you feel like parsing that...</div><div><br></div><div>(I'll post some code soon, getting sleepy)<br></div><div><br></div><div>Thanks,</div><div>Herbert<br></div></div>
_______________________________________________<br>
LibreQoS mailing list<br>
<a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Robert Chacón<br>CEO | <a href="http://jackrabbitwireless.com" target="_blank">JackRabbit Wireless LLC</a><br></div></div>