trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Thompson <da...@oath.com>
Subject Re: Openssl 1.1.0f Support
Date Thu, 21 Sep 2017 15:02:42 GMT
I think Alan was thinking of an effort we called CryptoProxy.   Right, QAT
was static code analysis considered but ultimately put aside.
Cryptoproxy focus was on keeping the private keys off the ATS box.  It was
done for security, not for CPU savings as we're not typically CPU bound,
despite ~80% of traffic over TLS.   CryptoProxy project sent RSA
encrypt/decrypt requests from handshake to a separate box.   FWIW, I recall
our old out dated test Xeon X5650 boxes taking like 3msec RSA decrypt or 4
msec RSA encrypt (key exchange dependent), and that of course is only for
non-resumption/new TLS connections.

Dave

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

> Ok,
>
>
>
> Looking at the presentation it seems that the openssl async jobs approach
> was not tested, but planned. Dave mentioned static code analysis and no
> performance tests.
>
>
>
> Within openssl+QAT you get the performance from running the openssl calls
> in an async job which becomes a sort of coroutine, which is then run in
> openssl’s threadpool. When offloading, it yields control to the scheduler,
> freeing the CPU for other jobs. Ofcourse it is a bit harder than this :)
>
> Building the jobs could be easy, the whole song and dance around
> synchronization, thread alignment, could be too cumbersome to bother with.
>
>
>
> Next to that it seems that the async jobs are a bit slower when only using
> the CPU, so you would end up with two separate flows to ensure the same
> performance for 99.99% of the users.
>
>
>
> Anybody willing to donate an Intel QAT PCI card :) Our address is ….
>
>
>
> Note: It seems that the intel QAT cards have an unexpected scaling problem
> with ECDHE-RSA, which they (intel) were looking into, and with the >32
> thread CPUs you will get a break even situation. So for HTTP/2 the benefit
> would be much smaller than normal RSA if the machine has enough cores.
> Ofcourse the Intel QAT card should still offload the CPU.
>
>
>
> Kees
>
>
>
>
>
>
>
>
>
> *From:* Alan Carroll [mailto:solidwallofcode@oath.com]
> *Sent:* Thursday, September 21, 2017 15:13
>
> *To:* users@trafficserver.apache.org
> *Subject:* Re: Openssl 1.1.0f Support
>
>
>
> 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