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.