From: "Diederik de Haas" <diederik@cknow-tech.com>
To: "Eric Biggers" <ebiggers@kernel.org>,
"Diederik de Haas" <diederik@cknow-tech.com>
Cc: "Dawid Olesinski" <dawidro@gmail.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Corentin Labbe" <clabbe@baylibre.com>,
<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
Date: Tue, 18 Aug 2026 22:23:18 +0200 [thread overview]
Message-ID: <DKSCMAUXS10I.2AB9KERO16FRG@cknow-tech.com> (raw)
In-Reply-To: <20260818200454.GA2718123@google.com>
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?
Cheers,
Diederik
WARNING: multiple messages have this Message-ID (diff)
From: "Diederik de Haas" <diederik@cknow-tech.com>
To: "Eric Biggers" <ebiggers@kernel.org>,
"Diederik de Haas" <diederik@cknow-tech.com>
Cc: "Dawid Olesinski" <dawidro@gmail.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Corentin Labbe" <clabbe@baylibre.com>,
<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
Date: Tue, 18 Aug 2026 22:23:18 +0200 [thread overview]
Message-ID: <DKSCMAUXS10I.2AB9KERO16FRG@cknow-tech.com> (raw)
In-Reply-To: <20260818200454.GA2718123@google.com>
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?
Cheers,
Diederik
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-08-18 20:23 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 17:58 [PATCH v2 0/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader Dawid Olesinski
2026-07-08 17:58 ` Dawid Olesinski
2026-07-08 17:58 ` [PATCH v2 1/4] dt-bindings: crypto: rockchip: Add RK356x/RK3588 crypto engine binding Dawid Olesinski
2026-07-08 17:58 ` Dawid Olesinski
2026-07-08 18:13 ` sashiko-bot
2026-07-08 23:53 ` Sebastian Reichel
2026-07-08 23:53 ` Sebastian Reichel
2026-07-08 17:58 ` [PATCH v2 2/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader driver Dawid Olesinski
2026-07-08 17:58 ` Dawid Olesinski
2026-07-08 18:13 ` sashiko-bot
2026-07-08 17:58 ` [PATCH v2 3/4] arm64: dts: rockchip: Add crypto node to rk356x-base Dawid Olesinski
2026-07-08 17:58 ` Dawid Olesinski
2026-07-08 23:56 ` Sebastian Reichel
2026-07-08 23:56 ` Sebastian Reichel
2026-07-09 7:07 ` Heiko Stübner
2026-07-09 7:07 ` Heiko Stübner
2026-07-10 14:30 ` Dawid Olesinski
2026-07-10 14:30 ` Dawid Olesinski
2026-07-25 14:13 ` Diederik de Haas
2026-07-25 14:13 ` Diederik de Haas
2026-07-08 17:58 ` [PATCH v2 4/4] arm64: dts: rockchip: Add crypto node to rk3588-base Dawid Olesinski
2026-07-08 17:58 ` Dawid Olesinski
2026-08-03 10:42 ` [PATCH v2 0/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader Diederik de Haas
2026-08-03 10:42 ` Diederik de Haas
2026-08-18 18:58 ` Eric Biggers
2026-08-18 18:58 ` Eric Biggers
2026-08-18 19:31 ` Diederik de Haas
2026-08-18 19:31 ` Diederik de Haas
2026-08-18 20:04 ` Eric Biggers
2026-08-18 20:04 ` Eric Biggers
2026-08-18 20:23 ` Diederik de Haas [this message]
2026-08-18 20:23 ` Diederik de Haas
2026-08-18 20:37 ` Eric Biggers
2026-08-18 20:37 ` Eric Biggers
2026-08-16 19:39 ` [PATCH v3 " Dawid Olesinski
2026-08-16 19:39 ` Dawid Olesinski
2026-08-16 19:39 ` [PATCH v3 1/4] dt-bindings: crypto: rockchip: Add RK356x/RK3588 crypto engine binding Dawid Olesinski
2026-08-16 19:39 ` Dawid Olesinski
2026-08-16 19:49 ` sashiko-bot
2026-08-17 8:14 ` Diederik de Haas
2026-08-17 8:14 ` Diederik de Haas
2026-08-18 7:42 ` Krzysztof Kozlowski
2026-08-18 7:42 ` Krzysztof Kozlowski
2026-08-16 19:39 ` [PATCH v3 2/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader driver Dawid Olesinski
2026-08-16 19:39 ` Dawid Olesinski
2026-08-16 19:56 ` sashiko-bot
2026-08-18 7:36 ` Krzysztof Kozlowski
2026-08-18 7:36 ` Krzysztof Kozlowski
2026-08-18 17:43 ` Eric Biggers
2026-08-18 17:43 ` Eric Biggers
2026-08-16 19:39 ` [PATCH v3 3/4] arm64: dts: rockchip: Add crypto node to rk356x-base Dawid Olesinski
2026-08-16 19:39 ` Dawid Olesinski
2026-08-16 19:48 ` sashiko-bot
2026-08-16 19:39 ` [PATCH v3 4/4] arm64: dts: rockchip: Add crypto node to rk3588-base Dawid Olesinski
2026-08-16 19:39 ` Dawid Olesinski
2026-08-16 19:51 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DKSCMAUXS10I.2AB9KERO16FRG@cknow-tech.com \
--to=diederik@cknow-tech.com \
--cc=clabbe@baylibre.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=dawidro@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=ebiggers@kernel.org \
--cc=heiko@sntech.de \
--cc=herbert@gondor.apana.org.au \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.