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 32B71456A5; Wed, 24 Jul 2024 22:02:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 244A942E7A; Wed, 24 Jul 2024 22:02:28 +0200 (CEST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by mails.dpdk.org (Postfix) with ESMTP id 5527C402D0 for ; Wed, 24 Jul 2024 22:02:26 +0200 (CEST) Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1fd9e6189d5so1402265ad.3 for ; Wed, 24 Jul 2024 13:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1721851345; x=1722456145; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=oVf6Ti0B0Dh+0rDvEeeKFnXDNr1ON00xLefLMLqVWiI=; b=OnrpiEmol8kidrxeh0UJg84XqwJAdNe9TwNqpZ3LuQHHAkeHGYQQh+p0QvWDPdwebU JlO9waIILaSqVV9Z9djaB/RNiy43erAj120NmSVloTysSXFGdzcPOE7r70PggrpIUWM6 hRZKtHh/DE6jui1kLn+q88REfgz3aoUvL0eA9u8o1gEttkwZbwHnVOJsKT0Ym8YqCpu/ +43ApE/IodUcwpkCEOI20NMdeSw35ZMavXXri6cJiGZUG2D2DzGc/wx3sR2VEahANF5z rFri0ziuB1H1CTaDBRK+8M4S3NkEEzEB0B8uPRendB39PTI9vScz8lwDz847mtmHd7dz SWXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721851345; x=1722456145; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oVf6Ti0B0Dh+0rDvEeeKFnXDNr1ON00xLefLMLqVWiI=; b=vGc7Qa8GJHDQ6Znec+KLcgS5/j19xGu+SsTZexrgv6YVv5AaVDgroYh9gBtDfxuNuh FUGHw513XFIrqN7YhJG0L8wFaO5eKhXU6iMh7zh2eXGsVYMeoKzZvw1nNa4ulDgbTm80 zt6WpK+9Vg2QDTgXrmoHoVkh2ph0JpxGpplFVfFO7QxW/onJHf+2kv8OcIzOLI08/HEj jhaEKvpvri6auJMoMMcqNUg/cWguZwNoIpDeNR6dXsV3Hoyus28npz+lQJrZV1xv/RxG ZkUhGcYU/yg0pARm0yMlr1QwZBAMU71oSATME0Q6XO6FDejw0aJHVCcOfcFzCh7m5EyF d3CQ== X-Forwarded-Encrypted: i=1; AJvYcCUYi7W6rHSVaSOeas99fgp3FG3Y7KRP7Y0SBGjGhqmlinbvZU4Wj663VtMhY7CpseO4Ns0l0IFKNkTxYk8= X-Gm-Message-State: AOJu0YxP0Scc/pEIJz78ZwQnAgXSm+lc83iKUfOcRl2zEHnA2oFNOhE5 FirtNDN4LGev3TL2J6LC9TomG6SesUJNCR6oX6fXJadUnqgHIGO1aF8A1ann6P8= X-Google-Smtp-Source: AGHT+IFUycZmFFlMbRdNTOIYIHl+vA6CLyfcDkDxRjc4DQ1Cps9ZUQHUnfKX+v9SdFPizjbIuqpWTQ== X-Received: by 2002:a17:903:24c:b0:1fd:8f66:b078 with SMTP id d9443c01a7336-1fed3ad7b09mr8542265ad.46.1721851345105; Wed, 24 Jul 2024 13:02:25 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fd6f44e767sm98011985ad.213.2024.07.24.13.02.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jul 2024 13:02:24 -0700 (PDT) Date: Wed, 24 Jul 2024 13:02:21 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Shunzhi Wen , Thomas Monjalon , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , 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 Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature Message-ID: <20240724130221.7c0fc39e@hermes.local> In-Reply-To: <02097e5b-1c04-4e02-a3d7-e8d0df1e3308@lysator.liu.se> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Wed, 24 Jul 2024 21:14:30 +0200 Mattias R=C3=B6nnblom 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, b= ut > >> system calls tend to have some pretty bad tail latencies. > >> > >> To improve efficiency, one could do a getentropy() on a relatively lar= ge > >> buffer, and cache the result on a per-lcore basis, amortizing the syst= em > >> 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. =20 > >=20 > >=20 > > Getrandom is a vsyscall on current kernels, and it manages use of entro= py across > > multiple sources. If you are doing lots of key generation, you don't wa= nt to > > hit the hardware every time. > >=20 > > https://lwn.net/Articles/974468/ > >=20 > > =20 >=20 > If I understand things correctly, the getrandom() vDSO support was=20 > mainlined *today*, so you need to be current indeed to have a vDSO=20 > getrandom(). :) Yes, it is headed for 6.11, but doubt that any reasonable workload is going to be constrained by crypto key generation. >=20 > The above benchmark (rand_perf_autotest with rte_rand() implemented with= =20 > getentropy()) was run on Linux 5.15 and glibc 2.35, so a regular system=20 > call was used. >=20 > (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.