On Wed, Aug 6, 2014 at 3:36 PM, David Sommerseth
<openvpn.l...@topphemmelig.net> wrote:
>
>> For the typical road-warrior scenario (one server, many clients)
>> you are probably right that a single user won't benefit much from
>> data-channel threading. However, in a high-capacity site-to-site
>> link, many concurrent connection by many users are handled by a
>> single connection instance. In this case threading would enable
>> processing multiple network packets concurrently. Though that does
>> not speed up processing of a single packet, it will speed up the
>> total connection almost linear to the number of cores.
>
> +1
Don't you really want to throw this case at hardware ssl offload?
> Even though it might look easier to implement a solution similar to
> Apache's prefork model, I'm not convinced that approach will be easier
> to implement in OpenVPN's context. Plus, if you start adding more
> processes than cores, the result will be worse.
Maybe - you are the code expert here, but doesn't this mean you either
have to start from scratch or find every possible thread contention in
the code? Or lock to the point that you essentially serialize anyway?
> Yes, splitting up the tasks OpenVPN does over multiple
> threads/processes is a harder task. But I feel quite confident that's
> the approach which will scale best.
Given that scaling beyond one CPU hasn't been a priority at all so
far, does the 'theoretical best' approach justify the debugging
complexity?
--
Les Mikesell
lesmikes...@gmail.com
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
