Use a network accelerator card on Linux to improve forwarding Performance

Linux has always been impressed by the server level. Although some people use it as a desktop or a mobile phone, it is a minority, almost no one has ever put it on the backbone network as a router, even if it is the access layer, almost no one uses Linux. The Netfilter mechanism can change this fact, because the Netfilter mechanism is too powerful, it almost allows you to completely re-customize the protocol stack behavior.
Don't think that Netfilter is only used by Firewall/NAT software such as iptables. In fact, Netfilter is a unified filtering framework, and its essence is that it can intercept data packets in some parts of the protocol stack, then, how do you process the intercepted data packets? That's your own business. For iptables, it only executes a series of matches and then executes a target, however, Netfilter can do more.
I have heard of network accelerators for a long time, but I have always felt that optimization of some algorithms by software is definitely impossible to increase the performance statistics by an order of magnitude. I must have some hardware help, even a Cisco Professional-level device uses a large number of ASIC chips to forward packets. In fact, it uses a hardware cache mechanism. If these hardware can also be inserted into the gateway running Linux, the network forwarding performance of Linux will inevitably be greatly improved. However, hardware insertion is very simple. How can we make the software work with the hardware? We know that the combination of hardware and no software is a pile of waste products. Therefore, it is easy to let the inserted acceleration card work under the guidance of the software. We have to modify the Protocol Stack code.
Fortunately, Linux has Netfilter, which makes it much easier. How to operate the accelerator card hardware is a hardware manufacturer's business. If the purchased hardware does not have a development manual, it is actually a pile of waste. Therefore, you must have a development manual for the purchased hardware. At least you must provide APIs that can be used on each platform. You can also give some demos as appropriate, in this way, we can complete the access of new hardware based on the API and Demo. For some platforms, you may need to develop a new protocol stack for the new hardware. This is purely for interconnection with hardware. However, for Linux platforms, the built-in Netfilter framework helps you easily connect to the accelerator card. Shows the general architecture:


 
Many hardware network accelerator cards have a built-in Gigabit or even 10-Gigabit Ethernet card, which means that the accelerator card driver itself includes an Ethernet Card Driver. In this case, hardware drivers are provided by the vendor. You only need to operate the hardware based on the vendor's API, these codes do not need to be placed in a single program. Instead, they can be connected to the Netfilter function. We can develop an nf_hook_ops independently or modify the existing Code, for example, according, the vendor provides an ASIC chip for wire speed forwarding. How can we achieve fast stream-based forwarding? In fact, we can modify ip_conntrack_in and the confirm function so that the initialized nf_conn information is not stored in the kernel memory, but stored in hardware through APIS. In fact, in most cases, only one stream header package will arrive at the kernel, other subsequent packages are directly forwarded by ASIC, And the header package continues to go up. If the filter table is reached, the filter result is also saved to the hardware. This is really a hardware Firewall, then, the routing information (mainly the information of the egress device) is stored in the hardware, so that the hardware accelerator card has all the information required to forward a data packet, the next package is directly forwarded by the hardware, and you do not need to enter the kernel.
In essence, the so-called hardware accelerator card is a series of Cache lines, which are implemented by hardware. They have a huge capacity and are not comparable to the software. They map a series of static tables on the software, such as route tables, arp tables, and policy tables, into a series of Cache lines, and add complex logic switches to achieve fast forwarding. This is one of the features of the hardware accelerator card. The second is to provide rich and easy-to-use APIs to reduce the development workload of R & D personnel. The next step is the platform selection of developers, selecting Linux can minimize the workload. With the network accelerator and Linux, anyone can DIY a super-powerful Gateway by themselves. Currently, I want to find the cheapest accelerator card and then use the cheapest PC that has been eliminated, add free Linux, so that ,... even so, I have no way to do stress testing...
Today's hardware is becoming more and more customizable, and many complicated policies that should have been completed by software can be completed by hardware, thanks to the improvement of the integrated circuit process level, in the face of increasingly powerful hardware, it seems that complicated software cannot keep up with the pace. Recently, I am conducting stress tests on OpenVPN, so I am very uneasy. I don't want to use too high-end hardware, because it almost cannot greatly improve the performance of OpenVPN, it is even more difficult to think That OpenVPN has slowed down... in a MB environment, the difference between using OpenVPN to transmit encrypted data and without using OpenVPN is only the difference between encryption and non-encryption, the performance is almost only affected by the encrypted bandwidth of the CPU (there is no need to use an encrypted card). However, in a gigabit environment, the performance difference between the two is an order of magnitude, in addition to CPU encryption, OpenVPN is a software architecture. Therefore, the software is far behind the development of hardware. Why did it cause such an embarrassing situation? Should I think over it carefully when the application is so rich today.

From the harvest of dawn