From owner-freebsd-hackers@freebsd.org Tue Oct 27 04:57:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2D90443D9B1 for ; Tue, 27 Oct 2020 04:57:49 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKzwX0JMFz4JTk; Tue, 27 Oct 2020 04:57:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09R4vZEU012404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 00:57:40 -0400 Date: Mon, 26 Oct 2020 21:57:35 -0700 From: Benjamin Kaduk To: Mark Johnston Cc: Neel Chauhan , freebsd-hackers@freebsd.org Subject: Re: QAT driver Message-ID: <20201027045735.GJ39170@kduck.mit.edu> References: <20201026200059.GA66299@raichu> <723fbd7326df42ce30cd5e361db9c736@neelc.org> <20201027032720.GB31663@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201027032720.GB31663@raichu> X-Rspamd-Queue-Id: 4CKzwX0JMFz4JTk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; NEURAL_HAM_LONG(-1.00)[-0.998]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.48)[-0.483]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 04:57:49 -0000 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"