From owner-freebsd-arch@freebsd.org Tue Jan 16 09:50:00 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EE81EB87E0 for ; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8459F70BA3 for ; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: by mailman.ysv.freebsd.org (Postfix) id 83B9BEB87DF; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 836AEEB87DE for ; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (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 4CF5E70BA1; Tue, 16 Jan 2018 09:49:59 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 6FD0E3760358; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 61A60376096D; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OYNX_nCy1DfY; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4F5D43760358; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Date: Tue, 16 Jan 2018 10:50:47 +0100 (CET) From: Emeric POUPON To: John Baldwin Cc: arch@freebsd.org Message-ID: <973472132.3159693.1516096247163.JavaMail.zimbra@stormshield.eu> In-Reply-To: <3790717.UIxaijsHl3@ralph.baldwin.cx> References: <3790717.UIxaijsHl3@ralph.baldwin.cx> Subject: Re: Ranting about OCF / crypto(9) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Topic: Ranting about OCF / crypto(9) Thread-Index: 86xZP1caLjQ7WbpOKF6kTUpF0Q3CTA== X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 09:50:00 -0000 Hello, > - We need to not treat accelerated software (e.g. AES-NI) as a > hardware interface. Right now OCF's model of priorities when > trying to choose a backend driver for a session only has two > "levels" software vs hardware and aesni(4) (and the ARMv8 variant) > are lumped into the hardware bucket so that they have precedence > over the "dumb" software implementation. However, the accelerated > software algorithms do need some of the same support features of > the "dumb" software implementation (such as being scheduled on a > thread pool to use CPU cycles) that are not needed by other "hardware" > engines. OCF needs to understand this distinction. > > - Somewhat related, we should try to use accelerated software when > possible (e.g. AES-CBC with SHA) doesn't use AES-NI unless the > CPU supports accelerated SHA. Ideally for this case we'd still > use AES-NI for the AES portion along with the software SHA > implementation (and we'd do it one pass over the data rather than > two when possible). Indeed it would make sense to extend the software driver to make use of available software acceleration. From IPSec, this would allow to accelerate the encryption part without accelerating the authentication part, and it is still a very common use case. Actually, we have some patches to do that, maybe it would make sense to try to distribute them? This would require quite a significant amount of work though. > This is all I could think of today. What do other folks think? Well, the batch mode and its queue is questionable. Indeed, when using several hardware drivers, having a single process trying to dispatch the crypto jobs to the drivers and calculating the CRYPTO_HINT_MORE flag sounds inefficient. Maybe we would need a dedicated queue/thread per driver if we really want the batch mode to be effective? Furthermore, hardware drivers often already manage internal queues for jobs. I guess the only benefit of the batch mode would be to allow a lot of crypto requests to be queued in the framework and prevent the consumers to deal with the crypto requests they don't manage to enqueue?