> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Stephen Hemminger
> Sent: Wednesday, April 10, 2019 10:46 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger <step...@networkplumber.org>
> Subject: [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for
> lcore_config
>
> The fields of the internal EAL core configuration are currently laid bare as
> part of
> the API. This is not good practice and limits fixing issues with layout and
> sizes.
>
> Make new accessor functions for the fields used by current drivers and
> examples. Mark return code functions as experimental since this value might
> change in the future and probably shouldn't have been used by non EAL code
> anyway.
>
> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
> Reviewed-by: David Marchand <david.march...@redhat.com>
> Shared Library Versions
> -----------------------
> diff --git a/lib/librte_eal/common/eal_common_lcore.c
> b/lib/librte_eal/common/eal_common_lcore.c
> index 1cbac42286ba..6cf4d7abb0bd 100644
> --- a/lib/librte_eal/common/eal_common_lcore.c
> +++ b/lib/librte_eal/common/eal_common_lcore.c
> @@ -16,6 +16,45 @@
> #include "eal_private.h"
> #include "eal_thread.h"
>
> +int rte_lcore_index(int lcore_id)
> +{
> + if (unlikely(lcore_id >= RTE_MAX_LCORE))
> + return -1;
> +
> + if (lcore_id < 0)
> + lcore_id = (int)rte_lcore_id();
> +
> + return lcore_config[lcore_id].core_index;
> +}
If I understand it correctly, We are planning to do this scheme only for slow
path functions. Right?
Is rte_lcore_* functions comes in slow path category? I thought a few of them
can be used
In fast path too.
I am bit concerned about a low end arm cores where function invocation overhead
significant vs inline.
ODP has taken a route of introducing a compile time config to choose inline vs
separate function to address
the performance regression . I am not sure what would be the correct way to
handle this.
