OpenVPN multi-processing-why not

OpenVPN multi-processing-why not
OpenVPN does not handle much. It is well known. I think it is a bit cool to say this every day. Why didn't I handle it more? Let's take a look at how James Yonan (JY for short), author of OpenVPN, has already exceeded code.
OpenVPN 2.0 has no multithreading support, this is the only feature present in
Well, it clearly shows that the OpenVPN 2.0 era does not support multithreading. In the 1.0 era, multithreading exists, but is not used for data transmission, that is, not for data channels. Note: Since the discussion is only limited to the CPU overhead of the processing process, as I thought before, in the 1.0 era, since OpenVPN is just an encrypted tunnel, CPU overhead occurs only when there is data in the tunnel. However, it is unknown when there is data, therefore, it is unwise to use the kernel scheduling mechanism (the kernel's task entry scheduling is based on a series of predictions ), therefore, the CPU overhead is only calculated in the TLS handshake phase of the control channel (for non-SSL scenarios, pre-shared keys and user name/password verification are only weaker than SSL, therefore, OpenVPN only applies additional threads to this negotiation phase. In the data transmission phase, OpenVPN only uses one thread and implements its own packet schedule mechanism internally.
The original rationale for having the TLS thread optimization was to improve
The benefits are not enough to make up for the cost, so it is so simple. I think it would be much better if OpenVPN was just customized for Linux. It seems that good software is not only the most efficient for a specific platform, but also the runability of all platforms. How did JY draw conclusions on this issue? First, let's take a look at JY's explanation:
Keep in mind that people use multithreading:
The idea is super clear and extremely clear (maybe I have found my resonance). He doesn't negotiate a specific, special, 100 + ms SSL handshake for one hour, the user name/password verification process is a bottleneck. At the same time, the efficiency of symmetric encryption in the transmission of data channels is a fixed value. All the key points to improve efficiency are: how to improve transmission performance, this idea is unbiased and objective. Why do I say so? For those who are concerned about the SSL protocol, he first focuses on the SSL performance because he has experience and capabilities in SSL optimization. In fact, this kind of preference may have shifted; for those who are interested in the network, he always focuses on multithreading, multi-nic queues, and so on, because he pays attention to this information every day. In fact, this kind of preference is certainly not the right way. JY objectively analyzes the two methods and considers SSL as a kind of action that only occupies a small part of the running time. The special phenomenon is not enough to become a bottleneck and there is no need to increase complexity for its independent thread, similarly, packet scheduling in the transmission phase is not under the control of OpenVPN, and multi-processing is not considered by OpenVPN. Therefore, he gives the conclusion:
Answer: Run multiple server mode daemons on different ports, and have
Yes, it is done externally!