Bare Metal Blog: FPGAs: Reaping the Benefits
#BareMetalBlog #f5 All the goodness FPGAs bring hardware in general, and ADO hardware in particular.
In two previous installments, I talked at a high level about the uses of FPGAs, risk mitigation, and the potential benefits. Today I’d like to delve into the benefits that the industry in general, and F5 in particular, gain from using FPGAs, and why it matters to IT. If you’re a regular reader, you know that I try not to be a chorus line for F5 solutions, but don’t shy away from talking about them when it fits the topic. That will continue with this post. While I will use F5 for the specifics, the benefits can be generalized to the bulk of the industry.
Used to be, way back in the day, everyone walked everywhere. That worked for a long period of world history. The horse was adopted for longer trips, and it about doubled travel speed, but still, the bulk of the world populace walked nearly all of the time. Then along came cars, and they enabled a whole lot of things. One of the great benefits that the automobile introduced was the ability to be more agile. By utilizing the machinery, you could move from one town to another relatively quickly. You could even work in a town 30 miles – a days’ walk for a physically fit person – from your home. At this point in human – or at least first world – history, walking is a mode of transportation that is rarely used for important events. There are some cities so tightly packed that walking makes sense, but for most of us, we take a car the vast majority of the time. When speed is not of the essence – say when you take a walk with a loved one – the car is left behind, but for day-to-day transport, the car is the go-to tool.
There is a corollary to this phenomenon in the Application Delivery world. While in some scenarios, a software ADC will do the trick, there are benefits to hardware that mean if you have it, you’ll use the hardware much more frequently. This is true of far more than ADCs, but bear with me, I do work for an ADC vendor . There are some things that can just be done more efficiently in hardware, and some things that are best left (normally due to complexity) to software. In the case of FPGAs, low-level operations that do a lot of repetitive actions are relatively easily implemented – even to the point of FPGA and/or programming tools for FPGAs coming with certain pre-built layouts at this point. As such, certain network processing that is latency-sensitive and can be done with little high-level logic are well suited to FPGA processing. When a packet can be processed in X micro-seconds in FPGA, or in X^3 milliseconds by the time it passes through the hardware, DMA transfer, firmware/network stack, and finally lands in software that can manipulate it, definitely go with the FPGA option if possible.
And that’s where a lot of the benefits of FPGAs in the enterprise are being seen. Of course you don’t want to have your own FPGA shop and have to maintain your own installation program to reap the benefits. But vendors have sets of hardware that are largely the same and are produced en-masse. It makes sense that they would make use of FPGAs, and they do. Get that packet off the wire, and if it meets certain criteria, turn it around and get it back on the wire with minor modifications.
But that’s not all. While it was a great step to be able to utilize FPGAs in this manner and not have to pay the huge up-front fees of getting an ASIC designed and a run of them completed, the use of FPGAs didn’t stop there – indeed, it is still growing and changing. The big area that has really grown the usage of ever-larger FPGAs is in software assistance. Much like BIOS provides discrete functionality that software can call to achieve a result, FPGAs can define functions with register interface that are called directly from software – not as a solution, but as an incremental piece of the solution. This enables an increase in the utilization of FPGAs and if the functions are chosen carefully, an improvement in the overall performance of the system the FPGAs are there to support. It is, essentially, offloading workload from software. When that offload is of computationally intensive operations, the result can be a huge performance improvement. Where a software solution might have a function call, hardware can just do register writes and reads, leaving the system resources less taxed. Of course if the operation requires a lot of data storage memory, it still will, which is why I mentioned “computationally expensive”.
The key thing is to ask your vendor (assuming they use FPGAs) what they’re doing with them, and what benefit you see. It is a truth that the vast majority of vendors go to FPGAs for their own benefit, but that is not exclusive of making things better for customers. So ask them how you, as a customer, benefit.
And when you wonder why a VM can’t perform every bit as well as custom hardware, well the answer is at least partially above. The hardware functionality of custom devices must be implemented in software for a VM, and that software then runs on not one, but two operating systems, and eventually calls general purpose hardware. While VMs, like feet, are definitely good for some uses, when you need your app to be the fastest it can possibly be, hardware – specifically FPGA enhanced hardware – is the best answer, much as the car is the best answer for daily travel in most of the world. Each extra layer – generic hardware, the host operating system, the virtual network, and the guest operating system – adds cost to processing. The lack of an FPGA does too, because those low-level operations must be performed in software.
So know your needs, use the right tool for the job. I would not drive a car to my neighbors’ house – 200 feet away – nor would I walk from Green Bay to Cincinnati (just over 500 miles). Know what your needs are and your traffic is like, then ask about FPGA usage. And generalize this… To network switches, WAPs, you name it. You’re putting it into your network, so that IS your business.
Walking in Ust-Donetsk
And yeah, you’ll hear more on this topic before I wrap up the Bare Metal Blog series, but for now, keep doing what you do so well, and I’ll be back with more on testing soon.
Related Articles and Blogs: