openvpn and system overhead

Eugene Grosbein eugen at grosbein.net
Thu Apr 18 00:02:17 UTC 2019


18.04.2019 6:11, Eugene Grosbein wrote:

> 17.04.2019 22:08, Wojciech Puchar wrote:
> 
>> i'm running openvpn server on Xeon E5 2620 server.
>>
>> when receiving 100Mbit/s traffic over VPN it uses 20% of single core.
>> At least 75% of it is system time.
>>
>> Seems like 500Mbit/s is a max for a single openvpn process.
>>
>> can anything be done about that to improve performance?
> 
> Anyone concerning performance should stop using solutions processing payload traffic
> with userland daemon while still using common system network interfaces
> because of unavoidable and big overhead due to constant context switching
> from user land to kernel land and back. Be it openvpn or another userland daemon.
> 
> 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.

Just to clarify: mpd5 still uses common networking stack and system interfaces ng0, ng1 etc. for p2p-tunnels
but it does not process tunneled traffic leaving the job to the kernel.

Back in 2011 I did some measures of my production mpd5 installation serving real PPPoE users
with FreeBSD 8 and mpd5, SuperMicro SuperServer 5016T-MTFB, Intel Xeon CPU E5507 @ 2.27GHz (4 cores)
and four 1GB Intel NICs (two on-board 82574L em0/em1 and single two-ports 82576 card igb0/igb1).

It processes 1812 simultaneous sessions when each CPU core had 90% load (2% user time and 88% system time approx.)
forwarding 1184.9Mbit/s to users plus 830.9Mbit/s from users (2015.8Mbit/s in total)
and dealing with 136.2Kpps in+120.3Kpps out for lagg0 (em0+em1, IP-only uplink) and
139.0Kpps in+154.3Kpps out for lagg1 (igb0+igb1, downlink with PPPoE/vlans and no IP).
It processed 102K interrupts per second then.

There was no encryption involved and numbers basically describe packet forwarding/filtering/shaping
ability of the kernel those days.



More information about the freebsd-hackers mailing list