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

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

On 2020-07-15 18:21, Stephen Hemminger wrote:
> On Wed, 15 Jul 2020 10:17:09 +0000
> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>
>> 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
>>
> The issue is glibc doesn't want to allow gettid()
> there is no wrapper, the only way to get it is using syscall()


There was certainly a lot of reluctance to add it, but since glibc 2.30, 
there is a syscall wrapper in place.