Linux Kernel version of OpenVPN, incomplete View of ghosts, openvpnlinux
It's time to give a general picture.
I mean, why do we have to port OpenVPN to the kernel instead of optimizing it in the user State. Why? In fact, I have optimized it in user mode. Although some segment fault is difficult to locate, it does not mean that I have no time to handle these problems, it is difficult to roll back to the kernel (it is not difficult to roll back to the kernel when it comes to panic). This is not the case. My intention is, and it has always been, to shorten the length of the processing path, I never believe in any software myth. In fact, I hate these myths. As a netizen said, why do we need to distinguish between kernel States and user States! The key point is not in which State the processing efficiency is high. The key is that the processing path length is different. As some people have said, the data plane must be processed in the user State. In fact, it means that data packets are directly captured in the user State at the driver level, in essence, the length of the processing path is shortened, So I plot the following, and the dotted line represents the existing path:
In the multi-core era, multi-core processing is really too simple, as long as the process is scheduled to different CPU cores using softirq or tasklet, there are so many complicated rules such as epoll. But this is not to say that writing code in the kernel state is fine, provided that you can control it! Not only is it panic, oops... More importantly, even if you can handle this, you cannot take a system as a single-chip computer, because you violate the basic principles of software design. This is why I don't like embedded systems. Processing logic in the kernel is extremely nonstandard unless you know what you are doing. In fact, everything that can be done in the kernel state can be done in the user State. The key is that you have to know how to do it. If you don't want to copy the buffer, you can use map, if you want to shorten the protocol stack processing path, why don't you just learn PF_RING and flat the user State... but the question is, do you know how to do this?
At the beginning of this year, I learned one thing. If you want to master a technology similar to PF_RING, of course, not PF_RING, but a vendor's API, you have to attend expensive training, it is very difficult for an individual to bear a considerable cost. As a company, even if the cost is not a problem, it also means to unify the previous architecture into the new architecture, this is completely different. Unless a single line is opened, the price of compatibility cannot be compensated.
What are the OpenVPN code processing? Most code processes the buffer and packet scheduling of data packets. These are pure data planes. However, the control plane code of OpenVPN and the data plane Code are in a large while loop. Separating them is a common idea. The data plane buffer management granularity of OpenVPN is too coarse. The whole loop uses the same buffer, but the buffer content is changed at the end of a loop, therefore, it is difficult to split the loop into multiple processing results, because this means that the entire buffer needs to be locked during the processing process. As a result, you have to copy the entire large loop into multiple copies. This effect is obvious, but it involves the same problem of the control plane, can the logic processing of the control channel in a while loop affect another while loop? If not, it means that a management layer must be encapsulated externally. This is what the tun driver of my multi-queue is doing, which leads to a high degree of coupling between the driver and OpenVPN. If yes, the control channel will in turn affect the processing process of other while LOOP data channels .. this is a dilemma. I don't know why James Yonan removed the multithreading he was going to add. Do he realize this too? Hard to say, hard to say...
How is it? After the book "UNIX network programming" has created an age that has influenced three generations of programmers, everyone is unable to extricate themselves. This is a feat of the whole world! Network programmers all over the world are crazy about sockets. They have set one sockopt after another, and cork has countless buffers. Everyone is scrambling to poll, and then epoll. At the same time, they laugh at the Ancients who are still in select, and I, as a person of the Stone Age, are still using artifacts like while (1) {recv; send... this is the status quo and continues... in this case, if there is any way to bypass all this, can you just give it a try? Just for myself, and you don't have to use UNP to hit me. The book is really thick, but it doesn't mean I won't fight back and look at my case:
