openvpn and system overhead

[Kurt Lidl]

On 4/19/19 12:45 PM, Wojciech Puchar wrote:
>>>
>>> You need either some netmap-based solution or kernel-side vpn like 
>>> IPsec (maybe with l2tp).
>>> For me, IKE daemon plus net/mpd5 work just fine. mpd5 is userland 
>>> daemon too,
>>> but it processes only signalling traffic like session establishment 
>>> packets
>>> and then it setups kernel structures (netgraph nodes) so that payload 
>>> traffic is processed in-kernel only.
>>
>>
>> Addendum to previous message to freebsd-hackers:
>>
>> We have (also) considered a netmap-enhanced (enabled?) OpenVPN.  You 
>> still have the problem that the ‘stack’ inside OpenVPN is 
>> single-threaded/single packet at a time.
>>
>> Also, you’ll need to multiplex > 1 instance of OpenVPN, maybe using 
>> the programability of VALE (aka ‘mswitch’).
>>
> there is no problem that openvpn is single threaded. i can easily divide 
> things over multiple openvpn processes.
> 
> The problem is CPU load it produces. It will not be smart to use up 
> whole 8 core machine just to provide 3-4Gbps of VPN traffic with no 
> spare power to do actual work.
> 
> i found that most of time openvpn executes system call, encryption takes 
> little time.
> 
> if FreeBSD would be able to provide multiple packets per read/write call 
> from/to tun device, as well as send/recv would have multipacket version 
> - it would mean speeding it up at least 4 times.

Well, FreeBSD does have sendmmsg()/recvmmsg(), which allows for
sending/receiving multiple packets per system call.  I do not know if
the "tun" device allows for send/recv type processing, or just
read/write.

Don't get me wrong -- having in-kernel processing, like ipsec does, is 
far superior to doing it as a userland daemon, IMHO. Just pointing out
that there is a multi-packet system call that could be used, possibly,
to make the userland solution less horrible.

-Kurt