[dpdk-dev] eal: added new `rte_lcore_is_service_lcore` API.

  This API can be used to test if an lcore(EAL thread) is a service lcore.

Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
---
 lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
  

> From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Wednesday, August 23, 2017 4:10 PM
> To: dev@dpdk.org
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> <pbhagavatula@caviumnetworks.com>
> Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> 
> This API can be used to test if an lcore(EAL thread) is a service lcore.
> 
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> ---
>  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/lib/librte_eal/common/include/rte_lcore.h
> b/lib/librte_eal/common/include/rte_lcore.h
> index 50e0d0f..7854ea1 100644
> --- a/lib/librte_eal/common/include/rte_lcore.h
> +++ b/lib/librte_eal/common/include/rte_lcore.h
> @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
>  }
> 
>  /**
> + * Test if an lcore is service lcore.
> + *
> + * @param lcore_id
> + *   The identifier of the lcore, which MUST be between 0 and
> + *   RTE_MAX_LCORE-1.
> + * @return
> + *   True if the given lcore is service; false otherwise.
> + */
> +static inline int
> +rte_lcore_is_service_lcore(unsigned lcore_id)
> +{
> +	struct rte_config *cfg = rte_eal_get_configuration();
> +	if (lcore_id >= RTE_MAX_LCORE)
> +		return 0;
> +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> +}

No header file and Static inline - so this is only to be used internally in the service cores library?
If so, the function should actually be used, instead of only added but not used in the library itself.

Or am I mis-understanding the intent?

-Harry
  

On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > Sent: Wednesday, August 23, 2017 4:10 PM
> > To: dev@dpdk.org
> > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > <pbhagavatula@caviumnetworks.com>
> > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> >
> > This API can be used to test if an lcore(EAL thread) is a service lcore.
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > ---
> >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > b/lib/librte_eal/common/include/rte_lcore.h
> > index 50e0d0f..7854ea1 100644
> > --- a/lib/librte_eal/common/include/rte_lcore.h
> > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> >  }
> >
> >  /**
> > + * Test if an lcore is service lcore.
> > + *
> > + * @param lcore_id
> > + *   The identifier of the lcore, which MUST be between 0 and
> > + *   RTE_MAX_LCORE-1.
> > + * @return
> > + *   True if the given lcore is service; false otherwise.
> > + */
> > +static inline int
> > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > +{
> > +	struct rte_config *cfg = rte_eal_get_configuration();
> > +	if (lcore_id >= RTE_MAX_LCORE)
> > +		return 0;
> > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > +}
>
> No header file and Static inline - so this is only to be used internally in the service cores library?
> If so, the function should actually be used, instead of only added but not used in the library itself.
>

The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
a service lcore as well as an EAL thread some libraries such as rte_timer allow
specific operations only over EAL threads.

The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
allow timers to be registered on a service core as processing those timers can
be done on them. This new function allows such libraries to check if the role is
ROLE_SERVICE and allow those operations.

Currently, the only rte_timer library has this specific role check. The
following patch shows the usage in rte_timer library.

http://dpdk.org/dev/patchwork/patch/27819/

> Or am I mis-understanding the intent?
>
> -Harry

Thanks,
Pavan.
  

> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Monday, August 28, 2017 12:33 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> 
> On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > Sent: Wednesday, August 23, 2017 4:10 PM
> > > To: dev@dpdk.org
> > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > > <pbhagavatula@caviumnetworks.com>
> > > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > >
> > > This API can be used to test if an lcore(EAL thread) is a service lcore.
> > >
> > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > ---
> > >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> > >  1 file changed, 18 insertions(+)
> > >
> > > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > > b/lib/librte_eal/common/include/rte_lcore.h
> > > index 50e0d0f..7854ea1 100644
> > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > >  }
> > >
> > >  /**
> > > + * Test if an lcore is service lcore.
> > > + *
> > > + * @param lcore_id
> > > + *   The identifier of the lcore, which MUST be between 0 and
> > > + *   RTE_MAX_LCORE-1.
> > > + * @return
> > > + *   True if the given lcore is service; false otherwise.
> > > + */
> > > +static inline int
> > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > +{
> > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > +		return 0;
> > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > +}
> >
> > No header file and Static inline - so this is only to be used internally in the service
> cores library?
> > If so, the function should actually be used, instead of only added but not used in the
> library itself.
> >
> 
> The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> a service lcore as well as an EAL thread some libraries such as rte_timer allow
> specific operations only over EAL threads.

Understood that role of cores is important, and that rte_timer might require this information.


> The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> allow timers to be registered on a service core as processing those timers can
> be done on them.

No problem from me here either - although it's the Timers library maintainer that should check this.


> This new function allows such libraries to check if the role is
> ROLE_SERVICE and allow those operations.

If the timers library requires information about service-cores, it should use a public API to retrieve that information. Having "internal" functions between libraries is not nice.

I think a better design would be to add this function as a public function, (add it to the .map files etc) and then call the public function from the timers library.

Does that sound like a good solution? -Harry


> Currently, the only rte_timer library has this specific role check. The
> following patch shows the usage in rte_timer library.
> 
> http://dpdk.org/dev/patchwork/patch/27819/
> 
> > Or am I mis-understanding the intent?
> >
> > -Harry
> 
> Thanks,
> Pavan.
  

