From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by huchra.bufferbloat.net (Postfix) with ESMTP id 9481C21F19C; Thu, 20 Dec 2012 02:32:14 -0800 (PST) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 4ABAD800037; Thu, 20 Dec 2012 02:32:13 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Dave Taht From: Hal Murray Subject: Re: hardware hacking on fq_codel in FPGA form at 10GigE In-Reply-To: Message from Dave Taht of "Thu, 20 Dec 2012 04:26:37 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2012 02:32:13 -0800 Message-Id: <20121220103213.4ABAD800037@ip-64-139-1-69.sjc.megapath.net> Cc: bloat-devel , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:32:15 -0000 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.