[email protected] 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. _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
