Date: Tue, 27 Oct 2020 04:32:40 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Mark Johnston <markj@freebsd.org>, Neel Chauhan <neel@neelc.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "jhb@FreeBSD.org" <jhb@FreeBSD.org> Subject: Re: QAT driver Message-ID: <YTBPR01MB39666C8CB2DA8292EA4E4033DD160@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> 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
Mark Johnston wrote:=0A= >On Mon, Oct 26, 2020 at 08:00:08PM -0700, Neel Chauhan wrote:=0A= >> Hi,=0A= >>=0A= >> This is great news for me with my home HPE ML110 G10/Xeon 4108 server.= =0A= >>=0A= >> However, I will not be able to test this patch unless it can get=0A= >> backported to 12.1 or 12.2 once it's out, and I don't expect backporting= =0A= >> to happen.=0A= >=0A= >Indeed, it wouldn't appear before 12.3.=0A= >=0A= >> I have one question about this: will I be able to use this to accelerate= =0A= >> OpenSSL? Is additional code needed?=0A= >=0A= >In principle OpenSSL can make use of cryptodev(4) using the cryptodev=0A= >engine, which would allow requests to be handled by qat(4) (or any other= =0A= >hardware crypto driver loaded in the kernel). I don't know that the=0A= >cryptodev engine is really maintained these days though. More=0A= >importantly, using the kernel to perform crypto transforms carries a lot= =0A= >of overhead since OpenSSL would have to switch into the kernel and copy=0A= >data between userspace and the kernel for each request. I'd be=0A= >surprised if you get any benefit from this versus using the AES-NI=0A= >extensions in userspace, which OpenSSL should do out of the box.=0A= Can it be made to work with the KERN_TLS in head?=0A= (KERN_TLS works fine for me using the ktls_ocf and aesni modules.)=0A= I think it is only head and requires the patched OpenSSL3 that jhb@=0A= currently has.=0A= I know nothing about it, except that it seems to work well, doing=0A= the TLS application data records in the kernel for a TCP socket=0A= enabled by the patched OpenSSL library.=0A= I've cc'd jhb@, so hopefully he can let us know what it needs?=0A= =0A= >There are QAT drivers designed to service userspace requests=0A= >efficiently, such as the one published by Intel and the one included=0A= >with DPDK. This one is a fair bit simpler and really mostly intended=0A= >for kernel consumers, mainly IPSec and disk encryption subsystems.=0A= >=0A= >> I use the mentioned HPE server for Tor and Tor is very crypto-heavy (yet= =0A= >> singlethreaded).=0A= >>=0A= >> I believe the official Intel drivers allow OpenSSL acceleration, but I'd= =0A= >> prefer to avoid out-of-band drivers whether possible (ports/src is=0A= >> fine).=0A= >=0A= >It'd still be worth testing if you think a significant gain may be had.=0A= =0A= rick=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB39666C8CB2DA8292EA4E4033DD160>