hardware hacking on fq_codel in FPGA form at 10GigE
Hal Murray
hmurray at megapathdsl.net
Thu Dec 20 05:32:13 EST 2012
dave.taht at gmail.com said:
>> If I was going to do something like that, I'd build a small/simple CPU
>> the work in microcode.
> There are two ppc 440 cpus already onboard the 10GigE device, I think. It's
> a REALLY NICE fpga.
> I'd also looked at the octeon and the latest arm chipset from TI which I
> can't remember the codename for at the moment...
I wasn't thinking of a traditional general purpose CPU but rather something
special for this problem.
>> How many lines of assembler code would it take?
> I could do a dump of the current code into any given assembly language. It's
> not a lot, but there are a lot of out of band functions.
I didn't mean lines of traditional assembly code. If we want to pursue this,
pick a chunk of c code (not too big) and break it into "lines" where
everything on a line can be executed at the same time. I'll try to sketch a
"CPU" and write the microcode.
> The enqueue and dequeue algorithms are entirely decoupled, with the
> exception of this error handling phase of (out of queue space) One thought
> would be to track packet count on enqueue (this is more "sfq"-like than
> fq_codel-like) which still has a tiny lock...
Stuff that can be reasonably done in the driver should probably be done there
if it saves a lot of work for the microcode. Avoiding out-of-queue-space
might be a good example.
> Well there are a few things that would benefit from moving directly into
> hardware - the 5 tuple hash, for example.
I'm probably missing the big picture. Are you building a router or a server?
A server has socket control blocks. Can the hash be precomputed and stored
there?
That doesn't help with UDP sendto, but I think it would work with TCP.
If you are building a router, does the routing as well as fq-ing have to fit
in the FPGA?
--
These are my opinions. I hate spam.
More information about the Bloat-devel
mailing list