https://bugs.dpdk.org/show_bug.cgi?id=1706
Bug ID: 1706
Summary: CPU affinity of registered non-EAL threads not
reflected in lcore configuration
Product: DPDK
Version: 25.03
Hardware: All
OS: All
https://bugs.dpdk.org/show_bug.cgi?id=1524
Bug ID: 1524
Summary: rte_lcore API treats Service cores and Registered
Non-EAL threads as disabled
Product: DPDK
Version: 24.07
Hardware: All
OS: All
state reserved for non-EAL threads,
which is not initialized. Fix it by initializing this extra state.
Fixes: 3f002f069612 ("eal: replace libc-based random generation with LFSR")
Cc: mattias.ronnb...@ericsson.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
We have two series for
On Mon, Oct 2, 2023 at 2:28 PM Mattias Rönnblom wrote:
>
> On 2023-09-07 17:24, Stephen Hemminger wrote:
> > The per-lcore PRNG was not initializing the rand_state of all
> > the lcores. Any usage of rte_random by a non-EAL lcore would
>
> "/../ by an unregistered non-EAL thread /../"
>
> > use ra
On 2023-09-07 17:24, Stephen Hemminger wrote:
The per-lcore PRNG was not initializing the rand_state of all
the lcores. Any usage of rte_random by a non-EAL lcore would
"/../ by an unregistered non-EAL thread /../"
use rand_states[RTE_MAX_LCORE] which was never initialized.
Fix by using RTE_
state reserved for non-EAL threads,
which is not initialized. Fix it by initializing this extra state.
Fixes: 3f002f069612 ("eal: replace libc-based random generation with LFSR")
Cc: mattias.ronnb...@ericsson.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
We have two series for
> rand state is initialized up until RTE_MAX_LCORE'th rand state. However,
> > rand state also has one extra rand state reserved for non-EAL threads,
> > which is not initialized. Fix it by initializing this extra state.
> >
> > Fixes: 3f002f069612 ("eal: replace libc-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, 7 September 2023 17.25
>
> The per-lcore PRNG was not initializing the rand_state of all
> the lcores. Any usage of rte_random by a non-EAL lcore would
> use rand_states[RTE_MAX_LCORE] which was never initialized.
>
>
Hello guys,
On Mon, Aug 28, 2023 at 2:07 PM Anatoly Burakov
wrote:
>
> Currently, the rte_rand() state is initialized with seed, and each
> rand state is initialized up until RTE_MAX_LCORE'th rand state. However,
> rand state also has one extra rand state reserved for non-EAL th
On 2023-09-08 22:56, Stephen Hemminger wrote:
On Fri, 8 Sep 2023 22:48:54 +0200
Mattias Rönnblom 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 (&quo
On Fri, 8 Sep 2023 22:48:54 +0200
Mattias Rönnblom 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 (&quo
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
te_random.c
index 02b6b6b97b..3f2a4830fd 100644
--- a/lib/eal/common/rte_random.c
+++ b/lib/eal/common/rte_random.c
@@ -128,20 +128,22 @@ struct rte_rand_state *__rte_rand_get_state(void)
idx = rte_lcore_id();
/* last instance reserved for unregistered non-EAL threads */
- if (unlik
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")
Signed-off-by: Stephen Hemminger
---
lib/eal/common/rte_ran
The per-lcore PRNG was not initializing the rand_state of all
the lcores. Any usage of rte_random by a non-EAL lcore would
use rand_states[RTE_MAX_LCORE] which was never initialized.
Fix by using RTE_DIM() which will get all lcores.
Fixes: 3f002f069612 ("eal: replace libc-based random generation
While examining the code for rte_random, noticed a couple of
existing bugs around use of rte_rand() by non-EAL threads
Stephen Hemminger (2):
random: initialize the random state for non-EAL threads
random: make rte_rand() thread safe for non-EAL threads
lib/eal/common/rte_random.c | 56
#x27;th rand state.
> However,
> > rand state also has one extra rand state reserved for non-EAL threads,
> > which is not initialized. Fix it by initializing this extra state.
> >
> > Fixes: 3f002f069612 ("eal: replace libc-based random generation with
> LFSR
On 2023-08-28 14:06, Anatoly Burakov wrote:
Currently, the rte_rand() state is initialized with seed, and each
rand state is initialized up until RTE_MAX_LCORE'th rand state. However,
rand state also has one extra rand state reserved for non-EAL threads,
which is not initialized. Fix
Currently, the rte_rand() state is initialized with seed, and each
rand state is initialized up until RTE_MAX_LCORE'th rand state. However,
rand state also has one extra rand state reserved for non-EAL threads,
which is not initialized. Fix it by initializing this extra state.
Fixes: 3f002f0
On Mon, Dec 5, 2022 at 11:08 AM Mattias Rönnblom
wrote:
>
> Prior to this change, unregistered non-EAL threads shared a PRNG
> instance with the main lcore. The main lcore may well be used for fast
> path processing, potentially making rte_rand() calls in the
> process. It sho
On 2022-12-05 11:58, Morten Brørup wrote:
>> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
>> Sent: Monday, 5 December 2022 11.04
>>
>> Prior to this change, unregistered non-EAL threads shared a PRNG
>> instance with the main lcore. The main lcore may
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
> Sent: Monday, 5 December 2022 11.04
>
> Prior to this change, unregistered non-EAL threads shared a PRNG
> instance with the main lcore. The main lcore may well be used for fast
> path processing, potential
Prior to this change, unregistered non-EAL threads shared a PRNG
instance with the main lcore. The main lcore may well be used for fast
path processing, potentially making rte_rand() calls in the
process. It should not need to synchronize with control threads.
With this change, all unregistered
This patch adds statistics for unregistered non-EAL threads, which was
previously not included in the statistics.
Add one more entry to the stats array, and use the last index for
unregistered non-EAL threads.
The unregistered non-EAL thread statistics are incremented atomically.
In theory, the
On 11/4/22 15:03, Morten Brørup wrote:
This patch adds statistics for unregistered non-EAL threads, which was
previously not included in the statistics.
Add one more entry to the stats array, and use the last index for
unregistered non-EAL threads.
The unregistered non-EAL thread statistics
This patch adds statistics for unregistered non-EAL threads, which was
previously not included in the statistics.
Add one more entry to the stats array, and use the last index for
unregistered non-EAL threads.
The unregistered non-EAL thread statistics are incremented atomically.
In theory, the
This patch adds statistics for unregistered non-EAL threads, which was
previously not included in the statistics.
Add one more entry to the stats array, and use the last index for
unregistered non-EAL threads.
The unregistered non-EAL thread statistics are incremented atomically.
In theory, the
(and other applications) has its own thread management but still
> > want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
> > faking EAL threads potentially unknown of some DPDK component.
> >
> > Introduce a new API to register non-EAL thread and associate the
t; want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
> faking EAL threads potentially unknown of some DPDK component.
>
> Introduce a new API to register non-EAL thread and associate them to a
> free lcore with a new NON_EAL role.
> This role denotes lcores that
On 2022-09-21 11:05, Bruce Richardson wrote:
On Wed, Sep 21, 2022 at 10:39:15AM +0200, Mattias Rönnblom wrote:
I have some lcore-related questions:
The documentation make use of the term "non-EAL thread". Is a non-EAL thread
the same thing as a non-lcore thread? I.e., are there E
"non-EAL thread". Is a non-EAL
> thread
> > the same thing as a non-lcore thread? I.e., are there EAL threads
> that are
> > not lcore threads?
>
> Yes, there are some threads created by EAL which are not lcore threads.
> These are generally for background tasks,
On Wed, Sep 21, 2022 at 10:39:15AM +0200, Mattias Rönnblom wrote:
> I have some lcore-related questions:
>
> The documentation make use of the term "non-EAL thread". Is a non-EAL thread
> the same thing as a non-lcore thread? I.e., are there EAL threads that are
> not l
I have some lcore-related questions:
The documentation make use of the term "non-EAL thread". Is a non-EAL
thread the same thing as a non-lcore thread? I.e., are there EAL threads
that are not lcore threads?
I also have a question related to rte_register_thread(): sho
On Thu, Mar 18, 2021 at 02:48:01PM +, Tal Shnaiderman wrote:
>
> I don't know if this table is needed, the approach should be to have the
> return value/rte_errno identical between the OSs.
> And having the specific OS errno printed.
the underlying problem here is that dpdk is adopting linux
On Thu, Mar 18, 2021 at 02:48:01PM +, Tal Shnaiderman wrote:
> > Subject: [dpdk-dev] [PATCH 1/3] Add EAL threads API
> >
> > From: Narcisa Vasile
> >
> > EAL must hide the environment specifics from apps and libraries.
> > Add an EAL API for managing thre
On Thu, Mar 18, 2021 at 04:48:49PM +0100, David Marchand wrote:
> On Thu, Mar 18, 2021 at 2:01 AM Narcisa Ana Maria Vasile
> wrote:
> > diff --git a/lib/librte_eal/common/eal_common_thread.c
> > b/lib/librte_eal/common/eal_common_thread.c
> > index 73a055902..5219e783e 100644
> > --- a/lib/librte
On Thu, Mar 18, 2021 at 2:01 AM Narcisa Ana Maria Vasile
wrote:
> diff --git a/lib/librte_eal/common/eal_common_thread.c
> b/lib/librte_eal/common/eal_common_thread.c
> index 73a055902..5219e783e 100644
> --- a/lib/librte_eal/common/eal_common_thread.c
> +++ b/lib/librte_eal/common/eal_common_thr
> Subject: [dpdk-dev] [PATCH 1/3] Add EAL threads API
>
> From: Narcisa Vasile
>
> EAL must hide the environment specifics from apps and libraries.
> Add an EAL API for managing threads.
>
> Signed-off-by: Narcisa Vasile
> Signed-off-by: Dmitry Malloy
> ---
Hi
From: Narcisa Vasile
EAL must hide the environment specifics from apps and libraries.
Add an EAL API for managing threads.
Signed-off-by: Narcisa Vasile
Signed-off-by: Dmitry Malloy
---
lib/librte_eal/common/eal_common_thread.c | 6 +-
lib/librte_eal/common/rte_thread.c| 346
On Mon, Jul 6, 2020 at 10:53 PM David Marchand
wrote:
>
> OVS and some other applications have been hacking into DPDK internals to
> fake EAL threads and avoid performance penalty of only having non-EAL
> threads.
>
> This series proposes to add a new type of lcores and maps
On Tue, Jul 7, 2020 at 1:23 AM Ananyev, Konstantin
wrote:
> > OVS and some other applications have been hacking into DPDK internals to
> > fake EAL threads and avoid performance penalty of only having non-EAL
> > threads.
> >
> > This series proposes to add a new
Hi David,
> OVS and some other applications have been hacking into DPDK internals to
> fake EAL threads and avoid performance penalty of only having non-EAL
> threads.
>
> This series proposes to add a new type of lcores and maps those threads
> to such lcores.
> non-EAL
OVS and some other applications have been hacking into DPDK internals to
fake EAL threads and avoid performance penalty of only having non-EAL
threads.
This series proposes to add a new type of lcores and maps those threads
to such lcores.
non-EAL threads won't run the DPDK eal mainloop.
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component
OVS and some other applications have been hacking into DPDK internals to
fake EAL threads and avoid performance penalty of only having non-EAL
threads.
This series proposes to add a new type of lcores and maps those threads
to such lcores.
non-EAL threads won't run the DPDK eal mainloop.
>
> On Fri, Jul 3, 2020 at 6:40 PM Ananyev, Konstantin
> wrote:
> > what are the advantages of current approach (forbid MP support on the fly)
> > over explicit start-up parameters (either --proc-type=single or
> > --lcore-allow=...)?
> > Why do you think it is a better one?
>
> I don't want t
On Fri, Jul 3, 2020 at 6:40 PM Ananyev, Konstantin
wrote:
> what are the advantages of current approach (forbid MP support on the fly)
> over explicit start-up parameters (either --proc-type=single or
> --lcore-allow=...)?
> Why do you think it is a better one?
I don't want to perpetuate the "pl
> > > If the final users finally hit the situation you describe, it means
> > > that the multiprocess had been in use so far and was known to be in
> > > use (*hopefully*).
> >
> > Yes.
> >
> > > So is it not a problem of design/non-regression testing when
> > > integrating the new API in the fir
02/07/2020 15:06, David Marchand:
> On Wed, Jul 1, 2020 at 1:58 PM Ananyev, Konstantin
> wrote:
> > > If the final users finally hit the situation you describe, it means
> > > that the multiprocess had been in use so far and was known to be in
> > > use (*hopefully*).
> >
> > Yes.
> >
> > > So is
On Wed, Jul 1, 2020 at 1:58 PM Ananyev, Konstantin
wrote:
> > If the final users finally hit the situation you describe, it means
> > that the multiprocess had been in use so far and was known to be in
> > use (*hopefully*).
>
> Yes.
>
> > So is it not a problem of design/non-regression testing wh
>
> On Tue, Jun 30, 2020 at 8:57 PM Ananyev, Konstantin
> wrote:
> > Imagine the situation - there is a primary proc (supposed to run forever)
> > that does rte_thread_register/rte_thread_unregister during its lifetime.
> > Plus from time to time user runs some secondary process to collect
> >
t; > > has some limitations.
> > > OVS (and other applications) has its own thread management but still
> > > want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
> > > faking EAL threads potentially unknown of some DPDK component.
> > >
&g
On Tue, Jun 30, 2020 at 8:57 PM Ananyev, Konstantin
wrote:
> Imagine the situation - there is a primary proc (supposed to run forever)
> that does rte_thread_register/rte_thread_unregister during its lifetime.
> Plus from time to time user runs some secondary process to collect stats/debug
> the
ead management but still
> > want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
> > faking EAL threads potentially unknown of some DPDK component.
> >
> > Introduce a new API to register non-EAL thread and associate them to a
> > free lcore with a new
>
> On Tue, Jun 30, 2020 at 12:07:32PM +, Ananyev, Konstantin wrote:
> > >
> > > 26/06/2020 16:43, David Marchand:
> > > > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> > > > wrote:
> > > > > > > Do you mean - make this new dynamic-lcore API return an error if
> > > > > > > callied
>
> 30/06/2020 14:07, Ananyev, Konstantin:
> > > 26/06/2020 16:43, David Marchand:
> > > > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> > > > wrote:
> > > > > > > Do you mean - make this new dynamic-lcore API return an error if
> > > > > > > callied
> > > > > > > from secondary process
data
> > and if so - split lcore_id space properly among them
> > (same as he has to do now with static lcores).
>
> A variant (more simple) of your approach could be to add
> "--proc-type=standalone" to explicitly disable MP and enable dynamic thread
> registr
30/06/2020 14:07, Ananyev, Konstantin:
> > 26/06/2020 16:43, David Marchand:
> > > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> > > wrote:
> > > > > > Do you mean - make this new dynamic-lcore API return an error if
> > > > > > callied
> > > > > > from secondary process?
> > > > >
> > >
On Tue, Jun 30, 2020 at 12:07:32PM +, Ananyev, Konstantin wrote:
> >
> > 26/06/2020 16:43, David Marchand:
> > > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> > > wrote:
> > > > > > Do you mean - make this new dynamic-lcore API return an error if
> > > > > > callied
> > > > > > from
>
> 26/06/2020 16:43, David Marchand:
> > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> > wrote:
> > > > > Do you mean - make this new dynamic-lcore API return an error if
> > > > > callied
> > > > > from secondary process?
> > > >
> > > > Yes, and prohibiting from attaching a secondary
26/06/2020 16:43, David Marchand:
> On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> wrote:
> > > > Do you mean - make this new dynamic-lcore API return an error if callied
> > > > from secondary process?
> > >
> > > Yes, and prohibiting from attaching a secondary process if dynamic
> > > lco
TE_PER_LCORE(_lcore_id) and
> faking EAL threads potentially unknown of some DPDK component.
>
> Introduce a new API to register non-EAL thread and associate them to a
> free lcore with a new NON_EAL role.
> This role denotes lcores that do not run DPDK mainloop and as such
> prevents u
> }
> if (rte_eal_config_reattach() < 0)
> return -1;
> + if (!eal_mcfg_enable_multiprocess()) {
> + RTE_LOG(ERR, EAL, "Primary process refused secondary
> attachment\n");
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component
OVS and some other applications have been hacking into DPDK internals to
fake EAL threads and avoid performance penalty of only having non-EAL
threads.
This series proposes to add a new type of lcores and maps those threads
to such lcores.
non-EAL threads won't run the DPDK eal mainloop.
On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
wrote:
> > > Do you mean - make this new dynamic-lcore API return an error if callied
> > > from secondary process?
> > >
> >
> > Yes, and prohibiting from attaching a secondary process if dynamic
> > lcore API has been used in primary.
> > I int
>
> On Wed, Jun 24, 2020 at 12:40 PM Ananyev, Konstantin
> wrote:
> > > Supporting lcore allocation in MP requires exchanges between
> > > primary/secondary processes like what we have for memory allocations.
> > > It will be quite a beast to get to work fine, while not even knowing
> > > if peo
On Wed, Jun 24, 2020 at 12:40 PM Ananyev, Konstantin
wrote:
> > Supporting lcore allocation in MP requires exchanges between
> > primary/secondary processes like what we have for memory allocations.
> > It will be quite a beast to get to work fine, while not even knowing
> > if people actually wan
>
> 24/06/2020 11:56, Bruce Richardson:
> > On Wed, Jun 24, 2020 at 11:23:55AM +0200, David Marchand wrote:
> > > On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin
> > > wrote:
> > > > > Even before this series, MP has no protection on lcore placing between
> > > > > primary and secondary proce
n
> ; Mcnamara, John
> ; Kovacevic, Marko ;
> Burakov, Anatoly ; Olivier
> Matz ; Andrew Rybchenko ;
> Neil Horman
> Subject: Re: [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores
>
> On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin
> wrote:
> &
24/06/2020 11:56, Bruce Richardson:
> On Wed, Jun 24, 2020 at 11:23:55AM +0200, David Marchand wrote:
> > On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin
> > wrote:
> > > > Even before this series, MP has no protection on lcore placing between
> > > > primary and secondary processes.
> > >
> >
On Wed, Jun 24, 2020 at 11:23:55AM +0200, David Marchand wrote:
> On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin
> wrote:
> > > Even before this series, MP has no protection on lcore placing between
> > > primary and secondary processes.
> >
> > Agree, it is not a new problem, it has been the
On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin
wrote:
> > Even before this series, MP has no protection on lcore placing between
> > primary and secondary processes.
>
> Agree, it is not a new problem, it has been there for a while.
> Though making lcore assignment dynamic will make it more n
On 6/22/20 4:25 PM, David Marchand wrote:
> DPDK allows calling some part of its API from a non-EAL thread but this
> has some limitations.
> OVS (and other applications) has its own thread management but still
> want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
Hi David,
> > > diff --git a/lib/librte_eal/common/eal_common_lcore.c
> > > b/lib/librte_eal/common/eal_common_lcore.c
> > > index 86d32a3dd7..7db05428e7 100644
> > > --- a/lib/librte_eal/common/eal_common_lcore.c
> > > +++ b/lib/librte_eal/common/eal_common_lcore.c
> > > @@ -220,3 +221,38 @@ rte
On Tue, Jun 23, 2020 at 11:14 AM Bruce Richardson
wrote:
>
> On Tue, Jun 23, 2020 at 09:49:18AM +0200, David Marchand wrote:
> > Hello Konstantin,
> >
> > On Mon, Jun 22, 2020 at 5:49 PM Ananyev, Konstantin
> > wrote:
> > > > diff --git a/lib/librte_eal/common/eal_common_lcore.c
> > > > b/lib/li
On Tue, Jun 23, 2020 at 09:49:18AM +0200, David Marchand wrote:
> Hello Konstantin,
>
> On Mon, Jun 22, 2020 at 5:49 PM Ananyev, Konstantin
> wrote:
> > > diff --git a/lib/librte_eal/common/eal_common_lcore.c
> > > b/lib/librte_eal/common/eal_common_lcore.c
> > > index 86d32a3dd7..7db05428e7 100
Hello Konstantin,
On Mon, Jun 22, 2020 at 5:49 PM Ananyev, Konstantin
wrote:
> > diff --git a/lib/librte_eal/common/eal_common_lcore.c
> > b/lib/librte_eal/common/eal_common_lcore.c
> > index 86d32a3dd7..7db05428e7 100644
> > --- a/lib/librte_eal/common/eal_common_lcore.c
> > +++ b/lib/librte_ea
>
> Hi David,
>
> > diff --git a/lib/librte_eal/common/eal_common_lcore.c
> > b/lib/librte_eal/common/eal_common_lcore.c
> > index 86d32a3dd7..7db05428e7 100644
> > --- a/lib/librte_eal/common/eal_common_lcore.c
> > +++ b/lib/librte_eal/common/eal_common_lcore.c
> > @@ -6,12 +6,13 @@
> > #inc
644
> --- a/lib/librte_eal/rte_eal_version.map
> +++ b/lib/librte_eal/rte_eal_version.map
> @@ -396,6 +396,8 @@ EXPERIMENTAL {
>
> # added in 20.08
> __rte_trace_mem_per_thread_free;
> + rte_thread_register;
> + rte_thread_unregister;
> };
>
>
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component
OVS and some other applications have been hacking into DPDK internals to
fake EAL threads and avoid performance penalty of only having non-EAL
threads.
This series proposes to add a new type of lcores and maps those threads
to such lcores.
non-EAL threads won't run the DPDK eal mainloop.
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component
OVS and some other applications have been hacking into DPDK internals to
fake EAL threads and avoid performance penalty of only having non-EAL
threads.
This series proposes to add a new type of lcores and maps those threads
to such lcores.
non-EAL threads won't run the DPDK eal mainloop.
and
> faking EAL threads potentially unknown of some DPDK component.
>
> Introduce a new API to register non-EAL thread and associate them to a
> free lcore with a new EXTERNAL role.
> This role denotes lcores that do not run DPDK mainloop and as such
> prevents use of rte_eal_wait_lc
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component
From: Erik Carrillo
This commit adds support for timers being created from
non-EAL threads; it maps timers from all such threads to
lcore id RTE_MAX_LCORE, and puts them all in a corresponding
skiplist.
Signed-off-by: Erik Gabriel Carrillo
---
v3:
* Rebased patch on reworked parent commit
v2
This commit adds support for timers being created from
non-EAL threads; it maps timers from all such threads to
lcore id RTE_MAX_LCORE, and puts them all in a corresponding
skiplist.
Signed-off-by: Erik Gabriel Carrillo
---
V3:
* Rebased patch on reworked parent commit
v2:
* Address checkpatch
This commit adds support for timers being created from
non-EAL threads; it maps timers from all such threads to
lcore id RTE_MAX_LCORE, and puts them all in a corresponding
skiplist.
Signed-off-by: Gabriel Carrillo
---
v2:
* Address checkpatch warnings
lib/librte_timer/rte_timer.c | 48
This commit adds support for timers being created from
non-EAL threads; it maps timers from all such threads to
lcore id RTE_MAX_LCORE, and puts them all in a corresponding
skiplist.
Signed-off-by: Gabriel Carrillo
---
lib/librte_timer/rte_timer.c | 48
nts for rte_rings, just for mempools. Yes,
> > you
> > need a NUMA node ID when creating the ring, so that DPDK knows where to
> > allocate
> > the memory for it. However, once that is done, the ring can safely be used
> > from
> > both EAL and non-EAL threads. Th
ecific elements for rte_rings, just for mempools. Yes, you
> need a NUMA node ID when creating the ring, so that DPDK knows where to
> allocate
> the memory for it. However, once that is done, the ring can safely be used
> from
> both EAL and non-EAL threads. There is no requirement to
will work.
>
> Rgds,
> Gopa.
There are no core-specific elements for rte_rings, just for mempools. Yes, you
need a NUMA node ID when creating the ring, so that DPDK knows where to allocate
the memory for it. However, once that is done, the ring can safely be used from
both EAL and non-EAL th
rte_ring_create() needs a socket-id though and seems to be allocating
core-specific memory pools for the ring ? But my non-EAL app thread is
not bound to any core, so now I am wondering if that will work.
Rgds,
Gopa.
On Wed, Jul 1, 2015 at 10:46 AM, Gopakumar Choorakkot Edakkunni
wrote:
> Hi,
>
Hi,
I have a requirement where one of my non-EAL app threads needs to
handoff some packets to an EAL task. I was thinking of using
rte_ring_mp_enqueue/dequeue for that purpose. I looked at the code for
the rte_ring library and it doesnt look like it has any "EAL"
dependencies, but I wanted to doub
96 matches
Mail list logo
