| Message ID | 20210302112453.13300-3-talshn@nvidia.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Thomas Monjalon |
| Headers | show |
| Series | EAL Thread TLS API enhancements | expand |
| Context | Check | Description |
|---|---|---|
| ci/github-robot | success | github build: passed |
| ci/intel-Testing | success | Testing PASS |
| ci/iol-testing | success | Testing PASS |
| ci/iol-abi-testing | success | Testing PASS |
| ci/travis-robot | fail | travis build: failed |
| ci/iol-intel-Performance | success | Performance Testing PASS |
| ci/iol-mellanox-Functional | success | Functional Testing PASS |
| ci/iol-mellanox-Performance | success | Performance Testing PASS |
| ci/Intel-compilation | success | Compilation OK |
| ci/checkpatch | success | coding style OK |
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tal Shnaiderman > Sent: Tuesday, March 2, 2021 12:25 PM > > rename the key opaque pointer from rte_tls_key to > rte_thread_tls_key to avoid confusion with transport layer security. > [...] > diff --git a/lib/librte_eal/include/rte_thread.h > b/lib/librte_eal/include/rte_thread.h > index 39737d1829..90bcb02554 100644 > --- a/lib/librte_eal/include/rte_thread.h > +++ b/lib/librte_eal/include/rte_thread.h > @@ -23,7 +23,7 @@ extern "C" { > /** > * TLS key type, an opaque pointer. > */ > -typedef struct eal_tls_key *rte_tls_key; > +typedef struct eal_tls_key *rte_thread_tls_key; > > /** > * Set core affinity of the current thread. > @@ -63,7 +63,8 @@ void rte_thread_get_affinity(rte_cpuset_t *cpusetp); > */ > > __rte_experimental > -int rte_thread_tls_key_create(rte_tls_key *key, void > (*destructor)(void *)); > +int rte_thread_tls_key_create(rte_thread_tls_key *key, > + void (*destructor)(void *)); > I agree with your argument for TLS confusion. How about rte_thread_key, instead of rte_thread_tls_key. Having both thread and tls seems redundant. Here are some more thoughts... It is meant as a provocation only, not a real suggestion: The DPDK API often uses the term "lcore" as the abstraction for threads, e.g. rte_per_lcore.h refers to thread local storage using "per_lcore", while it is in fact "per thread". Why use another terminology in the API for thread keys, instead of sticking with the "lcore" naming tradition, e.g. struct rte_lcore_key? Med venlig hilsen / kind regards - Morten Brørup
> Subject: RE: [dpdk-dev] [PATCH 2/2] eal: rename key opaque pointer in TLS > API > > External email: Use caution opening links or attachments > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tal Shnaiderman > > Sent: Tuesday, March 2, 2021 12:25 PM > > > > rename the key opaque pointer from rte_tls_key to rte_thread_tls_key > > to avoid confusion with transport layer security. > > > > [...] > > > diff --git a/lib/librte_eal/include/rte_thread.h > > b/lib/librte_eal/include/rte_thread.h > > index 39737d1829..90bcb02554 100644 > > --- a/lib/librte_eal/include/rte_thread.h > > +++ b/lib/librte_eal/include/rte_thread.h > > @@ -23,7 +23,7 @@ extern "C" { > > /** > > * TLS key type, an opaque pointer. > > */ > > -typedef struct eal_tls_key *rte_tls_key; > > +typedef struct eal_tls_key *rte_thread_tls_key; > > > > /** > > * Set core affinity of the current thread. > > @@ -63,7 +63,8 @@ void rte_thread_get_affinity(rte_cpuset_t *cpusetp); > > */ > > > > __rte_experimental > > -int rte_thread_tls_key_create(rte_tls_key *key, void > > (*destructor)(void *)); > > +int rte_thread_tls_key_create(rte_thread_tls_key *key, > > + void (*destructor)(void *)); > > > > I agree with your argument for TLS confusion. > > How about rte_thread_key, instead of rte_thread_tls_key. Having both > thread and tls seems redundant. > Thanks for the input, make sense, I'll change the name to your suggestion. > > Here are some more thoughts... It is meant as a provocation only, not a real > suggestion: > > The DPDK API often uses the term "lcore" as the abstraction for threads, e.g. > rte_per_lcore.h refers to thread local storage using "per_lcore", while it is in > fact "per thread". Why use another terminology in the API for thread keys, > instead of sticking with the "lcore" naming tradition, e.g. struct > rte_lcore_key? > You're right, but then there are some functions in eal_common_thread.c which uses the 'thread' terminology, maybe it's a good idea to rework it all to a single accepted term. > > Med venlig hilsen / kind regards > - Morten Brørup > >
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tal Shnaiderman > Sent: Tuesday, March 2, 2021 2:13 PM > > > Subject: RE: [dpdk-dev] [PATCH 2/2] eal: rename key opaque pointer in > TLS > > API > > > > External email: Use caution opening links or attachments > > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tal > Shnaiderman > > > Sent: Tuesday, March 2, 2021 12:25 PM > > > > > > rename the key opaque pointer from rte_tls_key to > rte_thread_tls_key > > > to avoid confusion with transport layer security. > > > > > > > [...] > > > > > diff --git a/lib/librte_eal/include/rte_thread.h > > > b/lib/librte_eal/include/rte_thread.h > > > index 39737d1829..90bcb02554 100644 > > > --- a/lib/librte_eal/include/rte_thread.h > > > +++ b/lib/librte_eal/include/rte_thread.h > > > @@ -23,7 +23,7 @@ extern "C" { > > > /** > > > * TLS key type, an opaque pointer. > > > */ > > > -typedef struct eal_tls_key *rte_tls_key; > > > +typedef struct eal_tls_key *rte_thread_tls_key; > > > > > > /** > > > * Set core affinity of the current thread. > > > @@ -63,7 +63,8 @@ void rte_thread_get_affinity(rte_cpuset_t > *cpusetp); > > > */ > > > > > > __rte_experimental > > > -int rte_thread_tls_key_create(rte_tls_key *key, void > > > (*destructor)(void *)); > > > +int rte_thread_tls_key_create(rte_thread_tls_key *key, > > > + void (*destructor)(void *)); > > > > > > > I agree with your argument for TLS confusion. > > > > How about rte_thread_key, instead of rte_thread_tls_key. Having both > > thread and tls seems redundant. > > > > Thanks for the input, make sense, I'll change the name to your > suggestion. > > > > > Here are some more thoughts... It is meant as a provocation only, not > a real > > suggestion: > > > > The DPDK API often uses the term "lcore" as the abstraction for > threads, e.g. > > rte_per_lcore.h refers to thread local storage using "per_lcore", > while it is in > > fact "per thread". Why use another terminology in the API for thread > keys, > > instead of sticking with the "lcore" naming tradition, e.g. struct > > rte_lcore_key? > > > > You're right, but then there are some functions in eal_common_thread.c > which uses the 'thread' terminology, maybe it's a good idea to rework > it all to a single accepted term. > Agreed. Especially after the introduction of service cores and non-EAL thread support, using "lcore" as a terminology for "thread" seems to be a legacy convention with decreasing relevance. However, cleaning up that convention would totally break the ABI, and take quite an effort. So I guess it will remain wishful thinking only. :-) But we can follow your lead and do it right with new ABIs.
diff --git a/drivers/net/mlx5/linux/mlx5_flow_os.c b/drivers/net/mlx5/linux/mlx5_flow_os.c index 732b1b2dd8..d15a0c0ae7 100644 --- a/drivers/net/mlx5/linux/mlx5_flow_os.c +++ b/drivers/net/mlx5/linux/mlx5_flow_os.c @@ -7,7 +7,7 @@ #include <rte_thread.h> /* Key of thread specific flow workspace data. */ -static rte_tls_key key_workspace; +static rte_thread_tls_key key_workspace; int mlx5_flow_os_init_workspace_once(void) diff --git a/drivers/net/mlx5/windows/mlx5_flow_os.c b/drivers/net/mlx5/windows/mlx5_flow_os.c index 2cc02df322..98b0b06c83 100644 --- a/drivers/net/mlx5/windows/mlx5_flow_os.c +++ b/drivers/net/mlx5/windows/mlx5_flow_os.c @@ -252,7 +252,7 @@ struct mlx5_workspace_thread { */ static struct mlx5_workspace_thread *curr; static struct mlx5_workspace_thread *first; -rte_tls_key ws_tls_index; +rte_thread_tls_key ws_tls_index; static pthread_mutex_t lock_thread_list; static bool diff --git a/lib/librte_eal/include/rte_thread.h b/lib/librte_eal/include/rte_thread.h index 39737d1829..90bcb02554 100644 --- a/lib/librte_eal/include/rte_thread.h +++ b/lib/librte_eal/include/rte_thread.h @@ -23,7 +23,7 @@ extern "C" { /** * TLS key type, an opaque pointer. */ -typedef struct eal_tls_key *rte_tls_key; +typedef struct eal_tls_key *rte_thread_tls_key; /** * Set core affinity of the current thread. @@ -63,7 +63,8 @@ void rte_thread_get_affinity(rte_cpuset_t *cpusetp); */ __rte_experimental -int rte_thread_tls_key_create(rte_tls_key *key, void (*destructor)(void *)); +int rte_thread_tls_key_create(rte_thread_tls_key *key, + void (*destructor)(void *)); /** * Delete a TLS data key visible to all threads in the process. @@ -76,7 +77,7 @@ int rte_thread_tls_key_create(rte_tls_key *key, void (*destructor)(void *)); * On failure, a negative number and an error number is set in rte_errno. */ __rte_experimental -int rte_thread_tls_key_delete(rte_tls_key key); +int rte_thread_tls_key_delete(rte_thread_tls_key key); /** * Set value bound to the TLS key on behalf of the calling thread. @@ -84,14 +85,14 @@ int rte_thread_tls_key_delete(rte_tls_key key); * @param key * The key allocated by rte_thread_tls_key_create(). * @param value - * The value bound to the rte_tls_key key for the calling thread. + * The value bound to the rte_thread_tls_key key for the calling thread. * * @return * On success, zero. * On failure, a negative number and an error number is set in rte_errno. */ __rte_experimental -int rte_thread_tls_value_set(rte_tls_key key, const void *value); +int rte_thread_tls_value_set(rte_thread_tls_key key, const void *value); /** * Get value bound to the TLS key on behalf of the calling thread. @@ -104,7 +105,7 @@ int rte_thread_tls_value_set(rte_tls_key key, const void *value); * On failure, NULL and an error number is set in rte_errno. */ __rte_experimental -void *rte_thread_tls_value_get(rte_tls_key key); +void *rte_thread_tls_value_get(rte_thread_tls_key key); #ifdef __cplusplus } diff --git a/lib/librte_eal/unix/rte_thread.c b/lib/librte_eal/unix/rte_thread.c index 86e42bf653..d2d216ee16 100644 --- a/lib/librte_eal/unix/rte_thread.c +++ b/lib/librte_eal/unix/rte_thread.c @@ -17,7 +17,7 @@ struct eal_tls_key { }; int -rte_thread_tls_key_create(rte_tls_key *key, void (*destructor)(void *)) +rte_thread_tls_key_create(rte_thread_tls_key *key, void (*destructor)(void *)) { int err; @@ -39,7 +39,7 @@ rte_thread_tls_key_create(rte_tls_key *key, void (*destructor)(void *)) } int -rte_thread_tls_key_delete(rte_tls_key key) +rte_thread_tls_key_delete(rte_thread_tls_key key) { int err; @@ -61,7 +61,7 @@ rte_thread_tls_key_delete(rte_tls_key key) } int -rte_thread_tls_value_set(rte_tls_key key, const void *value) +rte_thread_tls_value_set(rte_thread_tls_key key, const void *value) { int err; @@ -81,7 +81,7 @@ rte_thread_tls_value_set(rte_tls_key key, const void *value) } void * -rte_thread_tls_value_get(rte_tls_key key) +rte_thread_tls_value_get(rte_thread_tls_key key) { if (!key) { RTE_LOG(DEBUG, EAL, "Invalid TLS key.\n"); diff --git a/lib/librte_eal/windows/rte_thread.c b/lib/librte_eal/windows/rte_thread.c index 1c226b3e30..f071ab7678 100644 --- a/lib/librte_eal/windows/rte_thread.c +++ b/lib/librte_eal/windows/rte_thread.c @@ -12,7 +12,7 @@ struct eal_tls_key { }; int -rte_thread_tls_key_create(rte_tls_key *key, +rte_thread_tls_key_create(rte_thread_tls_key *key, __rte_unused void (*destructor)(void *)) { *key = malloc(sizeof(**key)); @@ -32,7 +32,7 @@ rte_thread_tls_key_create(rte_tls_key *key, } int -rte_thread_tls_key_delete(rte_tls_key key) +rte_thread_tls_key_delete(rte_thread_tls_key key) { if (!key) { RTE_LOG(DEBUG, EAL, "Invalid TLS key.\n"); @@ -50,7 +50,7 @@ rte_thread_tls_key_delete(rte_tls_key key) } int -rte_thread_tls_value_set(rte_tls_key key, const void *value) +rte_thread_tls_value_set(rte_thread_tls_key key, const void *value) { char *p; @@ -70,7 +70,7 @@ rte_thread_tls_value_set(rte_tls_key key, const void *value) } void * -rte_thread_tls_value_get(rte_tls_key key) +rte_thread_tls_value_get(rte_thread_tls_key key) { void *output;
rename the key opaque pointer from rte_tls_key to rte_thread_tls_key to avoid confusion with transport layer security. Suggested-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com> Signed-off-by: Tal Shnaiderman <talshn@nvidia.com> --- drivers/net/mlx5/linux/mlx5_flow_os.c | 2 +- drivers/net/mlx5/windows/mlx5_flow_os.c | 2 +- lib/librte_eal/include/rte_thread.h | 13 +++++++------ lib/librte_eal/unix/rte_thread.c | 8 ++++---- lib/librte_eal/windows/rte_thread.c | 8 ++++---- 5 files changed, 17 insertions(+), 16 deletions(-)