From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0459421F17D; Thu, 20 Dec 2012 06:18:23 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id y25so2821160iay.5 for ; Thu, 20 Dec 2012 06:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OQR2K9i1C/FxPMUgTqMxqb5v68/C09ArDsOsW6amiZw=; b=qMV5OyzDokKdTvM9ZXh6TCzjNcVy68sCo326ZBY5kyxCRESwezWGHScJ1tH2F5zlpr 38EZKkfp6KXyooVNnctPwTOOKS1cSHF2jUD4jg1Ey52ZjNyXAtcJ3aJTxe3oU4EweJb7 7PY1qJWcMfg0p3HHVdITD5ON1FkE5NYkRiCbEI0jmiPsxA8IypcFdC51DGcxHa+DLDnj sX+3WfClbPnQOk1hMi3+NU9QtpWbs+Kcof+/dDK2sxEK6sr105tVXOA7J/hw6jzbtpHR eWSWYfySfD/GssUohoTqSuNQzNmG++Hnc8nu0m+dbEctI5WBor2DqODr0pNE2hxRZx15 Fgdg== MIME-Version: 1.0 Received: by 10.50.88.136 with SMTP id bg8mr5609557igb.96.1356013103161; Thu, 20 Dec 2012 06:18:23 -0800 (PST) Received: by 10.64.135.39 with HTTP; Thu, 20 Dec 2012 06:18:23 -0800 (PST) In-Reply-To: <1356011592.2372508@apps.rackspace.com> References: <20121220103213.4ABAD800037@ip-64-139-1-69.sjc.megapath.net> <1356011592.2372508@apps.rackspace.com> Date: Thu, 20 Dec 2012 09:18:23 -0500 Message-ID: From: Dave Taht To: dpreed@reed.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat-devel , Hal Murray , cerowrt-devel@lists.bufferbloat.net, codel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] hardware hacking on fq_codel in FPGA form at 10GigE X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:18:24 -0000 On Thu, Dec 20, 2012 at 8:53 AM, wrote: > I have lately been using (for my very wideband software defined radio > amateur radio transceiver project) the brand new, very nice device called > the Zynq 7000 series of Platform FPGA's from Xilinx. It's a complete sys= tem > on a chip, with a dual core ARM Cortex A9 and an enormous amount of > programmable logic that has "cache coherent access" to the memory system. > > > > The chip is fabricated in 28 nm form, has a "zillion" SelectIO programmab= le > pins, but more importantly has a bunch of hard logic I/O paths. > > > > Since it comes packaged "cheap" (full 6 inch square evalboard with 512 M= B > DRAM and full standard "PC type" interconnects - GigE, VGA, HDMI, USB), a= s a > $299 board with free FPGA tool chain) and runs Linux out of the box, I > highly recommend the board called Zedboard (just google that). Their documentation is first rate! http://www.zedboard.org/sites/default/files/documentations/ZedBoard_HW_UG_v= 1_6.pdf > Easy to attach 10 GigE hardware if you can do simple PCB design and > soldering. The 10GigE thought was mostly because that's what's driving most of the decision making behind doing these huge network offloads on the host processor. Which is so problematic when it migrates out of the data center/talks to stuff outside of the datacenter and/or the software concepts end up in devices that need to run well at 100Mbit and below. So thoroughly solving the fq/codel problem in hardware at that level will head off the next worldwide problem when these devices become more affordable. And (IMHO) make them work better. > You can be up and running with a development system for under $500 in a > weekend, building FPGA acceleration, or if you want to add hardware that > connects to the zillions of I/O pins to the PLL and memory system, that > might take a week or more, depending on your hardware design and hacking > skills. I've connected "eval boards" of various sorts using a breakout bo= ard > you can buy from Xilinx quicker than that. > > > > In some ways, this is the Raspberry Pi of high speed digital logic hackin= g. You should give them that quote. And I'll order one. Heck, maybe two. Real find! Thanks! How far along is your SDR project? > > > > > > > > > > -----Original Message----- > From: "Hal Murray" > Sent: Thursday, December 20, 2012 5:32am > To: "Dave Taht" > Cc: "bloat-devel" , > codel@lists.bufferbloat.net, "Hal Murray" , > cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] hardware hacking on fq_codel in FPGA form at > 10GigE > > > 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 somethi= ng > 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 th= is, > 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 thoug= ht >> 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 serv= er? > > A server has socket control blocks. Can the hash be precomputed and store= d > 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. > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html