Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Oct 2020 23:27:20 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        Neel Chauhan <neel@neelc.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: QAT driver
Message-ID:  <20201027032720.GB31663@raichu>
In-Reply-To: <723fbd7326df42ce30cd5e361db9c736@neelc.org>
References:  <20201026200059.GA66299@raichu> <723fbd7326df42ce30cd5e361db9c736@neelc.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201027032720.GB31663>