openvpn: enable DCO by default

[sideeffect42]

Description:

Enable DCO by default in the openvpn package to allow for better performance and have a use case for kmod-ovpn-dco-v2. 🙂

Fixes #22472

[BKPepe]

If there is a better performance for DCO. Do you have some actual numbers to see the difference in the performance? With and without DCO? And also, would be good to have some size difference, when it is enabled or disabled.

[luizluca]

If there is a better performance for DCO. Do you have some actual numbers to see the difference in the performance? With and without DCO? And also, would be good to have some size difference, when it is enabled or disabled.

https://blog.openvpn.net/openvpn-data-channel-offload/

Also, one big issue without DCO in a medium-sized OpenVPN is that it does not paralelize. No matter how many procs you have, it would stick with a single one per openvpn instance. I have to split my clients between multiple instances just to workaround it.

(I did not tested in production DCO yet)

[sideeffect42]

If there is a better performance for DCO. Do you have some actual numbers to see the difference in the performance?

Yes, performance is the only reason DCO was developed.

OpenVPN historically runs in user space which makes it very portable, but it is also very restrictive to performance, because every incoming network packet is received by the kernel, then copied to user space where OpenVPN decrypts and processes it, then copies it back to the kernel which then routes the packet and if it is for the local machine, copies it to some other user space process again (in reverse for send).
DCO gets rid of two kernel/user copies by doing the decryption directly in kernel.

Also, as @luizluca mentioned, OpenVPN was written in a time when CPUs had a single core. If you want to make use of multiple cores you currently have to run one instance of OpenVPN on a different port for every core you want to utilize and then balance the connections in the client config.
DCO on the other hand makes use of multiple kernel threads, meaning you can use multiple cores on a single port, as it should've always been.

In general the difference in performance is significant, we're talking about "times" not "percents".
But in general, systems with more cores and crypto accelerators will benefit more from it than your 600 MHz single-core MIPS plastic router from 2010 😄.

And also, would be good to have some size difference, when it is enabled or disabled.

The size difference in the openvpn binary should be negligible, because all of the additional DCO code is in kmod-ovpn-dco-v2. Enabling this option just adds a new code path to set up the kernel module to handle data traffic instead of doing it in the user space process.

But, for some reason, this package's Makefile was written to add kmod-ovpn-dco-v2 as a DEPENDS when this option is enabled, so there will be an additional space requirement of about 30 kB.
Technically the kmod-ovpn-dco-v2 package is optional; a DCO-enabled OpenVPN will work perfectly fine without the kmod, just without DCO.
The only effect of this DEPENDS is "convenience".

Also, just to avoid possible confusions: enabling DCO here forces nobody to use DCO. There is always the disable_dco option which users can add to their server config to disable DCO completely, independant of whether the kmod is present or not.

(I did not tested in production DCO yet)

I did, though not on OpenWrt. No problems whatsoever.