A colleague recently forwarded this 2014 paper to me: https://www.cs.princeton.edu/courses/archive/spring16/cos598F/06560058.pdf
It's an interesting read. I believe the speedup was based on being able to serve hits for hot keys effectively out of the FPGA which would otherwise forward the request to the main process. This would require your FPGA to be in the hot path from NIC to CPU, though, so that may or may not work for you. IMO this won't work well for small things (e.g. hashing) because the overhead of data transfer alone would be slower than the action performed. Not directly related, but I'd hope you're aware of the in-line network acceleration Microsoft has done in their datacenters. It's some really cool stuff and could enlighten you on techniques to use for an inline accelerator as it relates to parsing network data: https://www.microsoft.com/en-us/research/publication/configurable-cloud-acceleration/ *Scott Mansfield* Product > Consumer Science Eng > EVCache > Sr. Software Eng { M: 352-514-9452 E: smansfi...@netflix.com K: {M: mobile, E: email, K: key} } On Tue, Jan 24, 2017 at 8:11 AM, Ravikiran Gummaluri < ravikiran.gummal...@xilinx.com> wrote: > HI , > We are trying to offload some of the functionality of memcacaheD to FPGA > to accelerate it. We are exploring possibilities of software bottle neck > and accelerating using FPGA’s . If anyone has already done some profiling > and they can help us to understand the functionalities that can improve > performance. Any suggestions are welcome. > > Thanks & Regards > Ravi G > > From: Scott Mansfield [mailto:smansfi...@netflix.com] > Sent: Tuesday, January 24, 2017 7:40 AM > To: memcached <memcached@googlegroups.com> > Cc: Ravikiran Gummaluri <rgum...@xilinx.com>; Venkata Ravi Shankar > Jonnalagadda <vjon...@xilinx.com>; Sunita Jain <suni...@xilinx.com> > Subject: Re: Ordering of commands per connection > > I'm actually also very interested to see anything you can share about your > project. > > On Monday, January 23, 2017 at 12:50:03 PM UTC-8, Dormando wrote: > Hey, > > I've always wanted to try implementing a server with a xilinx chip. Seems > like you folks would be more qualified to do that :) > > The short answer is that the server does guarantee order right now. The > ASCII protocol doesn't work very well if you reorder the results, but > primarily all clients will have been written with that assumption in mind. > > The longer answer is that binary protocol can technically allow > reordering, but it's unclear if any clients support that. Binprot uses > opaques or returns keys to tag requests with responses. > > You can still parallelize an ordered ASCII multiget (ie: "get key1 key2 > key3") by creating the iovec structures ahead of time, doing the > hashing/lookup in parallel and filling the results before sending the > response. > > With binprot each get/response are independently packaged so it's a bit > easier, although the protocol bloat makes it less useful at high rates. > > People have also written papers already on implementing memcached with > FPGA's or highly parallel microprocessors (tilera, MIT's tilera precursor, > etc). Hopefully you're familiar with them before diving into this. > > May I ask if you can share any other details of this project? is it a > proof of concept or some kind of a product? > > have fun, > -Dormando > > On Mon, 23 Jan 2017, Ravi Kiran wrote: > > > HI , > > We are planning to use the MemchaheD software and accelerate it with > hardware offload. We would like to know > > from protocol prospective each connection should maintain the order in > which it receives the command to > > send a response back ? > > for Ex: If we receive GET1 GET2 SET1 GET3 do we need to send the > response in the same order GET1 GET2 SET1 > > GET3 . Can we parallelize commands and send them out off order ? > > > > Thanks & Regards > > Ravi G > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to > > memcached+...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
