Re: [dpdk-dev] Retrieving lcore worker thread id

["Mattias Rönnblom" <mattias.ronnblom@ericsson.com>]

On 2020-07-14 22:51, Stephen Hemminger wrote:
> On Tue, 14 Jul 2020 18:59:59 +0000
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
>
>> <snip>
>>
>>>> Hi.
>>> Hey,
>>>    
>>>> In DPDK 19.11, the lcore_config struct of <rte_lcore.h> is made
>>>> private, and with it the possibility to look up the thread id of the
>>>> lcore worker threads disappears.
>>>>
>>>> One use case is an application with a monitoring function (on some
>>>> control plane thread), which uses the thread ids to make sure the
>>>> worker threads gets the CPU runtime they should, and thus is able to
>>>> detect stalls.
>> This sounds similar to 'keep alive' functionality.
>>
>>>> Is there some other way of finding out the thread_id of a lcore worker
>>>> thread? All I can think of are hacks like using a temporary service
>>>> function for service cores, in combination with requiring launched
>>>> application threads also to store their thread id in some global
>>>> structure (index by lcore_id).
>>> -1 for the service cores idea. I like the creative solution thinking, but not as a
>>> long-term solution.
>>>    
>>>> Is there some cleaner way? If not, would adding something like a
>>>> rte_lcore_thread_id() function make sense?
>> I guess here you mean the OS provided thread ID. Are there OS calls that provide the CPU runtime?
> This might be difficult sinc thread id in Linux/glibc is intentionally and opaque value.
> According to Posix the only valid way to look at it is to use return value from
> pthread_create() and pthread_self().
>

The rte_lcore_thread_id() would return this value, which could 
subsequently be used in the application, calling pthread_getcpuclockid() 
and clock_gettime() to retrieve the run time for the lcore worker 
thread. No need to break the opacity in this case, although the Linux 
thread id (i.e. the result of a gettid()) would be useful in case you 
would want to dig around in /proc for other scheduler statistics.


Regards,

     Mattias