Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Hal Murray <hmurray@megapathdsl.net>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: bloat-devel <bloat-devel@lists.bufferbloat.net>,
	codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net
Subject: Re: hardware hacking on fq_codel in FPGA form at 10GigE
Date: Thu, 20 Dec 2012 01:51:51 -0800	[thread overview]
Message-ID: <20121220095151.63712800037@ip-64-139-1-69.sjc.megapath.net> (raw)
In-Reply-To: Message from Jonathan Morton <chromatix99@gmail.com> of "Thu, 20 Dec 2012 10:27:11 +0200." <CAJq5cE1SEopk_vDrRjdUFhzoJhZ-6b3f0=Tr68DK0nFEePP6qw@mail.gmail.com>


chromatix99@gmail.com said:
> 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. 

I was thinking of a small/simple CPU with a wide instruction word to simplify 
instruction decoding.  We used to call it microcode rather than software.

My straw man would be an ALU that can add and compare and whatever else you 
need, an instruction field for loading various hardware control registers and 
another field for writing control registers, and other fields for 
setting/testing flags and such.  We used to put a next-instruction-address 
field so there was no ALU for the PC.  Branching was done by ORing bits into 
the PC.


> 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.

Sounds about right.

> Dedicated logic that *is* fast enough to run the algorithm on each packet
> shouldn't be any bigger than such a CPU.

You still need to describe the algorithm.  That's going to be some sort of 
FSM.  How many steps (clock cycles) will that take?

I think the key idea behind what I was trying to say is that as soon as the 
algorithm gets reasonably complicated, you probably want to think of it as 
software rather than hardware.

The sort of microcode I'm thinking of should be a reasonable way to describe 
that type of algorithm.  If it can't come close to what raw hardware could do 
then the design of the instruction set should be fixed.





-- 
These are my opinions.  I hate spam.




  reply	other threads:[~2012-12-20  9:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <dave.taht@gmail.com>
2012-12-20  7:28 ` Dave Taht
2012-12-20  8:17   ` Hal Murray
2012-12-20  8:27     ` Jonathan Morton
2012-12-20  9:51       ` Hal Murray [this message]
2012-12-20  9:13     ` Dave Taht
2012-12-20  9:26       ` Dave Taht
2012-12-20 10:32         ` Hal Murray
2012-12-20 13:53           ` [Cerowrt-devel] " dpreed
2012-12-20 14:18             ` Dave Taht
2012-12-20 15:05               ` Dave Taht
2012-12-21 12:34                 ` Dave Taht
2012-12-21 17:48                   ` dpreed
2012-12-21 18:14                     ` Jim Gettys
2012-12-21 18:25                       ` dpreed
2012-12-21 18:45                         ` Jim Gettys
2012-12-21 19:34                           ` dpreed
2012-12-21 19:42                             ` Jim Gettys
2012-12-21 21:54                           ` [Codel] " David Woodhouse
2012-12-21 21:56                             ` John Crispin
2012-12-21 22:08                               ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121220095151.63712800037@ip-64-139-1-69.sjc.megapath.net \
    --to=hmurray@megapathdsl.net \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=codel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox