From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8818E456C1; Sat, 27 Jul 2024 00:33:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14D0D40696; Sat, 27 Jul 2024 00:33:14 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id A88E440274 for ; Sat, 27 Jul 2024 00:33:12 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id EBA081C53F for ; Sat, 27 Jul 2024 00:33:11 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DF46F1C53E; Sat, 27 Jul 2024 00:33:11 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.3 Received: from [192.168.1.86] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id CD2241C45E; Sat, 27 Jul 2024 00:33:08 +0200 (CEST) Message-ID: <2d28f42f-480b-4070-8ba2-1353a742b46d@lysator.liu.se> Date: Sat, 27 Jul 2024 00:33:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature To: Shunzhi Wen , "thomas@monjalon.net" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Ruifeng Wang , Bruce Richardson , Tyler Retzlaff , Min Zhou , David Christensen , Stanislaw Kardach , Konstantin Ananyev Cc: "dev@dpdk.org" , nd , Wathsala Wathawana Vithanage , Jack Bond-Preston , Dhruv Tripathi References: <20240723212703.721050-1-shunzhi.wen@arm.com> <536d1325-ee15-4630-9ae9-00cef9411d34@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2024-07-26 20:34, Shunzhi Wen wrote: >> I'm missing a rationale here. Why is this useful? >> > This creates an API for HW that supports cryptographically secure random number generation. > >> If you want to extend with a cryptographically secure >> random number generator, that's fine. >> >> To have an API that's only available on certain ARM CPUs is not. >> >> NAK >> > The primary goal of this patch is to provide a direct interface to HW, > instead of letting kernel handle it. This is not an API just for Arm > CPUs, as other vendors also have similar HW features. For instance, > Intel and AMD has support for x86 RDRAND and RDSEED instructions, thus > can easily implement this API. > No DPDK library (or PMD) currently needs this functionality, and no application, to my knowledge, has asked for this. If an app or a DPDK library would require cryptographically secure random numbers, it would most likely require it on all CPU/OS platforms (and with all DPDK -march flags). RDRAND is only available on certain x86_64 CPUs, and is incredibly slow - slower than getting entropy via the kernel, even with non-vDSO syscalls. Agner Fog lists the RDRAND latency as ~3700 cc for Zen 2. Later generations of both AMD and Intel CPUs have much shorter latencies, but a reciprocal throughput so low that one have to wait thousands of clock cycles before issuing another RDRAND, or risk stalling the core. My Raptor Lake seems to require ~1000 cc retire RDRAND, which is ~11x slower than getting entropy (in bulk) via getentropy(). What is the latency for the ARM equivalent? Does it also have a reciprocal throughput issue? >> A new function should be called something with "secure", rather than "true" >> (which is a bit silly, since we might well live in a completely deterministic >> universe). "secure" would more clearly communicate the intent, and also >> doesn't imply any particular implementation. >> > Regarding the terminology, “cryptographically secure random number” > is a more accurate and meaningful term than “true random number.” > This change will be made in the description, and the function name will > be replaced with rte_csrand. > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.