QAT driver

[Rick Macklem]

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 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?

>There are QAT drivers designed to service userspace requests
>efficiently, such as the one published by Intel and the one included
>with DPDK.  This one is a fair bit simpler and really mostly intended
>for kernel consumers, mainly IPSec and disk encryption subsystems.
>
>> I use the mentioned HPE server for Tor and Tor is very crypto-heavy (yet
>> singlethreaded).
>>
>> I believe the official Intel drivers allow OpenSSL acceleration, but I'd
>> prefer to avoid out-of-band drivers whether possible (ports/src is
>> fine).
>
>It'd still be worth testing if you think a significant gain may be had.

rick
_______________________________________________
freebsd-hackers at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"