From mboxrd@z Thu Jan 1 00:00:00 1970 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)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2D5526059D for ; Wed, 25 Jun 2025 12:45:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750855508; cv=none; b=G8AVdX2sCUVxrwY+E2eSDzeF7TzcPmD+UuxVsxj7P4N0k5FC3eF9U/r6dUul3AlUd7kVu8yq08xDuMUDArbUqOEf3XgudFrHMMEm4FjGer6AONxJwZS8Vf4ObMQ1n+p/n41vfSe3Q89ZhO+QjUSDb5J5sochnVcE0XEMkMmeUH0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750855508; c=relaxed/simple; bh=U6MI2PdJBFWRH5pUrWIaLIFI8PrLyw/SMKOxte+tblQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SgozrX5266O+5AqY50MYsE9z10Du1OAXDcxIqnTOask/DFe0ickSxK034TBkwLV1Wo6WtqKlFt1/EtMyG01VJqEGJ29+8Cd0S6pWO4jxGyRBbifYO1Kk+WwUVbk3ooY+LH188ZtyBLDw3GuFXptdpOcAu5h1NYf+d9MRnzzz+j8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Received: from trampoline.thunk.org (pool-173-48-82-219.bstnma.fios.verizon.net [173.48.82.219]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 55PCijuO005260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jun 2025 08:44:46 -0400 Received: by trampoline.thunk.org (Postfix, from userid 15806) id 067412E00D5; Wed, 25 Jun 2025 08:44:45 -0400 (EDT) Date: Wed, 25 Jun 2025 08:44:45 -0400 From: "Theodore Ts'o" To: Eric Biggers Cc: Simon Richter , linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, ceph-devel@vger.kernel.org Subject: Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers Message-ID: <20250625124445.GC28249@mit.edu> References: <20250611205859.80819-1-ebiggers@kernel.org> <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> <20250612005914.GA546455@google.com> <20250612062521.GA1838@sol> <20250625063252.GD8962@sol> Precedence: bulk X-Mailing-List: ceph-devel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250625063252.GD8962@sol> On Tue, Jun 24, 2025 at 11:32:52PM -0700, Eric Biggers wrote: > > That was the synchronous throughput. However, submitting multiple requests > asynchronously (which again, fscrypt doesn't actually do) barely helps. > Apparently the STM32 crypto engine has only one hardware queue. > > I already strongly suspected that these non-inline crypto engines > aren't worth using. But I didn't realize they are quite this bad. > Even with AES on a Cortex-A7 CPU that lacks AES instructions, the > CPU is much faster! I wonder if the primary design goal of the STM32 crypto engine is that it might reduce power consumption --- after all, one of the primary benchmarketing metrics that vendors care about is "hours of You Tube watch time" --- and decryptoing a video stream doesn't require high performance. Given that the typical benchmarketing number which handset vendors tend to care about is SQLite transactions per second, maybe they wouldn't be all that eager to use the crypto engine. :-) - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 99CEBC7115C for ; Wed, 25 Jun 2025 13:00:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Subject:In-Reply-To:MIME-Version:References:Message-ID:To:From:Date:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WiPho/YrNmxhKRZMswh56X3ZCDoPJEI53FXqdUvfZEc=; b=kKfZmKDYzYhBkKVTtxTKyKRYU5 wHL3a+uQKv1woC/fSNqYfGXVLc4bUgwPf5vXUSrgfRjFZROMJF4SmrVsdaeY57EojHr1IbHrhQnJ2 h0l3fk5hRg8wkjRlPkDlBf0zdjIt+66itQkALVxDahyMeTK0gJ/pKIc/BK7kt86oV6zQ=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1uUPjc-0006H8-DP; Wed, 25 Jun 2025 13:00:16 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uUPjb-0006H2-5r for linux-f2fs-devel@lists.sourceforge.net; Wed, 25 Jun 2025 13:00:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YuzEsVWBRugxMDikTUbqgddFbCJ7pRKSZLKOLwLAAAQ=; b=H/yDWNRn6SzJR1pRg7VhXcQUaX 0tUUfMkftqawunBGpGnhwotKSRHiIGQfmPw2FQQrkcyEXEum9B/U7AS0nGG9dydbLxFleC/0AyyoM GBJrbxTNNRkqjT2HPW65u7+3r+VNHg8NLJT98Jcx0EbeN7HAg/Y61Jaz3h3N4M0zXFXA=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YuzEsVWBRugxMDikTUbqgddFbCJ7pRKSZLKOLwLAAAQ=; b=Bd8Mx/5JGLLWWBx/NgfN3MiJMF 1i4bm7rWkpuuo3Tx5mSYqfUc3KoaGEzndBFCigcl0XqM/loojenHnu5vofJmNNATnCVzWO/S1+3Ek lHkcJ38iqhPwHHjY+wek9QSgfA7u6GLT1wErD255+Xs9MJN6Uw+k5IfU99QpajEe4V7I=; Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1uUPja-0007t7-LO for linux-f2fs-devel@lists.sourceforge.net; Wed, 25 Jun 2025 13:00:15 +0000 Received: from trampoline.thunk.org (pool-173-48-82-219.bstnma.fios.verizon.net [173.48.82.219]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 55PCijuO005260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jun 2025 08:44:46 -0400 Received: by trampoline.thunk.org (Postfix, from userid 15806) id 067412E00D5; Wed, 25 Jun 2025 08:44:45 -0400 (EDT) Date: Wed, 25 Jun 2025 08:44:45 -0400 From: "Theodore Ts'o" To: Eric Biggers Message-ID: <20250625124445.GC28249@mit.edu> References: <20250611205859.80819-1-ebiggers@kernel.org> <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> <20250612005914.GA546455@google.com> <20250612062521.GA1838@sol> <20250625063252.GD8962@sol> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250625063252.GD8962@sol> X-Headers-End: 1uUPja-0007t7-LO Subject: Re: [f2fs-dev] [PATCH] fscrypt: don't use hardware offload Crypto API drivers X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org, Simon Richter , ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Tue, Jun 24, 2025 at 11:32:52PM -0700, Eric Biggers wrote: > > That was the synchronous throughput. However, submitting multiple requests > asynchronously (which again, fscrypt doesn't actually do) barely helps. > Apparently the STM32 crypto engine has only one hardware queue. > > I already strongly suspected that these non-inline crypto engines > aren't worth using. But I didn't realize they are quite this bad. > Even with AES on a Cortex-A7 CPU that lacks AES instructions, the > CPU is much faster! I wonder if the primary design goal of the STM32 crypto engine is that it might reduce power consumption --- after all, one of the primary benchmarketing metrics that vendors care about is "hours of You Tube watch time" --- and decryptoing a video stream doesn't require high performance. Given that the typical benchmarketing number which handset vendors tend to care about is SQLite transactions per second, maybe they wouldn't be all that eager to use the crypto engine. :-) - Ted _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 38DA8C83013 for ; Wed, 25 Jun 2025 17:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=B+MqaK0Ii6W0fEqqQOB3RCHPPbNA1EHgpqP0+cuayGU=; b=E5P0M5ZwyXFSw+ 4e46kIa4fLF+T4E45c+0w2vsbky7FB/MGnU6IPyiSyFg3hjzt87w6/R20RQRoyOK4fJnqYgVXYGWz FyY5cILOyrJRSWKy5dAfsKcHwd2XGlG4EifS88L6Q2yDaSi7LPK8mxADbkdrfkEi7lkCKVL1qLttW +9ZogInQpU8V2T23Enz54kcbFSg2x5FOtzR/fBzF05KEaQAG2WHzHC/FyVdYi+51EABMAnp+SZ6aZ E6MHZxYOL7jZqOB26bGqBl6oE2tEHl08veCeF2J919H13SZONhTXXZKBub83KzkTfCDh0okqBjQXY KRX4V6Xrg2mA72GVKCbg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uUU32-00000009T1r-1IZA; Wed, 25 Jun 2025 17:36:36 +0000 Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uUPUl-00000008fGp-34gQ for linux-mtd@lists.infradead.org; Wed, 25 Jun 2025 12:44:57 +0000 Received: from trampoline.thunk.org (pool-173-48-82-219.bstnma.fios.verizon.net [173.48.82.219]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 55PCijuO005260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jun 2025 08:44:46 -0400 Received: by trampoline.thunk.org (Postfix, from userid 15806) id 067412E00D5; Wed, 25 Jun 2025 08:44:45 -0400 (EDT) Date: Wed, 25 Jun 2025 08:44:45 -0400 From: "Theodore Ts'o" To: Eric Biggers Cc: Simon Richter , linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, ceph-devel@vger.kernel.org Subject: Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers Message-ID: <20250625124445.GC28249@mit.edu> References: <20250611205859.80819-1-ebiggers@kernel.org> <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> <20250612005914.GA546455@google.com> <20250612062521.GA1838@sol> <20250625063252.GD8962@sol> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250625063252.GD8962@sol> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250625_054455_964433_53C6AC69 X-CRM114-Status: GOOD ( 10.97 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Tue, Jun 24, 2025 at 11:32:52PM -0700, Eric Biggers wrote: > > That was the synchronous throughput. However, submitting multiple requests > asynchronously (which again, fscrypt doesn't actually do) barely helps. > Apparently the STM32 crypto engine has only one hardware queue. > > I already strongly suspected that these non-inline crypto engines > aren't worth using. But I didn't realize they are quite this bad. > Even with AES on a Cortex-A7 CPU that lacks AES instructions, the > CPU is much faster! I wonder if the primary design goal of the STM32 crypto engine is that it might reduce power consumption --- after all, one of the primary benchmarketing metrics that vendors care about is "hours of You Tube watch time" --- and decryptoing a video stream doesn't require high performance. Given that the typical benchmarketing number which handset vendors tend to care about is SQLite transactions per second, maybe they wouldn't be all that eager to use the crypto engine. :-) - Ted ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/