Re:Re: [PATCH] eal/linux: enhanced error handling for affinity

["Jianyue Wu" <wujianyue000@163.com>]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

Hello, Stephen,




Understand, yesterday I had added new changes to the patch, how to recall that patch?

Thank you~














At 2024-04-25 23:04:46, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>On Thu, 25 Apr 2024 13:40:21 +0800 (CST)
>吴剑跃 <wujianyue000@163.com> wrote:
>
>> After reviewing the code, I believe that the combination of the __linux__ and _GNU_SOURCE macros effectively confirms whether the pthread_getname_np() API can be utilized. I will proceed with adding them. Thank you~
>> #if defined(__linux__) && defined(_GNU_SOURCE)
>> 
>> 
>> 在 2024-04-25 09:08:59，"吴剑跃" <wujianyue000@163.com> 写道：
>> 
>> Hello, Stephen,
>> 
>> 
>> 
>> Good day
>> The issue is not caused by DPDK itself, but arises when the DPDK worker process attempts to set affinity to a cpuset that exceeds the limits set by the cgroup cpuset settings.
>> Original error prints are:
>>      PANIC in rte_eal_init():
>>      Cannot set affinity
>>      # Callstacks.
>> 
>> 
>> Finding the detailed reason for the failure was challenging, so I added extra print statements to help diagnose the issue.
>> I understand your concern about maintaining OS independence with the rte_thread functions. This change aims to provide more context when errors occur, facilitating quicker troubleshooting. I agree that this introduces more code and could be seen as platform-specific. Perhaps we could implement this conditionally, only for platforms where such detailed logging is supported and useful.
>> 
>
>My point is that just giving the kernel error should be sufficient, rather than having
>to reformat the incoming arguments. The arguments are coming from the command line, and what I
>would do is look at the error and the command line arguments to the application, as well as
>any kernel logs.

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]