On 2024-07-24 22:02, Stephen Hemminger wrote:
On Wed, 24 Jul 2024 21:14:30 +0200
Mattias Rönnblom <hof...@lysator.liu.se> 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.
