QAT driver

[Mark Johnston]

On Tue, Oct 27, 2020 at 04:32:40AM +0000, Rick Macklem wrote:
> Mark Johnston wrote:
> >On Mon, Oct 26, 2020 at 08:00:08PM -0700, Neel Chauhan wrote:
> >> Hi,
> >>
> >> This is great news for me with my home HPE ML110 G10/Xeon 4108 server.
> >>
> >> However, I will not be able to test this patch unless it can get
> >> backported to 12.1 or 12.2 once it's out, and I don't expect backporting
> >> to happen.
> >
> >Indeed, it wouldn't appear before 12.3.
> >
> >> I have one question about this: will I be able to use this to accelerate
> >> OpenSSL? Is additional code needed?
> >
> >In principle OpenSSL can make use of cryptodev(4) using the cryptodev
> >engine, which would allow requests to be handled by qat(4) (or any other
> >hardware crypto driver loaded in the kernel).  I don't know that the
> >cryptodev engine is really maintained these days though.  More
> >importantly, using the kernel to perform crypto transforms carries a lot
> >of overhead since OpenSSL would have to switch into the kernel and copy
> >data between userspace and the kernel for each request.  I'd be
> >surprised if you get any benefit from this versus using the AES-NI
> >extensions in userspace, which OpenSSL should do out of the box.
> Can it be made to work with the KERN_TLS in head?
> (KERN_TLS works fine for me using the ktls_ocf and aesni modules.)
> I think it is only head and requires the patched OpenSSL3 that jhb@
> currently has.

I hadn't looked at ktls_ocf.c before but at a glance it looks like it
can make use of any hardware or software opencrypto driver that supports
the requested algorithms.  The qat(4) port implements the algorithms
referenced by ktls_ocf_try().

> I know nothing about it, except that it seems to work well, doing
> the TLS application data records in the kernel for a TCP socket
> enabled by the patched OpenSSL library.
> I've cc'd jhb@, so hopefully he can let us know what it needs?