From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
"Bruce Richardson" <bruce.richardson@intel.com>
Subject: Re: [PATCH v2 2/2] random: make rte_rand() thread safe for non-EAL threads
Date: Sat, 9 Sep 2023 09:00:42 +0200 [thread overview]
Message-ID: <e4348e47-e4ee-0605-e70b-9692c9129be0@lysator.liu.se> (raw)
In-Reply-To: <20230908135602.4a9026c0@hermes.local>
On 2023-09-08 22:56, Stephen Hemminger wrote:
> On Fri, 8 Sep 2023 22:48:54 +0200
> Mattias Rönnblom <hofors@lysator.liu.se> wrote:
>
>> On 2023-09-07 17:24, Stephen Hemminger wrote:
>>> Add missing locking so that if two non-EAL threads call rte_rand()
>>> they will not corrupt the per-thread state.
>>>
>>> Fixes: 3f002f069612 ("eal: replace libc-based random generation with LFSR")
>>
>> The API documentation clearly states that no MT safety guarantees are
>> given for unregistered non-EAL threads. So this patch doesn't fix anything.
>>
>> rte_rand() is MT safe for *registered* non-EAL threads.
>
> Reading the documentation, it only guarantees safety if registered.
> We should add an otherwise clause rather than leaving case as undefined.
I agree. It is MT safe in case only single unregistered non-EAL thread
uses the API (or multiple such threads, provided they are properly
[externally] serialized).
"If called from EAL threads, registered non-EAL threads or a *single*
unregistered non-EAL thread, this function is thread-safe. Multiple
unregistered non-EAL threads may not safely call this function in
parallel (i.e., must use external serialization)."
A lot of words, unfortunately. Maybe this is better:
"rte_xxx() is MT safe, with the exception it may not be called from
multiple *unregistered* non-EAL threads in parallel."
Then of course comes the issue that nobody knows what is an registered
non-EAL thread is. DPDK threading terminology is a big mess, so no wonder.
next prev parent reply other threads:[~2023-09-09 7:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 15:53 [PATCH] random: initialize the random state for non-eal lcores Stephen Hemminger
2023-09-06 16:25 ` Morten Brørup
2023-09-06 16:28 ` Stephen Hemminger
2023-09-07 15:24 ` [PATCH v2 0/2] fixes to rte_random for non-EAL threads Stephen Hemminger
2023-09-07 15:24 ` [PATCH v2 1/2] random: initialize the random state " Stephen Hemminger
2023-10-02 9:00 ` Morten Brørup
2023-10-02 12:27 ` Mattias Rönnblom
2023-10-02 16:07 ` Stephen Hemminger
2023-10-04 8:45 ` David Marchand
2023-09-07 15:24 ` [PATCH v2 2/2] random: make rte_rand() thread safe " Stephen Hemminger
2023-09-07 15:47 ` Stephen Hemminger
2023-09-07 16:10 ` David Marchand
2023-09-08 20:48 ` Mattias Rönnblom
2023-09-08 20:56 ` Stephen Hemminger
2023-09-09 7:00 ` Mattias Rönnblom [this message]
2023-10-02 16:10 ` Stephen Hemminger
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=e4348e47-e4ee-0605-e70b-9692c9129be0@lysator.liu.se \
--to=hofors@lysator.liu.se \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=mattias.ronnblom@ericsson.com \
--cc=stephen@networkplumber.org \
/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).