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] <mailto:[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] <mailto:[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] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>> > <mailto:[email protected]> > >>> > wrote: >>> >> >>> >> >>> >> On Sep 19, 2017, at 2:20 PM, Jeremy Payne <[email protected] >>> >> <mailto:[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 <http://docs.trafficserver.apache.org> . >>> >> Maybe you have some mismatch / issues >>> >> between >>> >> headers (when compiling ATS) and runtime? >>> >> >>> >> Cheers, >>> >> >>> >> — Leif >>> >> >>> > >> >> >
