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" <step...@networkplumber.org> wrote: >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.
