[openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

Fedor Indutny via RT rt at openssl.org
Sat Feb 6 04:24:35 UTC 2016


On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 05/02/16 22:42, Fedor Indutny wrote:
> > Matt,
> >
> > I have looked through the APIs. Will have to experiment with them
> > somewhen later to see how well they will perform, but from theoretical
> > point of view I am a bit scared of having 2 fds (and one ucontext) for
> > every job in a pool. It seems like this could be a bit of burden in
> > event-loop based model. For example, it is not hard to imagine a
> > situation in node.js application with 10000 handshakes that are trying
> > to complete in parallel. Is there any need in creating this fds
> > unconditionally?
>
> Well of course the number of jobs in the pool is not the same as the
> number of handshakes. We create a pool of jobs that are shared between
> the handshakes as required in order to conserve resources. With regards
> to the fds, I mentioned that I was working on some tweaks to the API. It
> is in this area where there are tweaks being made. Specifically I am
> moving the creation of the fds to be a responsibility of the called code
> (i.e. most likely an engine) and not the async framework itself.
>

I understand what the pool means ;) The imaginary situation that I was
talking about had lots of handshakes happening in parallel. To make it a
bit real: a server that decrypts premaster secrets remotely with 2000ms
latency, that receives 1000 requests per second. In such situation pool
size needs to be at least 2000 to accommodate this amount of requests.

While 2000ms is a bit far-fetched, it is very easy to imagine that that
remote decrypting server will go absolutely down and won't respond at
all. Meaning that for some period of time (maybe 5-10 seconds) all this
load is going to attempt to take new job from the pool. While I'm sure that
SSL structures itself will take a huge stake in resources usage, having
extra fd for each of these jobs doesn't sound right to me.

I'm glad to hear that this fd-behavior is going to be overridable. This
sounds lovely!


>
> > However, again, this is only a hypothetical situation, I'm yet to see
> > how well it will behave in real situations. Just sharing some immediate
> > concerns with you.
>
> I have been collaborating with Intel on this piece of work and they have
> been testing the performance quite thoroughly. We are still working on
> optimising things, but so far so good.
>
>
Fantastic!

Thank you very much,
Fedor.


> Matt
>
>
> >
> > Thank you,
> > Fedor.
> >
> > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT <rt at openssl.org
> > <mailto:rt at openssl.org>> wrote:
> >
> >     Thank you very much, Matt, Rich.
> >
> >     I will read through these docs tomorrow.
> >
> >     On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT <rt at openssl.org
> >     <mailto:rt at openssl.org>> wrote:
> >
> >     >
> >     >
> >     > On 04/02/16 06:34, Salz, Rich via RT wrote:
> >     > > It’s late and my response was incomplete.
> >     > > The other part has already landed in master, and that's the
> "async
> >     > engine" support.
> >     >
> >     > See:
> >     >
> >     > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> >     > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html
> (i.e.
> >     > the SSL_MODE_ASYNC bit)
> >     >
> https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
> >     >
> >     > I'm working on a patch that may make some tweaks to this API, but
> you
> >     > should get the idea.
> >     >
> >     > Matt
> >     >
> >     >
> >     >
> >
> >     _______________________________________________
> >     openssl-dev mailing list
> >     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> >
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528
Please log in as guest with password guest if prompted



More information about the openssl-dev mailing list