<p>A small CPU can be made in perhaps 35K gates - something like an ARM7TDMI or a Cortex-M0. It is common to stick one of those in a special purpose chip to help with control logic.</p>
<p>But that would operate at a few hundred MHz, which leaves only a few cycles per packet for small packets. That's not enough to run even a relatively simple algorithm like codel. </p>
<p>Dedicated logic that *is* fast enough to run the algorithm on each packet shouldn't be any bigger than such a CPU. </p>
<p> - Jonathan Morton<br>
</p>
<div class="gmail_quote">On Dec 20, 2012 10:17 AM, "Hal Murray" <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If I was going to do something like that, I'd build a small/simple CPU and do<br>
the work in microcode.<br>
<br>
> implementing {n,e,s}fq_codel onboard looks very feasible<br>
<br>
How many lines of assembler code would it take?<br>
<br>
How many registers do you need?  Do you need any memory other than queues?<br>
Maybe counters?<br>
<br>
<br>
> The only thing that is seriously serial about fq_codel is shooting the<br>
> biggest flow when the queue limit is exceeded, and that could be made<br>
> embarrassingly parallel with enough gates.There are no doubt other tricky<br>
> issues.<br>
<br>
Would it be better to do the fq work in the main CPU and let the FPGA grab<br>
packets from some shared  data structure in memory?  Can you work out a<br>
memory structure that doesn't need locks?<br>
<br>
<br>
--<br>
These are my opinions.  I hate spam.<br>
<br>
<br>
<br>
_______________________________________________<br>
Bloat-devel mailing list<br>
<a href="mailto:Bloat-devel@lists.bufferbloat.net">Bloat-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat-devel" target="_blank">https://lists.bufferbloat.net/listinfo/bloat-devel</a><br>
</blockquote></div>