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 99E0A456AB; Thu, 25 Jul 2024 06:48:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8415142EA3; Thu, 25 Jul 2024 06:48:54 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 718BF427C2 for ; Thu, 25 Jul 2024 06:48:53 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C136D14707 for ; Thu, 25 Jul 2024 06:48:52 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id A643C146A8; Thu, 25 Jul 2024 06:48:52 +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 DDDC414644; Thu, 25 Jul 2024 06:48:47 +0200 (CEST) Message-ID: <44ab5731-6fc6-4283-835a-4f46f9e425a3@lysator.liu.se> Date: Thu, 25 Jul 2024 06:48:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature To: Stephen Hemminger Cc: Shunzhi Wen , Thomas Monjalon , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Ruifeng Wang , Bruce Richardson , Tyler Retzlaff , Min Zhou , David Christensen , Stanislaw Kardach , Konstantin Ananyev , dev@dpdk.org, nd@arm.com, Wathsala Vithanage , Jack Bond-Preston , Dhruv Tripathi References: <20240723212703.721050-1-shunzhi.wen@arm.com> <536d1325-ee15-4630-9ae9-00cef9411d34@lysator.liu.se> <20240724073501.70d86435@hermes.local> <18c67157-8753-4a95-9ab5-f4f1d4a32010@lysator.liu.se> <20240724091620.11ce8c38@hermes.local> <02097e5b-1c04-4e02-a3d7-e8d0df1e3308@lysator.liu.se> <20240724130221.7c0fc39e@hermes.local> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20240724130221.7c0fc39e@hermes.local> 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-24 22:02, Stephen Hemminger wrote: > On Wed, 24 Jul 2024 21:14:30 +0200 > Mattias Rönnblom wrote: > >>>> Ideally, you want to avoid system calls on lcore workers doing packet >>>> processing. If you have to do system calls (which I believe is the case >>>> here), it's better to a simple call, not so often. >>>> >>>> getentropy() seems to need about 800 core clock cycles on my x86_64, on >>>> average. (rte_rand() needs ~11 cc/call.) 800 cc is not too horrible, but >>>> system calls tend to have some pretty bad tail latencies. >>>> >>>> To improve efficiency, one could do a getentropy() on a relatively large >>>> buffer, and cache the result on a per-lcore basis, amortizing the system >>>> call overhead over many calls. >>>> >>>> You still have the tail latency issue to deal with. We could have a >>>> control thread providing entropy for the lcores, but that seems like >>>> massive overkill. >>> >>> >>> Getrandom is a vsyscall on current kernels, and it manages use of entropy across >>> multiple sources. If you are doing lots of key generation, you don't want to >>> hit the hardware every time. >>> >>> https://lwn.net/Articles/974468/ >>> >>> >> >> If I understand things correctly, the getrandom() vDSO support was >> mainlined *today*, so you need to be current indeed to have a vDSO >> getrandom(). :) > > Yes, it is headed for 6.11, but doubt that any reasonable workload > is going to be constrained by crypto key generation. > For certain *very* latency-sensitive applications the main concern with a non-vDSO system call would be jitter, and not necessarily average latency (i.e., a throughput degradation). >> >> The above benchmark (rand_perf_autotest with rte_rand() implemented with >> getentropy()) was run on Linux 5.15 and glibc 2.35, so a regular system >> call was used. >> >> (getentropy() delegates to getrandom(), so the performance is the same.) > > I would trust the upstream kernel support for secure random more than > anything DPDK could develop. As soon as we get deeper into crypto it > opens up a whole new security domain and attack surface. > I much agree here. What potentially would be useful is an EAL-level OS wrapper. So getrandom() for UNIX-like OSes, and something else for Windows. In addition, you could make larger getrandom() calls to shave off some cycles on the average (at least for the non-vDSO case). It seems to me we should defer the introduction of anything like that until a) it's needed by a DPDK library, or b) someone on the application side is asking for it.