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 9A6B5C5DF7D for ; Tue, 18 Aug 2026 20:38:05 +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=PmKXz9XXHft8mLx4770xwdhUqEmqrgiTeAs73d69mpY=; b=LX6AvxiehzcfvE v3nL/h54hTkJvRvLUvJl3P9cUlYqUsAVKCUWsr7ba2GkuouyyxFqjfd5Eqtesxn78m5AksJrIGB52 N/jKw2hoO7nd2Aue7bTZrd9kH0bM+bO9fLqp94mbYvNCcGGZtoD5Lqf05m8OIQhk4SMvVzKk9tFHJ hhlsdSHR5TG488IshYFWEReoiu5dxN6vIJe3dYwmd2HHja2/sV4KSrDME5AaupiXYOnU9bQpeSgLB ahbXBKnRWcNe9mnoKyUbQypGKUA7nEUg1cHoSz0Is3QTSPxZNqL5sSOadZSwZMC+uaK3BirD0sneL TbsAZhqyx8ESiwV1k6Bw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wwQZL-00000008dnJ-1vEa; Tue, 18 Aug 2026 20:37:59 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wwQZJ-00000008dme-1ZOA; Tue, 18 Aug 2026 20:37:57 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id CDC91601FB; Tue, 18 Aug 2026 20:37:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1C311F000E9; Tue, 18 Aug 2026 20:37:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787085475; bh=vS+hrw7DR5QjvngIhGCIUMUP90zpgBBzUMr8U2SbJEc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kp3ftP8lgwzzmR4XG4D3ofqWLPKNHPwk31tk6KCBZ4wcRAzJS9CoKTfizilk33tEN rhX+GqTNYJSKYTogq47ReDOXZiQoiE555xBjVR3wW5XSD03NMgmXcUy625f933ceef 2xM+zufoxlvj1A3ZK3MSHgNx8W8AepObJOl424/vHbLr6YI2rpizHCUPf53RNJK3BI etRxeEHEhi81pgkcv8lSzvDM4/v0wD4M6HEHtUsZG38z+OxkoVRwLBQQWPooKQJosT gkV2by9tcrh4zz+wpXh10F3OlKKtBC7HmKfRlTpP4yGjPs8a1uAlVdq9mfI3Xy302C D7zjY38D7YC7g== Date: Tue, 18 Aug 2026 20:37:53 +0000 From: Eric Biggers To: Diederik de Haas Cc: Dawid Olesinski , Herbert Xu , "David S . Miller" , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiko Stuebner , Corentin Labbe , linux-crypto@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader Message-ID: <20260818203753.GA3388792@google.com> References: <20260708175837.1718437-1-dawidro@gmail.com> <20260818185810.GA7030@quark> <20260818200454.GA2718123@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Tue, Aug 18, 2026 at 10:23:18PM +0200, Diederik de Haas wrote: > On Tue Aug 18, 2026 at 10:04 PM CEST, Eric Biggers wrote: > > tcrypt.c reports cycle counts from get_cycles(), which has an > > architecture-dependent meaning. On x86_64 it is something approximating > > the CPU cycles (3-5 GHz) whereas on arm64 it is the ARM Generic Timer > > which tends to be around 24 MHz or so, over 100 times slower than the > > actual CPU. So 9044 vs 115 "cycles" for x86_64 vs arm64 sounds about > > expected, and they suggest the real times are likely similar but > > slightly faster on x86_64 as expected. > > Phew, thanks for the explanation :-) > > > This sort of thing is why benchmarks usually should measure real time. > > The legacy module tcrypt.c unfortunately uses get_cycles() instead. > > What would be a better/non-legacy way to test crypto performance? > Is that documented somewhere? The KUnit tests in lib/crypto/tests/ have benchmarks in them. They can be run like any other KUnit tests, though you do need to set CONFIG_CRYPTO_LIB_BENCHMARK=y to enable the benchmark test cases. I'll add some more information to libcrypto.rst about how to do this, but besides the extra option it's no different from any other KUnit tests. Anyway, that is just for the code that actually matters, not legacy drivers like this one. So you're right to have used tcrypt.c to try to benchmark this legacy driver, as it is one of the ways to do so, just it is a bit pointless since this type of driver is known to be very slow. - Eric _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip