History log of /dpdk/lib/eal/linux/eal_thread.c (Results 1 – 7 of 7)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# a95d7054 05-Apr-2022 David Marchand <[email protected]>

eal: factorize lcore main loop

All OS implementations provide the same main loop.
Introduce helpers (shared for Linux and FreeBSD) to handle synchronisation
between main and threads and factorize th

eal: factorize lcore main loop

All OS implementations provide the same main loop.
Introduce helpers (shared for Linux and FreeBSD) to handle synchronisation
between main and threads and factorize the rest as common code.
Thread id are now logged as string in a common format across OS.

Note:
- this change also fixes Windows EAL: worker threads cpu affinity was
incorrectly reported in log.

- libabigail flags this change as breaking ABI in clang builds:
1 function with some indirect sub-type change:

[C] 'function int rte_eal_remote_launch(int (void*)*, void*, unsigned
int)' at eal_common_launch.c:35:1 has some indirect sub-type
changes:
parameter 1 of type 'int (void*)*' changed:
in pointed to type 'function type int (void*)' at rte_launch.h:31:1:
entity changed from 'function type int (void*)' to 'typedef
lcore_function_t' at rte_launch.h:31:1
type size hasn't changed

This is being investigated on libabigail side.
For now, we don't have much choice but to waive reports on this symbol.

Signed-off-by: David Marchand <[email protected]>
Acked-by: Morten Brørup <[email protected]>
Acked-by: Tyler Retzlaff <[email protected]>

show more ...


# 449e7dbc 05-Apr-2022 David Marchand <[email protected]>

eal: cleanup lcore ID hand-over

So far, a worker thread has been using its thread_id to discover which
lcore has been assigned to it.

On the other hand, as noted by Tyler, the pthread API does not

eal: cleanup lcore ID hand-over

So far, a worker thread has been using its thread_id to discover which
lcore has been assigned to it.

On the other hand, as noted by Tyler, the pthread API does not strictly
guarantee that a new thread won't start running eal_thread_loop before
pthread_create writes to &lcore_config[xx].thread_id.

Though all OS implementations supported in DPDK (recently) ensure this
property, it is more robust to have the main thread directly pass
the worker thread lcore.

Signed-off-by: David Marchand <[email protected]>

show more ...


Revision tags: v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2
# 30a1de10 15-Feb-2022 Sean Morrissey <[email protected]>

lib: remove unneeded header includes

These header includes have been flagged by the iwyu_tool
and removed.

Signed-off-by: Sean Morrissey <[email protected]>


Revision tags: v22.03-rc1, v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2, v21.11-rc1
# 35965370 25-Oct-2021 Honnappa Nagarahalli <[email protected]>

eal: fix memory ordering around lcore task accesses

Ensure that the memory operations before the call to
rte_eal_remote_launch are visible to the worker thread.
Use the function pointer to execute i

eal: fix memory ordering around lcore task accesses

Ensure that the memory operations before the call to
rte_eal_remote_launch are visible to the worker thread.
Use the function pointer to execute in worker thread
as the guard variable.

Ensure that the memory operations in worker thread, that happen
before it returns the status of the assigned function, are
visible to the main thread. Use the variable containing the
lcore's state as the guard variable.

Signed-off-by: Honnappa Nagarahalli <[email protected]>
Reviewed-by: Ola Liljedahl <[email protected]>
Reviewed-by: Feifei Wang <[email protected]>

show more ...


# f6c6c686 25-Oct-2021 Honnappa Nagarahalli <[email protected]>

eal: remove FINISHED lcore state

FINISHED state seems to be used to indicate that the worker's update
of the 'state' is not visible to other threads. There seems to be no
requirement to have such a

eal: remove FINISHED lcore state

FINISHED state seems to be used to indicate that the worker's update
of the 'state' is not visible to other threads. There seems to be no
requirement to have such a state.

Since the FINISHED state is removed, the API rte_eal_wait_lcore
is updated to always return the status of the last function that
ran in the worker core.

Signed-off-by: Honnappa Nagarahalli <[email protected]>
Reviewed-by: Ola Liljedahl <[email protected]>
Reviewed-by: Feifei Wang <[email protected]>

show more ...


# 33969e9c 25-Oct-2021 Honnappa Nagarahalli <[email protected]>

eal: reset lcore task callback and argument

In the rte_eal_remote_launch function, the lcore function
pointer is checked for NULL. However, the pointer is never
reset to NULL. Reset the lcore functi

eal: reset lcore task callback and argument

In the rte_eal_remote_launch function, the lcore function
pointer is checked for NULL. However, the pointer is never
reset to NULL. Reset the lcore function pointer and argument
after the worker has completed executing the lcore function.

Fixes: af75078fece3 ("first public release")
Cc: [email protected]

Signed-off-by: Honnappa Nagarahalli <[email protected]>
Reviewed-by: Ruifeng Wang <[email protected]>
Reviewed-by: Feifei Wang <[email protected]>

show more ...


Revision tags: v21.08, v21.08-rc4, v21.08-rc3, v21.08-rc2, v21.08-rc1, v21.05, v21.05-rc4, v21.05-rc3, v21.05-rc2, v21.05-rc1
# 99a2dd95 20-Apr-2021 Bruce Richardson <[email protected]>

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
m

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'

Signed-off-by: Bruce Richardson <[email protected]>

show more ...