trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Carroll <solidwallofc...@oath.com>
Subject Re: Openssl 1.1.0f Support
Date Thu, 21 Sep 2017 13:12:58 GMT
Kees - I think Dave and/or Susan tried the thread off loading approach. I
think it is mentioned in the presentation cited above. IIRC that ended up
not working well for some reason.

On Thu, Sep 21, 2017 at 2:49 AM, Kees Spoelstra <kspoelstra@we-amp.com>
wrote:

> Hi Dave and Jeremy,
>
>
>
> We were also looking into using Intel QAT, the AES was not of interest to
> us , mostly improving the RSA handshake phase.
>
>
>
> Not having looked at the API, I wonder if we would able to offload the
> handshake part to threads which handle the openssl-async stuff, and after
> the handshake go back to normal processing.  Performance of SSL handshakes
> is bound by raw CPU and pretty low in rq/s, so the overhead in thread sync
> could be negligible.  Any thoughts about that?
>
>
>
> We’re pretty busy here, but I’m going to check here if we can burn some
> cycles on looking into this. Any other insights from the tests at yahoo are
> welcome.
>
>
>
> Kees
>
>
>
> *From:* Dave Thompson [mailto:davet@oath.com]
> *Sent:* Wednesday, September 20, 2017 23:17
> *To:* users@trafficserver.apache.org
> *Subject:* Re: Openssl 1.1.0f Support
>
>
>
> Sorry Jeremy, my recollections were from 16 months ago which is fuzzy by
> now at best.   The gist of my recollection is that QAT is an IO based async
> engine, which of course ATS already has done extensively.   I recall the
> under-the-hood QAT longjumping was a non-starter in an ATS framework.
> This was all static code analysis.  Integration looked like a non-starter,
> so no performance test done.
>
> Regarding performance testing of "ATS + Openssl 1.1.0(x) + standard aes-ni
> acceleration", Susan (?Bryan?) was just telling me today of a measured
> order of magnitude improvement over with the same using Openssl 1.0.1(x)
> and small packet sizes...  Improvement attributed to lock contention issues
> in the older OpenSSL 1.0.1(x).
>
>
> Dave
>
>
>
> On Wed, Sep 20, 2017 at 3:22 PM, Jeremy Payne <jp557198@gmail.com> wrote:
>
> Dave,
>
> Did you run any comparison performance tests using the QAT engine ?
> Specifically around these configurations(or similar)
>
> 1. ATS + Openssl 1.1.0(x) + QAT engine(sync)
> 2. ATS + Openssl 1.1.0(x) + standard aes-ni acceleration
>
>
>
>
> On Wed, Sep 20, 2017 at 11:26 AM, Dave Thompson <davet@oath.com> wrote:
> > July 2016, I was evaluating the async Quick Assist in the context of ATS,
> > and came away with the opinion it's value comes into play with a much
> > simpler application.   It's effectively it's own async engine, long
> jumping
> > across the stack, and doesn't play well or add  value to ATS's more
> > extensive model to do similar.... not to mention mutually exclusive in
> their
> > current forms.
> >
> > Dave
> >
> >
> >
> > On Wed, Sep 20, 2017 at 10:08 AM, Alan Carroll <solidwallofcode@oath.com
> >
> > wrote:
> >>
> >> Susan and Dave Thompson were working on something related to that,
> "crypto
> >> proxy". There's a small mention of it by Susan at the Fall 2016 summit
> in
> >> the TLS state slides
> >> (https://cwiki.apache.org/confluence/display/TS/Presentations+-+2016).
> I'd
> >> start there and see if you can bug Susan or Good Dave*. Although that
> work
> >> was designed to use an off box crypto engine, the implementation from
> the
> >> ATS point of view is identical to what you're writing about. Susan will
> be
> >> at the Fall 2017 Summit, I'd look her up then as well.
> >>
> >> * To distinguish from "Evil Dave" Carlin.
> >>
> >> On Wed, Sep 20, 2017 at 9:44 AM, Jeremy Payne <jp557198@gmail.com>
> wrote:
> >>>
> >>> Thanks guys.. Thats all I needed to know.. Now I can look closer at my
> >>> end. Will let you know what I find.
> >>>
> >>> Also, any plans on supporting openssl async, which then allows for
> >>> taking full advantage of the Intel QAT engine?
> >>> Understood patches/commits are welcome, but just figured there may be
> >>> some behind the scene works already started.
> >>>
> >>> Thanks!
> >>>
> >>> On Tue, Sep 19, 2017 at 6:31 PM, Alan Carroll <
> solidwallofcode@oath.com>
> >>> wrote:
> >>> > Susan has also run some performance tests with 7.1.x and openSSL 1.1
> >>> > vs.
> >>> > openSSL 1.0.2.
> >>> >
> >>> > On Tue, Sep 19, 2017 at 5:55 PM, Leif Hedstrom <zwoop@apache.org>
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >> On Sep 19, 2017, at 2:20 PM, Jeremy Payne <jp557198@gmail.com>
> wrote:
> >>> >>
> >>> >> I can link ATS 7.x and 8.x against openssl 1.1.0f, however, for
some
> >>> >> reason I can't establish a SSL/TLS connection.  Has anyone
> >>> >> successfully linked ATS against openssl 1.1.0f  and successfully
> been
> >>> >> able to establish a SSL/TLS session?
> >>> >> In other words, is openssl 1.1.0f supported by ATS? If not, what
> about
> >>> >> an earlier version of 1.1.0(x)??
> >>> >>
> >>> >>
> >>> >>
> >>> >> Yeh, we’re running current master with OpenSSL v1.1.0f on
> >>> >> docs.trafficserver.apache.org. Maybe you have some mismatch /
> issues
> >>> >> between
> >>> >> headers (when compiling ATS) and runtime?
> >>> >>
> >>> >> Cheers,
> >>> >>
> >>> >> — Leif
> >>> >>
> >>> >
> >>
> >>
> >
>
>
>

Mime
View raw message