[PATCH] eal/linux: enhanced error handling for affinity
Stephen Hemminger
stephen at networkplumber.org
Thu Apr 25 17:04:46 CEST 2024
On Thu, 25 Apr 2024 13:40:21 +0800 (CST)
吴剑跃 <wujianyue000 at 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 at 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.
More information about the dev
mailing list