On Thu, 25 Apr 2024 13:40:21 +0800 (CST) 吴剑跃 <wujianyue...@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，"吴剑跃" <wujianyue...@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.
