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 <[email protected]> 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:[email protected]] > *Sent:* Wednesday, September 20, 2017 23:17 > *To:* [email protected] > *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 <[email protected]> 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 <[email protected]> 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 <[email protected] > > > > 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 <[email protected]> > 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 < > [email protected]> > >>> 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 <[email protected]> > >>> > wrote: > >>> >> > >>> >> > >>> >> On Sep 19, 2017, at 2:20 PM, Jeremy Payne <[email protected]> > 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 > >>> >> > >>> > > >> > >> > > > > >
