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 F2DA921F19D; Thu, 20 Dec 2012 01:51:51 -0800 (PST) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 63712800037; Thu, 20 Dec 2012 01:51:51 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Jonathan Morton From: Hal Murray Subject: Re: hardware hacking on fq_codel in FPGA form at 10GigE In-Reply-To: Message from Jonathan Morton of "Thu, 20 Dec 2012 10:27:11 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2012 01:51:51 -0800 Message-Id: <20121220095151.63712800037@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 09:51:52 -0000 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.