<div dir="auto">I am curious as to the cpu and thruput difference between pfifo,  htb + fqcodel v cake at these insane speeds.<div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 6, 2018, 3:27 AM Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank" rel="noreferrer">chromatix99@gmail.com</a>> writes:<br>
<br>
>> On 6 Jul, 2018, at 4:21 pm, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk" target="_blank" rel="noreferrer">toke@toke.dk</a>> wrote:<br>
>> <br>
>>> I'm handling it without using any extra permanent state, just making<br>
>>> use of what's already there. Take a look at latest commit.<br>
>> <br>
>> Yup, that also fixes the infinite loop issue. I'm fine with doing it<br>
>> this way; however, it doesn't handle the other places where we check<br>
>> whether sch->q.qlen is nonzero. Are you sure that is not going to give<br>
>> us more problems down the road? :)<br>
><br>
> The other places are checking whether the queue is empty for the<br>
> purposes of updating the shaper state. They are therefore much less<br>
> critical, and I think self-correcting.<br>
<br>
Right, cool. In that case I think we are good to go for another upstream<br>
submission; I'll get that done later today :)<br>
<br>
-Toke<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank" rel="noreferrer">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div>