Date: Mon, 26 Oct 2020 21:57:35 -0700 From: Benjamin Kaduk <kaduk@mit.edu> To: Mark Johnston <markj@freebsd.org> Cc: Neel Chauhan <neel@neelc.org>, freebsd-hackers@freebsd.org Subject: Re: QAT driver Message-ID: <20201027045735.GJ39170@kduck.mit.edu> In-Reply-To: <20201027032720.GB31663@raichu> References: <20201026200059.GA66299@raichu> <723fbd7326df42ce30cd5e361db9c736@neelc.org> <20201027032720.GB31663@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 26, 2020 at 11:27:20PM -0400, 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 The openssl cryptodev engine was rewritten in https://github.com/openssl/openssl/pull/3744 , but engines are going to be deprecated in openssl 3.0. In theory someone (Intel?) could write an openssl "provider" that utilizes the QAT hardware, but (unsurprisingly, given that the interface isn't even finalized yet!) no one has done that yet. > 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. Yes, the overhead of switching to kernel mode and copyin/copyout is expected to take up fair bit of the nominal gains. -Ben > 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201027045735.GJ39170>