Time to make tasks faster: Hardware acceleration

Hardware (HW) acceleration is a method to speed up the processing of any task that would require a lot of computation from a typical Central Processing Unit (CPU) in a workstation or a server. Such tasks can be ooaded to a specic processing unit, an accelerator, that has been specially developed for the given task.

Hardware acceleration can take place in either a Graphics Processing Unit (GPU), a special section in the CPU, a Field Programmable Gate Array (FPGA) or in an Application-Specic Integrated Circuit (ASIC). Usually though, a GPU or some instruction set in a CPU are used because they are relatively easy to set up. Although the FPGA and ASIC solutions are very ecient, they often require a lot of work.

In fact, a GPU is a very good example of a HW accelerator, as its main purpose is to help the PC's CPU generate an image on the screen. Image- processing tasks are ooaded from the CPU to the GPU. Additionally, the GPU may aid the CPU with, for instance, video encoding/decoding tasks [4].

Task acceleration with a General Purpose GPU (GPGPU) [52] means that the GPU is not just conned to video. For instance Nvidia has developed a parallel computing platform, which is a Compute Unied Device Architec- ture (CUDA), that can run a vast number of computationally heavy processes concurrently in their GPUs [104]. The CUDA can be used with machine learn- ing, for example with the TensorFlow neural network [166] or with a network

Intrusion Detection System (IDS) [173].

Even though a CPU is generally regarded as a non-accelerated device, it might have some special logic section that can be regarded as an accelerator. The AES-NI presented in 2.3.4 is actually a HW accelerated version of the AES suite, e.g. in Intel CPUs [69]. AES-NI was used in a case study by Intel and was proved to have signicant performance gain as compared to traditional AES usage [70]. The QuickAssist Technology (QAT) HW accelerator block is another CPU-integrated HW accelerator. It was developed by Intel and used, for instance, in their Xeon D-1600 series [149]. The QAT oers a set of accelerators for [97] for cryptographic and data-compression operations. The use of a CPU-integrated HW accelerator is ingenious since the CPU can ooad data to it whenever possible. The data stays inside the CPU, which not only decreases the time spent on data transfer but also reduces the risk of data leaks compared to an external HW accelerator.

FPGA is an integrated circuits device that holds a number of congurable blocks and input/output (I/O) ports [159]. With these blocks and ports, it is possible to congure the FPGA to work on a particular task, such as a calculation. An FPGA runs on a relatively low clock frequency compared to a PC, but its eciency stems from the highly parallel hardware operation of the task [159].

The ASIC is another integrated circuit, although unlike an FPGA, it is not recongurable. ASIC chips are built to perform their own function, and nothing else. However, their performance is much better than an FPGA's and they consume much less power [157]. Probably the best-known standalone ASIC accelerators are the ones that have been created for Bitcoin mining [175]. A System on a Chip (SoC) is an ASIC design that holds a number of smaller elements including processors, memory, and also sometimes accelera- tors. Mathew et al. [89] has presented an AES HW accelerator called nanoAES that is especially targeted for mobile SoC platforms with only 13 mW total power consumption. The nanoAES is capable of AES-128 encryption of 432 Mbps. This kind of low-power solution is especially important in relation to the Internet of Things (IoT), as IoT devices can vary greatly, from large, high- performance devices to hand-held, ultra-low-power constrained devices.

FPGA solution outdoes the GPU solution due to its combination of recong- urability and performance [20]. A GPU suers from its static architecture, such as the CPU, whereas an FPGA can freely be edited. On the other hand, build- ing an accelerator for a GPU is a much simpler task than it is for an FPGA. An FPGA solution requires a lot of extra work from the developer team [20]. The drawback with ASICs is that they are extremely expensive unless the produc- tion numbers are huge. For these reasons, the FPGA suits most purposes and is an almost universal accelerator in that it can be freely congured to perform almost any desired task. For instance, Salman, Rogawski and Kaps [147] have used FPGAs for IPsec cryptographic operations and Sjovall et al. [158] for 4K video encoding.

FPGA accelerators usually use either a Universal Serial Bus (USB), a PCI express (PCIe) or the Ethernet network to transfer data from, e.g. a PC to an FPGA. Neil and Liu [99] presented a neural network FPGA accelerator and implemented it in a USB-attached FPGA development board. In contrast, Sjovall et al. [158] used a PCIe interface in their video accelerator to insert the FPGA accelerator into a rack-installable server. A much more ambitious approach aimed at providing FPGA acceleration for a whole network in one go was considered by Cauleld et al. [19]. They installed FPGA accelerator boards between the servers and switches in a Cloud platform. This provided direct, dedicated, accelerators for every single bare-metal server in the cloud.

It seems that in the long run it is better to run accelerators directly in the network. The SDN then becomes an ecient method for redirecting the network packets, as stated earlier in subsection 2.2.3. As an FPGA is a freely congurable platform, Naous et al. [98] has implemented an OpenFlow switch on one. Their solution is capable of line-rate switching and the writers found their solution to be very feasible due to its relatively low area consumption of 34% in a netFPGA platform [98].

3 ANSWERS TO QUESTIONS:

PUBLICATIONS GET TIED UP

This chapter will establish the links between the publications for this thesis. Publication I and Publication II discuss the SME business and thus answer the rst research question, the approach to which is explained in section 3.1.

The second research question is more about enterprise VPN solutions, which are discussed in section 3.2 and are based on Publication III and Publication V.

3.1 Resilient VPN connections with an IP zero