On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > Sent: Monday, August 28, 2017 12:33 PM
> > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> >
> > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > Sent: Wednesday, August 23, 2017 4:10 PM
> > > > To: dev@dpdk.org
> > > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > > > <pbhagavatula@caviumnetworks.com>
> > > > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > >
> > > > This API can be used to test if an lcore(EAL thread) is a service lcore.
> > > >
> > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > > ---
> > > >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> > > >  1 file changed, 18 insertions(+)
> > > >
> > > > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > > > b/lib/librte_eal/common/include/rte_lcore.h
> > > > index 50e0d0f..7854ea1 100644
> > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > >  }
> > > >
> > > >  /**
> > > > + * Test if an lcore is service lcore.
> > > > + *
> > > > + * @param lcore_id
> > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > + *   RTE_MAX_LCORE-1.
> > > > + * @return
> > > > + *   True if the given lcore is service; false otherwise.
> > > > + */
> > > > +static inline int
> > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > +{
> > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > +		return 0;
> > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > +}
> > >
> > > No header file and Static inline - so this is only to be used internally in the service
> > cores library?
> > > If so, the function should actually be used, instead of only added but not used in the
> > library itself.
> > >
> >
> > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> > a service lcore as well as an EAL thread some libraries such as rte_timer allow
> > specific operations only over EAL threads.
>
> Understood that role of cores is important, and that rte_timer might require this information.
>
>
> > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> > allow timers to be registered on a service core as processing those timers can
> > be done on them.
>
> No problem from me here either - although it's the Timers library maintainer that should check this.
>
>
> > This new function allows such libraries to check if the role is
> > ROLE_SERVICE and allow those operations.
>
> If the timers library requires information about service-cores, it should use a public API to retrieve that information. Having "internal" functions between libraries is not nice.
>
> I think a better design would be to add this function as a public function, (add it to the .map files etc) and then call the public function from the timers library.
>
> Does that sound like a good solution? -Harry
>

The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
file for eal/common and also other functions that are present in rte_lcore.h
aren't mapped in eal/linuxapp or eal/bsdapp.
I think it is fine as the functions are static inline.

-Pavan

>
> > Currently, the only rte_timer library has this specific role check. The
> > following patch shows the usage in rte_timer library.
> >
> > http://dpdk.org/dev/patchwork/patch/27819/
> >
> > > Or am I mis-understanding the intent?
> > >
> > > -Harry
> >
> > Thanks,
> > Pavan.
  

> -----Original Message-----
> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Monday, August 28, 2017 4:10 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> 
> On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > Sent: Monday, August 28, 2017 12:33 PM
> > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > >
> > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > Sent: Wednesday, August 23, 2017 4:10 PM
> > > > > To: dev@dpdk.org
> > > > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > > > > <pbhagavatula@caviumnetworks.com>
> > > > > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > > >
> > > > > This API can be used to test if an lcore(EAL thread) is a service lcore.
> > > > >
> > > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > > > ---
> > > > >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> > > > >  1 file changed, 18 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > > > > b/lib/librte_eal/common/include/rte_lcore.h
> > > > > index 50e0d0f..7854ea1 100644
> > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > >  }
> > > > >
> > > > >  /**
> > > > > + * Test if an lcore is service lcore.
> > > > > + *
> > > > > + * @param lcore_id
> > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > + *   RTE_MAX_LCORE-1.
> > > > > + * @return
> > > > > + *   True if the given lcore is service; false otherwise.
> > > > > + */
> > > > > +static inline int
> > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > +{
> > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > +		return 0;
> > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > +}
> > > >
> > > > No header file and Static inline - so this is only to be used internally in the service
> > > cores library?
> > > > If so, the function should actually be used, instead of only added but not used in the
> > > library itself.
> > > >
> > >
> > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> > > a service lcore as well as an EAL thread some libraries such as rte_timer allow
> > > specific operations only over EAL threads.
> >
> > Understood that role of cores is important, and that rte_timer might require this
> information.
> >
> >
> > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> > > allow timers to be registered on a service core as processing those timers can
> > > be done on them.
> >
> > No problem from me here either - although it's the Timers library maintainer that should
> check this.
> >
> >
> > > This new function allows such libraries to check if the role is
> > > ROLE_SERVICE and allow those operations.
> >
> > If the timers library requires information about service-cores, it should use a public API
> to retrieve that information. Having "internal" functions between libraries is not nice.
> >
> > I think a better design would be to add this function as a public function, (add it to the
> .map files etc) and then call the public function from the timers library.
> >
> > Does that sound like a good solution? -Harry
> >
> 
> The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> file for eal/common and also other functions that are present in rte_lcore.h
> aren't mapped in eal/linuxapp or eal/bsdapp.
> I think it is fine as the functions are static inline.
> 
> -Pavan

OK - I was looking at this from a service core library POV. The intent seems to be to update EAL in order to allow detection of a core having a ROLE_SERVICE. Now I see your intent better, no problem with the approach. Correct that static-inline functions don't need .map file entries (cause they're inlined :)

One technical issue:
> +	if (lcore_id >= RTE_MAX_LCORE)
> +		return 0;

This should return a -ERROR value, as 0 is a valid return value that should indicate one thing (and one thing only) "not a service core".

Please spin a v2 and I'll Ack.

> 
> >
> > > Currently, the only rte_timer library has this specific role check. The
> > > following patch shows the usage in rte_timer library.
> > >
> > > http://dpdk.org/dev/patchwork/patch/27819/
> > >
> > > > Or am I mis-understanding the intent?
> > > >
> > > > -Harry
> > >
> > > Thanks,
> > > Pavan.
  

On Mon, Aug 28, 2017 at 03:24:06PM +0000, Van Haaren, Harry wrote:
>
>
> > -----Original Message-----
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > Sent: Monday, August 28, 2017 4:10 PM
> > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> >
> > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > > Sent: Monday, August 28, 2017 12:33 PM
> > > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > >
> > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > Sent: Wednesday, August 23, 2017 4:10 PM
> > > > > > To: dev@dpdk.org
> > > > > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > > > > > <pbhagavatula@caviumnetworks.com>
> > > > > > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > > > >
> > > > > > This API can be used to test if an lcore(EAL thread) is a service lcore.
> > > > > >
> > > > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > > > > ---
> > > > > >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> > > > > >  1 file changed, 18 insertions(+)
> > > > > >
> > > > > > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > index 50e0d0f..7854ea1 100644
> > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > >  }
> > > > > >
> > > > > >  /**
> > > > > > + * Test if an lcore is service lcore.
> > > > > > + *
> > > > > > + * @param lcore_id
> > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > + * @return
> > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > + */
> > > > > > +static inline int
> > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > +{
> > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > +		return 0;
> > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > +}
> > > > >
> > > > > No header file and Static inline - so this is only to be used internally in the service
> > > > cores library?
> > > > > If so, the function should actually be used, instead of only added but not used in the
> > > > library itself.
> > > > >
> > > >
> > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> > > > a service lcore as well as an EAL thread some libraries such as rte_timer allow
> > > > specific operations only over EAL threads.
> > >
> > > Understood that role of cores is important, and that rte_timer might require this
> > information.
> > >
> > >
> > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> > > > allow timers to be registered on a service core as processing those timers can
> > > > be done on them.
> > >
> > > No problem from me here either - although it's the Timers library maintainer that should
> > check this.
> > >
> > >
> > > > This new function allows such libraries to check if the role is
> > > > ROLE_SERVICE and allow those operations.
> > >
> > > If the timers library requires information about service-cores, it should use a public API
> > to retrieve that information. Having "internal" functions between libraries is not nice.
> > >
> > > I think a better design would be to add this function as a public function, (add it to the
> > .map files etc) and then call the public function from the timers library.
> > >
> > > Does that sound like a good solution? -Harry
> > >
> >
> > The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> > file for eal/common and also other functions that are present in rte_lcore.h
> > aren't mapped in eal/linuxapp or eal/bsdapp.
> > I think it is fine as the functions are static inline.
> >
> > -Pavan
>
> OK - I was looking at this from a service core library POV. The intent seems to be to update EAL in order to allow detection of a core having a ROLE_SERVICE. Now I see your intent better, no problem with the approach. Correct that static-inline functions don't need .map file entries (cause they're inlined :)
>
> One technical issue:
> > +	if (lcore_id >= RTE_MAX_LCORE)
> > +		return 0;
>
> This should return a -ERROR value, as 0 is a valid return value that should indicate one thing (and one thing only) "not a service core".

