<div dir="ltr"><div>That looks like it could be very, very useful. There's more email thread there than I have time to read,</div><div>I wonder if there's a way to chain the xdp metadata to secondary XDP programs (which would</div><div>obviate a lot of the "doing everything repeatedly" problem when dissecting packets on the XDP</div><div>side as well as when passing to the TC side of things).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 10, 2022 at 5:45 PM Toke Høiland-Jørgensen 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">Dave Taht via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> writes:<br>
<br>
> There is a long thread about xdp metadata going on here. I have high<br>
> hopes for this concept once it lands,<br>
> everything from getting the three hashes cake requires directly from<br>
> the network card (and timestamps), but also a<br>
> "quality" figure of some sort, and who knows what else...<br>
<br>
Haha, yeah, I actually mentioned LibreQoS as one of the use cases, here:<br>
<a href="https://lore.kernel.org/r/87r0yaxw5s.fsf@toke.dk" rel="noreferrer" target="_blank">https://lore.kernel.org/r/87r0yaxw5s.fsf@toke.dk</a> :)<br>
<br>
-Toke<br>
_______________________________________________<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>