DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: "Wathsala Wathawana Vithanage" <wathsala.vithanage@arm.com>,
	"Shunzhi Wen" <Shunzhi.Wen@arm.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
	"Ruifeng Wang" <Ruifeng.Wang@arm.com>,
	"Bruce Richardson" <bruce.richardson@intel.com>,
	"Tyler Retzlaff" <roretzla@linux.microsoft.com>,
	"Min Zhou" <zhoumin@loongson.cn>,
	"David Christensen" <drc@linux.ibm.com>,
	"Stanislaw Kardach" <stanislaw.kardach@gmail.com>,
	"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>
Cc: "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>,
	Jack Bond-Preston <Jack.Bond-Preston@arm.com>,
	Dhruv Tripathi <Dhruv.Tripathi@arm.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature
Date: Sat, 27 Jul 2024 19:07:34 +0200	[thread overview]
Message-ID: <5d409e6a-1d61-4d8a-b9ab-8cbcf7838ad0@lysator.liu.se> (raw)
In-Reply-To: <AM0PR08MB507361714E151D504B5C5E849FB52@AM0PR08MB5073.eurprd08.prod.outlook.com>

On 2024-07-27 17:45, Wathsala Wathawana Vithanage wrote:
> Hi Mattias,
> 
>>> 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).
>>
> 
> I'm sorry, I'm not following this. Are you saying
> 
> (a) adding a feature someone hasn't already asked for is impossible?
> 

No, not if you can explain why this feature will be useful. You guys 
made no such attempt.

> (b) it is impossible to add support for a feature that is only available in a few CPUs
> of an architecture family?
> 

Cryptographically secure random numbers are available on all CPUs, via 
the operating system. Arguably, such random numbers are more secure than 
anything that a machine instruction can offer.

If your patch are to have non-zero chance of being accepted, it should 
include a base implementation based on getrandom() (and the Windows 
equivalent), with the proper optimizations (e.g., batching entropy 
requests to the kernel on a per-lcore basis).

You would also need to provide a rationale why ARM CPU HW random numbers 
are better than what the kernel can offer. The only potential reason I 
can think of is performance, so you would need to quantify that in some way.

In addition, reliance on CPU CSRNG would need to be a build-time option, 
and disabled by default.

Plus, what I've mentioned several times, give a rationale why DPDK 
should have this functionality.

>> 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?
>>
> 
> Agree, from the numbers you are showing, it looks like they are all slow and
> unsuitable for the data plane. But aren't there multi-plane DPDK applications
> with control-plane threads that can benefit from a CSRNG, albeit slow?
> 
> 

  parent reply	other threads:[~2024-07-27 17:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 21:27 Shunzhi Wen
2024-07-24  6:40 ` Mattias Rönnblom
2024-07-24 14:35   ` Stephen Hemminger
2024-07-24 15:07     ` Mattias Rönnblom
2024-07-24 16:16       ` Stephen Hemminger
2024-07-24 19:14         ` Mattias Rönnblom
2024-07-24 20:02           ` Stephen Hemminger
2024-07-25  4:48             ` Mattias Rönnblom
2024-07-25 14:56               ` Stephen Hemminger
2024-07-26 18:34   ` Shunzhi Wen
2024-07-26 19:00     ` Stephen Hemminger
2024-07-26 20:12       ` Wathsala Wathawana Vithanage
2024-07-26 22:33     ` Mattias Rönnblom
2024-07-27 15:45       ` Wathsala Wathawana Vithanage
2024-07-27 15:54         ` Stephen Hemminger
2024-07-27 22:27           ` Wathsala Wathawana Vithanage
2024-07-27 23:55             ` Stephen Hemminger
2024-07-28  6:46               ` Mattias Rönnblom
2024-07-29  4:48               ` Wathsala Wathawana Vithanage
2024-07-27 17:07         ` Mattias Rönnblom [this message]
2024-07-27 22:45           ` Wathsala Wathawana Vithanage
2024-07-28  6:42             ` Mattias Rönnblom
2024-07-28 15:52               ` Stephen Hemminger
2024-07-29  4:34                 ` Wathsala Wathawana Vithanage
2024-07-29  6:34               ` Wathsala Wathawana Vithanage
2024-07-29  6:47                 ` Mattias Rönnblom
2024-07-29 18:16                   ` Wathsala Wathawana Vithanage
2024-07-29 18:31                     ` Stephen Hemminger
2024-07-29 19:11                     ` Mattias Rönnblom
2024-07-29 19:30                       ` Morten Brørup

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=5d409e6a-1d61-4d8a-b9ab-8cbcf7838ad0@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=Dhruv.Tripathi@arm.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Jack.Bond-Preston@arm.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=Shunzhi.Wen@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=drc@linux.ibm.com \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=nd@arm.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=stanislaw.kardach@gmail.com \
    --cc=thomas@monjalon.net \
    --cc=wathsala.vithanage@arm.com \
    --cc=zhoumin@loongson.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).