The function function follows the same structure as rte_lcore_is_enabled i.e.
returns either true(1) or false(0). So, I think returning 0 would be fine?. If
not I'll gladly send a v2.

Thanks for the inputs :). -Pavan.
>
> Please spin a v2 and I'll Ack.
>
> >
> > >
> > > > Currently, the only rte_timer library has this specific role check. The
> > > > following patch shows the usage in rte_timer library.
> > > >
> > > > http://dpdk.org/dev/patchwork/patch/27819/
> > > >
> > > > > Or am I mis-understanding the intent?
> > > > >
> > > > > -Harry
> > > >
> > > > Thanks,
> > > > Pavan.
  

> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Monday, August 28, 2017 4:43 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> 
> On Mon, Aug 28, 2017 at 03:24:06PM +0000, Van Haaren, Harry wrote:
> >
> >
> > > -----Original Message-----
> > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > Sent: Monday, August 28, 2017 4:10 PM
> > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > >
> > > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > > > Sent: Monday, August 28, 2017 12:33 PM
> > > > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > > > Cc: dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > > Sent: Wednesday, August 23, 2017 4:10 PM
> > > > > > > To: dev@dpdk.org
> > > > > > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > > > > > > <pbhagavatula@caviumnetworks.com>
> > > > > > > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > > > > >
> > > > > > > This API can be used to test if an lcore(EAL thread) is a service lcore.
> > > > > > >
> > > > > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > > > > > ---
> > > > > > >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> > > > > > >  1 file changed, 18 insertions(+)
> > > > > > >
> > > > > > > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > index 50e0d0f..7854ea1 100644
> > > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > > >  }
> > > > > > >
> > > > > > >  /**
> > > > > > > + * Test if an lcore is service lcore.
> > > > > > > + *
> > > > > > > + * @param lcore_id
> > > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > > + * @return
> > > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > > + */
> > > > > > > +static inline int
> > > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > > +{
> > > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > > +		return 0;
> > > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > > +}
> > > > > >
> > > > > > No header file and Static inline - so this is only to be used internally in the
> service
> > > > > cores library?
> > > > > > If so, the function should actually be used, instead of only added but not used in
> the
> > > > > library itself.
> > > > > >
> > > > >
> > > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> > > > > a service lcore as well as an EAL thread some libraries such as rte_timer allow
> > > > > specific operations only over EAL threads.
> > > >
> > > > Understood that role of cores is important, and that rte_timer might require this
> > > information.
> > > >
> > > >
> > > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> > > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> > > > > allow timers to be registered on a service core as processing those timers can
> > > > > be done on them.
> > > >
> > > > No problem from me here either - although it's the Timers library maintainer that should
> > > check this.
> > > >
> > > >
> > > > > This new function allows such libraries to check if the role is
> > > > > ROLE_SERVICE and allow those operations.
> > > >
> > > > If the timers library requires information about service-cores, it should use a public
> API
> > > to retrieve that information. Having "internal" functions between libraries is not nice.
> > > >
> > > > I think a better design would be to add this function as a public function, (add it to
> the
> > > .map files etc) and then call the public function from the timers library.
> > > >
> > > > Does that sound like a good solution? -Harry
> > > >
> > >
> > > The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> > > file for eal/common and also other functions that are present in rte_lcore.h
> > > aren't mapped in eal/linuxapp or eal/bsdapp.
> > > I think it is fine as the functions are static inline.
> > >
> > > -Pavan
> >
> > OK - I was looking at this from a service core library POV. The intent seems to be to update
> EAL in order to allow detection of a core having a ROLE_SERVICE. Now I see your intent better,
> no problem with the approach. Correct that static-inline functions don't need .map file
> entries (cause they're inlined :)
> >
> > One technical issue:
> > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > +		return 0;
> >
> > This should return a -ERROR value, as 0 is a valid return value that should indicate one
> thing (and one thing only) "not a service core".
> 
> The function function follows the same structure as rte_lcore_is_enabled i.e.
> returns either true(1) or false(0). So, I think returning 0 would be fine?. If
> not I'll gladly send a v2.

I looked that that function too - I'm not sure what's better API design...
Lets stay consistent with other functions in the file; so keep your current implementation.

Note that these service core patches depend on the Service Cores rework patchset (currently
v2 available here: http://dpdk.org/dev/patchwork/patch/27684/ )

@Pavan, if you have time to Ack the patches this one is based on that would be fantastic.

Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
  

On Tue, Aug 29, 2017 at 01:17:18PM +0000, Van Haaren, Harry wrote:
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > Sent: Monday, August 28, 2017 4:43 PM
> > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> >
> > On Mon, Aug 28, 2017 at 03:24:06PM +0000, Van Haaren, Harry wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > > Sent: Monday, August 28, 2017 4:10 PM
> > > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > >
> > > > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > > > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > Sent: Monday, August 28, 2017 12:33 PM
> > > > > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > > > > Cc: dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > > > >
> > > > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > > > Sent: Wednesday, August 23, 2017 4:10 PM
> > > > > > > > To: dev@dpdk.org
> > > > > > > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Pavan Nikhilesh
> > > > > > > > <pbhagavatula@caviumnetworks.com>
> > > > > > > > Subject: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore` API.
> > > > > > > >
> > > > > > > > This API can be used to test if an lcore(EAL thread) is a service lcore.
> > > > > > > >
> > > > > > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > > > > > > ---
> > > > > > > >  lib/librte_eal/common/include/rte_lcore.h | 18 ++++++++++++++++++
> > > > > > > >  1 file changed, 18 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > index 50e0d0f..7854ea1 100644
> > > > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > > > >  }
> > > > > > > >
> > > > > > > >  /**
> > > > > > > > + * Test if an lcore is service lcore.
> > > > > > > > + *
> > > > > > > > + * @param lcore_id
> > > > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > > > + * @return
> > > > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > > > + */
> > > > > > > > +static inline int
> > > > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > > > +{
> > > > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > > > +		return 0;
> > > > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > > > +}
> > > > > > >
> > > > > > > No header file and Static inline - so this is only to be used internally in the
> > service
> > > > > > cores library?
> > > > > > > If so, the function should actually be used, instead of only added but not used in
> > the
> > > > > > library itself.
> > > > > > >
> > > > > >
> > > > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> > > > > > a service lcore as well as an EAL thread some libraries such as rte_timer allow
> > > > > > specific operations only over EAL threads.
> > > > >
> > > > > Understood that role of cores is important, and that rte_timer might require this
> > > > information.
> > > > >
> > > > >
> > > > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> > > > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> > > > > > allow timers to be registered on a service core as processing those timers can
> > > > > > be done on them.
> > > > >
> > > > > No problem from me here either - although it's the Timers library maintainer that should
> > > > check this.
> > > > >
> > > > >
> > > > > > This new function allows such libraries to check if the role is
> > > > > > ROLE_SERVICE and allow those operations.
> > > > >
> > > > > If the timers library requires information about service-cores, it should use a public
> > API
> > > > to retrieve that information. Having "internal" functions between libraries is not nice.
> > > > >
> > > > > I think a better design would be to add this function as a public function, (add it to
> > the
> > > > .map files etc) and then call the public function from the timers library.
> > > > >
> > > > > Does that sound like a good solution? -Harry
> > > > >
> > > >
> > > > The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> > > > file for eal/common and also other functions that are present in rte_lcore.h
> > > > aren't mapped in eal/linuxapp or eal/bsdapp.
> > > > I think it is fine as the functions are static inline.
> > > >
> > > > -Pavan
> > >
> > > OK - I was looking at this from a service core library POV. The intent seems to be to update
> > EAL in order to allow detection of a core having a ROLE_SERVICE. Now I see your intent better,
> > no problem with the approach. Correct that static-inline functions don't need .map file
> > entries (cause they're inlined :)
> > >
> > > One technical issue:
> > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > +		return 0;
> > >
> > > This should return a -ERROR value, as 0 is a valid return value that should indicate one
> > thing (and one thing only) "not a service core".
> >
> > The function function follows the same structure as rte_lcore_is_enabled i.e.
> > returns either true(1) or false(0). So, I think returning 0 would be fine?. If
> > not I'll gladly send a v2.
>
> I looked that that function too - I'm not sure what's better API design...
> Lets stay consistent with other functions in the file; so keep your current implementation.
>
> Note that these service core patches depend on the Service Cores rework patchset (currently
> v2 available here: http://dpdk.org/dev/patchwork/patch/27684/ )
>
> @Pavan, if you have time to Ack the patches this one is based on that would be fantastic.

Sure Harry will go through the patch set.

>
> Acked-by: Harry van Haaren <harry.van.haaren@intel.com>

Thanks,
Pavan.
  

28/08/2017 17:09, Pavan Nikhilesh Bhagavatula:
> On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > >  }
> > > > >
> > > > >  /**
> > > > > + * Test if an lcore is service lcore.
> > > > > + *
> > > > > + * @param lcore_id
> > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > + *   RTE_MAX_LCORE-1.
> > > > > + * @return
> > > > > + *   True if the given lcore is service; false otherwise.
> > > > > + */
> > > > > +static inline int
> > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > +{
> > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > +		return 0;
> > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > +}
> > > >
> > > > No header file and Static inline - so this is only to be used internally in the service
> > > cores library?
> > > > If so, the function should actually be used, instead of only added but not used in the
> > > library itself.
> > > >
> > >
> > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular lcore is
> > > a service lcore as well as an EAL thread some libraries such as rte_timer allow
> > > specific operations only over EAL threads.
> >
> > Understood that role of cores is important, and that rte_timer might require this information.
> >
> >
> > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a lcore is an
> > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should also
> > > allow timers to be registered on a service core as processing those timers can
> > > be done on them.
> >
> > No problem from me here either - although it's the Timers library maintainer that should check this.
> >
> >
> > > This new function allows such libraries to check if the role is
> > > ROLE_SERVICE and allow those operations.
> >
> > If the timers library requires information about service-cores, it should use a public API to retrieve that information. Having "internal" functions between libraries is not nice.
> >
> > I think a better design would be to add this function as a public function, (add it to the .map files etc) and then call the public function from the timers library.
> >
> > Does that sound like a good solution? -Harry
> >
> 
> The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> file for eal/common and also other functions that are present in rte_lcore.h
> aren't mapped in eal/linuxapp or eal/bsdapp.
> I think it is fine as the functions are static inline.

We must avoid adding more inline functions without a good justification.
The inline functions are tolerated for performance reasons only.

We could also choose to add this function to rte_service.h ?
  

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, September 15, 2017 2:53 PM
> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@caviumnetworks.com>; Van Haaren,
> Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> API.
> 
> 28/08/2017 17:09, Pavan Nikhilesh Bhagavatula:
> > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > >  }
> > > > > >
> > > > > >  /**
> > > > > > + * Test if an lcore is service lcore.
> > > > > > + *
> > > > > > + * @param lcore_id
> > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > + * @return
> > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > + */
> > > > > > +static inline int
> > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > +{
> > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > +		return 0;
> > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > +}
> > > > >
> > > > > No header file and Static inline - so this is only to be used
> internally in the service
> > > > cores library?
> > > > > If so, the function should actually be used, instead of only added but
> not used in the
> > > > library itself.
> > > > >
> > > >
> > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular
> lcore is
> > > > a service lcore as well as an EAL thread some libraries such as rte_timer
> allow
> > > > specific operations only over EAL threads.
> > >
> > > Understood that role of cores is important, and that rte_timer might
> require this information.
> > >
> > >
> > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a
> lcore is an
> > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should
> also
> > > > allow timers to be registered on a service core as processing those
> timers can
> > > > be done on them.
> > >
> > > No problem from me here either - although it's the Timers library
> maintainer that should check this.
> > >
> > >
> > > > This new function allows such libraries to check if the role is
> > > > ROLE_SERVICE and allow those operations.
> > >
> > > If the timers library requires information about service-cores, it should
> use a public API to retrieve that information. Having "internal" functions
> between libraries is not nice.
> > >
> > > I think a better design would be to add this function as a public function,
> (add it to the .map files etc) and then call the public function from the
> timers library.
> > >
> > > Does that sound like a good solution? -Harry
> > >
> >
> > The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> > file for eal/common and also other functions that are present in rte_lcore.h
> > aren't mapped in eal/linuxapp or eal/bsdapp.
> > I think it is fine as the functions are static inline.
> 
> We must avoid adding more inline functions without a good justification.
> The inline functions are tolerated for performance reasons only.
> 
> We could also choose to add this function to rte_service.h ?

Yes that is an option, and OK with me.

@Pavan what do you think of adding it to service.h, implement in .c and add to .map?
  

On Fri, Sep 15, 2017 at 01:57:42PM +0000, Van Haaren, Harry wrote:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Friday, September 15, 2017 2:53 PM
> > To: Pavan Nikhilesh Bhagavatula <pbhagavatula@caviumnetworks.com>; Van Haaren,
> > Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> > API.
> >
> > 28/08/2017 17:09, Pavan Nikhilesh Bhagavatula:
> > > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > > >  }
> > > > > > >
> > > > > > >  /**
> > > > > > > + * Test if an lcore is service lcore.
> > > > > > > + *
> > > > > > > + * @param lcore_id
> > > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > > + * @return
> > > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > > + */
> > > > > > > +static inline int
> > > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > > +{
> > > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > > +		return 0;
> > > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > > +}
> > > > > >
> > > > > > No header file and Static inline - so this is only to be used
> > internally in the service
> > > > > cores library?
> > > > > > If so, the function should actually be used, instead of only added but
> > not used in the
> > > > > library itself.
> > > > > >
> > > > >
> > > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a particular
> > lcore is
> > > > > a service lcore as well as an EAL thread some libraries such as rte_timer
> > allow
> > > > > specific operations only over EAL threads.
> > > >
> > > > Understood that role of cores is important, and that rte_timer might
> > require this information.
> > > >
> > > >
> > > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a
> > lcore is an
> > > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it should
> > also
> > > > > allow timers to be registered on a service core as processing those
> > timers can
> > > > > be done on them.
> > > >
> > > > No problem from me here either - although it's the Timers library
> > maintainer that should check this.
> > > >
> > > >
> > > > > This new function allows such libraries to check if the role is
> > > > > ROLE_SERVICE and allow those operations.
> > > >
> > > > If the timers library requires information about service-cores, it should
> > use a public API to retrieve that information. Having "internal" functions
> > between libraries is not nice.
> > > >
> > > > I think a better design would be to add this function as a public function,
> > (add it to the .map files etc) and then call the public function from the
> > timers library.
> > > >
> > > > Does that sound like a good solution? -Harry
> > > >
> > >
> > > The file rte_lcore.h is in librte_eal/common/include I couldn't find a .map
> > > file for eal/common and also other functions that are present in rte_lcore.h
> > > aren't mapped in eal/linuxapp or eal/bsdapp.
> > > I think it is fine as the functions are static inline.
> >
> > We must avoid adding more inline functions without a good justification.
> > The inline functions are tolerated for performance reasons only.
> >
> > We could also choose to add this function to rte_service.h ?
>
> Yes that is an option, and OK with me.
>
> @Pavan what do you think of adding it to service.h, implement in .c and add to .map?
>

The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense to put
it in rte_lcore.h as lcore properties are accessed mostly through this header.
I'm fine with adding it to service.h as suggested by Harry.

-Pavan
  

> -----Original Message-----
> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Friday, September 15, 2017 3:42 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: thomas@monjalon.net; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> API.
> 
> On Fri, Sep 15, 2017 at 01:57:42PM +0000, Van Haaren, Harry wrote:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Friday, September 15, 2017 2:53 PM
> > > To: Pavan Nikhilesh Bhagavatula <pbhagavatula@caviumnetworks.com>; Van
> Haaren,
> > > Harry <harry.van.haaren@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> > > API.
> > >
> > > 28/08/2017 17:09, Pavan Nikhilesh Bhagavatula:
> > > > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > > > From: Pavan Nikhilesh Bhagavatula
> [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > > > >  }
> > > > > > > >
> > > > > > > >  /**
> > > > > > > > + * Test if an lcore is service lcore.
> > > > > > > > + *
> > > > > > > > + * @param lcore_id
> > > > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > > > + * @return
> > > > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > > > + */
> > > > > > > > +static inline int
> > > > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > > > +{
> > > > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > > > +		return 0;
> > > > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > > > +}
> > > > > > >
> > > > > > > No header file and Static inline - so this is only to be used
> > > internally in the service
> > > > > > cores library?
> > > > > > > If so, the function should actually be used, instead of only added
> but
> > > not used in the
> > > > > > library itself.
> > > > > > >
> > > > > >
> > > > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a
> particular
> > > lcore is
> > > > > > a service lcore as well as an EAL thread some libraries such as
> rte_timer
> > > allow
> > > > > > specific operations only over EAL threads.
> > > > >
> > > > > Understood that role of cores is important, and that rte_timer might
> > > require this information.
> > > > >
> > > > >
> > > > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a
> > > lcore is an
> > > > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it
> should
> > > also
> > > > > > allow timers to be registered on a service core as processing those
> > > timers can
> > > > > > be done on them.
> > > > >
> > > > > No problem from me here either - although it's the Timers library
> > > maintainer that should check this.
> > > > >
> > > > >
> > > > > > This new function allows such libraries to check if the role is
> > > > > > ROLE_SERVICE and allow those operations.
> > > > >
> > > > > If the timers library requires information about service-cores, it
> should
> > > use a public API to retrieve that information. Having "internal" functions
> > > between libraries is not nice.
> > > > >
> > > > > I think a better design would be to add this function as a public
> function,
> > > (add it to the .map files etc) and then call the public function from the
> > > timers library.
> > > > >
> > > > > Does that sound like a good solution? -Harry
> > > > >
> > > >
> > > > The file rte_lcore.h is in librte_eal/common/include I couldn't find a
> .map
> > > > file for eal/common and also other functions that are present in
> rte_lcore.h
> > > > aren't mapped in eal/linuxapp or eal/bsdapp.
> > > > I think it is fine as the functions are static inline.
> > >
> > > We must avoid adding more inline functions without a good justification.
> > > The inline functions are tolerated for performance reasons only.
> > >
> > > We could also choose to add this function to rte_service.h ?
> >
> > Yes that is an option, and OK with me.
> >
> > @Pavan what do you think of adding it to service.h, implement in .c and add
> to .map?
> >
> 
> The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense to put
> it in rte_lcore.h as lcore properties are accessed mostly through this header.
> I'm fine with adding it to service.h as suggested by Harry.
> 
> -Pavan

*as suggested by Thomas ;)

Initially I thought it made more sense in lcore.h too, however the application
should only require knowing if core X is a service core if it cares about
services / service-cores, hence I'm fine with rte_service.h too.

-Harry
  

On Fri, Sep 15, 2017 at 02:44:57PM +0000, Van Haaren, Harry wrote:
>
>
> > -----Original Message-----
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > Sent: Friday, September 15, 2017 3:42 PM
> > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Cc: thomas@monjalon.net; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> > API.
> >
> > On Fri, Sep 15, 2017 at 01:57:42PM +0000, Van Haaren, Harry wrote:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Friday, September 15, 2017 2:53 PM
> > > > To: Pavan Nikhilesh Bhagavatula <pbhagavatula@caviumnetworks.com>; Van
> > Haaren,
> > > > Harry <harry.van.haaren@intel.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> > > > API.
> > > >
> > > > 28/08/2017 17:09, Pavan Nikhilesh Bhagavatula:
> > > > > On Mon, Aug 28, 2017 at 01:49:37PM +0000, Van Haaren, Harry wrote:
> > > > > > From: Pavan Nikhilesh Bhagavatula
> > [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > > On Mon, Aug 28, 2017 at 10:59:51AM +0000, Van Haaren, Harry wrote:
> > > > > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > > > > > > > > --- a/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > > +++ b/lib/librte_eal/common/include/rte_lcore.h
> > > > > > > > > @@ -180,6 +180,24 @@ rte_lcore_is_enabled(unsigned lcore_id)
> > > > > > > > >  }
> > > > > > > > >
> > > > > > > > >  /**
> > > > > > > > > + * Test if an lcore is service lcore.
> > > > > > > > > + *
> > > > > > > > > + * @param lcore_id
> > > > > > > > > + *   The identifier of the lcore, which MUST be between 0 and
> > > > > > > > > + *   RTE_MAX_LCORE-1.
> > > > > > > > > + * @return
> > > > > > > > > + *   True if the given lcore is service; false otherwise.
> > > > > > > > > + */
> > > > > > > > > +static inline int
> > > > > > > > > +rte_lcore_is_service_lcore(unsigned lcore_id)
> > > > > > > > > +{
> > > > > > > > > +	struct rte_config *cfg = rte_eal_get_configuration();
> > > > > > > > > +	if (lcore_id >= RTE_MAX_LCORE)
> > > > > > > > > +		return 0;
> > > > > > > > > +	return cfg->lcore_role[lcore_id] == ROLE_SERVICE;
> > > > > > > > > +}
> > > > > > > >
> > > > > > > > No header file and Static inline - so this is only to be used
> > > > internally in the service
> > > > > > > cores library?
> > > > > > > > If so, the function should actually be used, instead of only added
> > but
> > > > not used in the
> > > > > > > library itself.
> > > > > > > >
> > > > > > >
> > > > > > > The enum rte_lcore_role_t has ROLE_SERVICE which tells that a
> > particular
> > > > lcore is
> > > > > > > a service lcore as well as an EAL thread some libraries such as
> > rte_timer
> > > > allow
> > > > > > > specific operations only over EAL threads.
> > > > > >
> > > > > > Understood that role of cores is important, and that rte_timer might
> > > > require this information.
> > > > > >
> > > > > >
> > > > > > > The rte_timer lib uses the rte_is_lcore_enabled() call to check if a
> > > > lcore is an
> > > > > > > EAL thread, Which checks if the lcore role is  ROLE_RTE. But it
> > should
> > > > also
> > > > > > > allow timers to be registered on a service core as processing those
> > > > timers can
> > > > > > > be done on them.
> > > > > >
> > > > > > No problem from me here either - although it's the Timers library
> > > > maintainer that should check this.
> > > > > >
> > > > > >
> > > > > > > This new function allows such libraries to check if the role is
> > > > > > > ROLE_SERVICE and allow those operations.
> > > > > >
> > > > > > If the timers library requires information about service-cores, it
> > should
> > > > use a public API to retrieve that information. Having "internal" functions
> > > > between libraries is not nice.
> > > > > >
> > > > > > I think a better design would be to add this function as a public
> > function,
> > > > (add it to the .map files etc) and then call the public function from the
> > > > timers library.
> > > > > >
> > > > > > Does that sound like a good solution? -Harry
> > > > > >
> > > > >
> > > > > The file rte_lcore.h is in librte_eal/common/include I couldn't find a
> > .map
> > > > > file for eal/common and also other functions that are present in
> > rte_lcore.h
> > > > > aren't mapped in eal/linuxapp or eal/bsdapp.
> > > > > I think it is fine as the functions are static inline.
> > > >
> > > > We must avoid adding more inline functions without a good justification.
> > > > The inline functions are tolerated for performance reasons only.
> > > >
> > > > We could also choose to add this function to rte_service.h ?
> > >
> > > Yes that is an option, and OK with me.
> > >
> > > @Pavan what do you think of adding it to service.h, implement in .c and add
> > to .map?
> > >
> >
> > The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense to put
> > it in rte_lcore.h as lcore properties are accessed mostly through this header.
> > I'm fine with adding it to service.h as suggested by Harry.
> >
> > -Pavan
>
> *as suggested by Thomas ;)
>
> Initially I thought it made more sense in lcore.h too, however the application
> should only require knowing if core X is a service core if it cares about
> services / service-cores, hence I'm fine with rte_service.h too.
>
> -Harry
>
Agreed, will spin up a v2.

Thanks,
Pavan
>
>
>
  

15/09/2017 16:59, Pavan Nikhilesh Bhagavatula:
> On Fri, Sep 15, 2017 at 02:44:57PM +0000, Van Haaren, Harry wrote:

> > > > > We could also choose to add this function to rte_service.h ?
> > > >
> > > > Yes that is an option, and OK with me.
> > > >
> > > > @Pavan what do you think of adding it to service.h, implement in .c and add
> > > to .map?
> > > >
> > >
> > > The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense to put
> > > it in rte_lcore.h as lcore properties are accessed mostly through this header.
> > > I'm fine with adding it to service.h as suggested by Harry.
> > >
> > > -Pavan
> >
> > *as suggested by Thomas ;)
> >
> > Initially I thought it made more sense in lcore.h too, however the application
> > should only require knowing if core X is a service core if it cares about
> > services / service-cores, hence I'm fine with rte_service.h too.
> >
> > -Harry
> >
> Agreed, will spin up a v2.

The most difficult is to find a good name for this function :)
  

On Fri, Sep 15, 2017 at 05:51:36PM +0200, Thomas Monjalon wrote:
> 15/09/2017 16:59, Pavan Nikhilesh Bhagavatula:
> > On Fri, Sep 15, 2017 at 02:44:57PM +0000, Van Haaren, Harry wrote:
>
> > > > > > We could also choose to add this function to rte_service.h ?
> > > > >
> > > > > Yes that is an option, and OK with me.
> > > > >
> > > > > @Pavan what do you think of adding it to service.h, implement in .c and add
> > > > to .map?
> > > > >
> > > >
> > > > The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense to put
> > > > it in rte_lcore.h as lcore properties are accessed mostly through this header.
> > > > I'm fine with adding it to service.h as suggested by Harry.
> > > >
> > > > -Pavan
> > >
> > > *as suggested by Thomas ;)
> > >
> > > Initially I thought it made more sense in lcore.h too, however the application
> > > should only require knowing if core X is a service core if it cares about
> > > services / service-cores, hence I'm fine with rte_service.h too.
> > >
> > > -Harry
> > >
> > Agreed, will spin up a v2.
>
> The most difficult is to find a good name for this function :)

If not rte_lcore_is_service_core then how about rte_lcore_is_role_service?
But this would need a sibling api rte_lcore_is_role_rte (or a better one) which
is satisfied by rte_lcore_is_enabled :(
IMO when role was limited to RTE & OFF rte_lcore_is_enabled fits now with
new role SERVICE it looks out of place cause even service lcores are
"enabled".
Modifying rte_lcore_is_enabled would be a huge task (API change) as it is used
widely in many places.

-Pavan
  

> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Friday, September 15, 2017 6:38 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: added new `rte_lcore_is_service_lcore`
> API.
> 
> On Fri, Sep 15, 2017 at 05:51:36PM +0200, Thomas Monjalon wrote:
> > 15/09/2017 16:59, Pavan Nikhilesh Bhagavatula:
> > > On Fri, Sep 15, 2017 at 02:44:57PM +0000, Van Haaren, Harry wrote:
> >
> > > > > > > We could also choose to add this function to rte_service.h ?
> > > > > >
> > > > > > Yes that is an option, and OK with me.
> > > > > >
> > > > > > @Pavan what do you think of adding it to service.h, implement in .c
> and add
> > > > > to .map?
> > > > > >
> > > > >
> > > > > The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense
> to put
> > > > > it in rte_lcore.h as lcore properties are accessed mostly through this
> header.
> > > > > I'm fine with adding it to service.h as suggested by Harry.
> > > > >
> > > > > -Pavan
> > > >
> > > > *as suggested by Thomas ;)
> > > >
> > > > Initially I thought it made more sense in lcore.h too, however the
> application
> > > > should only require knowing if core X is a service core if it cares about
> > > > services / service-cores, hence I'm fine with rte_service.h too.
> > > >
> > > > -Harry
> > > >
> > > Agreed, will spin up a v2.
> >
> > The most difficult is to find a good name for this function :)
> 
> If not rte_lcore_is_service_core then how about rte_lcore_is_role_service?
> But this would need a sibling api rte_lcore_is_role_rte (or a better one) which
> is satisfied by rte_lcore_is_enabled :(
> IMO when role was limited to RTE & OFF rte_lcore_is_enabled fits now with
> new role SERVICE it looks out of place cause even service lcores are
> "enabled".
> Modifying rte_lcore_is_enabled would be a huge task (API change) as it is used
> widely in many places.

Hey all,

I've been thinking a little, and adding the "is service core" functionality in the
rte_service_* namespace might be the wrong place. The function name certainly doesn't
roll off the tongue ( rte_service_lcore_has_service_role() ?? )

What if we add a new function to rte_lcore.h? The implementation could be in a
new file, rte_lcore.c, to avoid "static inline" in a control-path function.

In my eyes, this approach is the cleanest as it allows re-use of the same function
for various types, including SERVICE, RTE, OFF etc. 


/** Probes if the calling core has a specific role.
 * @retval 1 If the core has role matching the *role* passed in
 * @retval 0 If the core's role does not match *role* passed in
 */
int
rte_lcore_has_role(enum rte_lcore_role_t role);


Application code becomes pretty self-documenting:
if (rte_lcore_has_role(ROLE_SERVICE)) {
    // do something
}

Thoughts? -Harry
  

20/09/2017 16:53, Van Haaren, Harry:
> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > On Fri, Sep 15, 2017 at 05:51:36PM +0200, Thomas Monjalon wrote:
> > > 15/09/2017 16:59, Pavan Nikhilesh Bhagavatula:
> > > > On Fri, Sep 15, 2017 at 02:44:57PM +0000, Van Haaren, Harry wrote:
> > >
> > > > > > > > We could also choose to add this function to rte_service.h ?
> > > > > > >
> > > > > > > Yes that is an option, and OK with me.
> > > > > > >
> > > > > > > @Pavan what do you think of adding it to service.h, implement in .c
> > and add
> > > > > > to .map?
> > > > > > >
> > > > > >
> > > > > > The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense
> > to put
> > > > > > it in rte_lcore.h as lcore properties are accessed mostly through this
> > header.
> > > > > > I'm fine with adding it to service.h as suggested by Harry.
> > > > > >
> > > > > > -Pavan
> > > > >
> > > > > *as suggested by Thomas ;)
> > > > >
> > > > > Initially I thought it made more sense in lcore.h too, however the
> > application
> > > > > should only require knowing if core X is a service core if it cares about
> > > > > services / service-cores, hence I'm fine with rte_service.h too.
> > > > >
> > > > > -Harry
> > > > >
> > > > Agreed, will spin up a v2.
> > >
> > > The most difficult is to find a good name for this function :)
> > 
> > If not rte_lcore_is_service_core then how about rte_lcore_is_role_service?
> > But this would need a sibling api rte_lcore_is_role_rte (or a better one) which
> > is satisfied by rte_lcore_is_enabled :(
> > IMO when role was limited to RTE & OFF rte_lcore_is_enabled fits now with
> > new role SERVICE it looks out of place cause even service lcores are
> > "enabled".
> > Modifying rte_lcore_is_enabled would be a huge task (API change) as it is used
> > widely in many places.
> 
> Hey all,
> 
> I've been thinking a little, and adding the "is service core" functionality in the
> rte_service_* namespace might be the wrong place. The function name certainly doesn't
> roll off the tongue ( rte_service_lcore_has_service_role() ?? )
> 
> What if we add a new function to rte_lcore.h? The implementation could be in a
> new file, rte_lcore.c, to avoid "static inline" in a control-path function.
> 
> In my eyes, this approach is the cleanest as it allows re-use of the same function
> for various types, including SERVICE, RTE, OFF etc. 
> 
> 
> /** Probes if the calling core has a specific role.
>  * @retval 1 If the core has role matching the *role* passed in
>  * @retval 0 If the core's role does not match *role* passed in
>  */
> int
> rte_lcore_has_role(enum rte_lcore_role_t role);
> 
> 
> Application code becomes pretty self-documenting:
> if (rte_lcore_has_role(ROLE_SERVICE)) {
>     // do something
> }
> 
> Thoughts? -Harry

OK, no problem
  

On Wed, Sep 20, 2017 at 05:53:04PM +0200, Thomas Monjalon wrote:
> 20/09/2017 16:53, Van Haaren, Harry:
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com]
> > > On Fri, Sep 15, 2017 at 05:51:36PM +0200, Thomas Monjalon wrote:
> > > > 15/09/2017 16:59, Pavan Nikhilesh Bhagavatula:
> > > > > On Fri, Sep 15, 2017 at 02:44:57PM +0000, Van Haaren, Harry wrote:
> > > >
> > > > > > > > > We could also choose to add this function to rte_service.h ?
> > > > > > > >
> > > > > > > > Yes that is an option, and OK with me.
> > > > > > > >
> > > > > > > > @Pavan what do you think of adding it to service.h, implement in .c
> > > and add
> > > > > > > to .map?
> > > > > > > >
> > > > > > >
> > > > > > > The ROLE_SERVICE/ROLE_RTE defines the role of a lcore so it made sense
> > > to put
> > > > > > > it in rte_lcore.h as lcore properties are accessed mostly through this
> > > header.
> > > > > > > I'm fine with adding it to service.h as suggested by Harry.
> > > > > > >
> > > > > > > -Pavan
> > > > > >
> > > > > > *as suggested by Thomas ;)
> > > > > >
> > > > > > Initially I thought it made more sense in lcore.h too, however the
> > > application
> > > > > > should only require knowing if core X is a service core if it cares about
> > > > > > services / service-cores, hence I'm fine with rte_service.h too.
> > > > > >
> > > > > > -Harry
> > > > > >
> > > > > Agreed, will spin up a v2.
> > > >
> > > > The most difficult is to find a good name for this function :)
> > >
> > > If not rte_lcore_is_service_core then how about rte_lcore_is_role_service?
> > > But this would need a sibling api rte_lcore_is_role_rte (or a better one) which
> > > is satisfied by rte_lcore_is_enabled :(
> > > IMO when role was limited to RTE & OFF rte_lcore_is_enabled fits now with
> > > new role SERVICE it looks out of place cause even service lcores are
> > > "enabled".
> > > Modifying rte_lcore_is_enabled would be a huge task (API change) as it is used
> > > widely in many places.
> >
> > Hey all,
> >
> > I've been thinking a little, and adding the "is service core" functionality in the
> > rte_service_* namespace might be the wrong place. The function name certainly doesn't
> > roll off the tongue ( rte_service_lcore_has_service_role() ?? )
> >
> > What if we add a new function to rte_lcore.h? The implementation could be in a
> > new file, rte_lcore.c, to avoid "static inline" in a control-path function.
> >
> > In my eyes, this approach is the cleanest as it allows re-use of the same function
> > for various types, including SERVICE, RTE, OFF etc.
> >
> >
> > /** Probes if the calling core has a specific role.
> >  * @retval 1 If the core has role matching the *role* passed in
> >  * @retval 0 If the core's role does not match *role* passed in
> >  */
> > int
> > rte_lcore_has_role(enum rte_lcore_role_t role);
> >
> >
> > Application code becomes pretty self-documenting:
> > if (rte_lcore_has_role(ROLE_SERVICE)) {
> >     // do something
> > }
> >
> > Thoughts? -Harry
>
> OK, no problem
>
Thanks for all the inputs will spin up a v2.
-Pavan