Date: Wed, 17 Apr 2019 18:40:03 -0500 From: Jim Thompson <jim@netgate.com> To: Eugene Grosbein <eugen@grosbein.net> Cc: Wojciech Puchar <wojtek@puchar.net>, freebsd-hackers@freebsd.org Subject: Re: openvpn and system overhead Message-ID: <ACE6415A-549E-4349-BB70-E4C1ECA08BCB@netgate.com> In-Reply-To: <0cc6e0ac-a9a6-a462-3a1e-bfccfd41e138@grosbein.net> References: <alpine.BSF.2.20.1904171707030.87502@puchar.net> <0cc6e0ac-a9a6-a462-3a1e-bfccfd41e138@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 17, 2019, at 6:11 PM, Eugene Grosbein <eugen@grosbein.net> = wrote: >=20 > 17.04.2019 22:08, Wojciech Puchar wrote: >=20 >> i'm running openvpn server on Xeon E5 2620 server. >>=20 >> when receiving 100Mbit/s traffic over VPN it uses 20% of single core. >> At least 75% of it is system time. >>=20 >> Seems like 500Mbit/s is a max for a single openvpn process. >>=20 >> can anything be done about that to improve performance? >=20 > 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. >=20 > 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 =E2=80=98stack=E2=80=99 inside OpenVPN = is single-threaded/single packet at a time. Also, you=E2=80=99ll need to multiplex > 1 instance of OpenVPN, maybe = using the programability of VALE (aka =E2=80=98mswitch=E2=80=99). Linaro=E2=80=99s Open Data Plane project did a shim that would talk via = shared memory (ODP queues) between OpenVPN and ODP. ODP queues = aren=E2=80=99t too different from netmap rings,=20 so a PoC based on this code would be straight-forward. "This demo was = not intend to improve performance, it was only for basic functionality." https://github.com/repu1sion/odp_apps/tree/master/openvpn Jim=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ACE6415A-549E-4349-BB70-E4C1ECA08BCB>