Re: hardware hacking on fq_codel in FPGA form at 10GigE

[Hal Murray <hmurray@megapathdsl.net>]

dave.taht@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.