On Wed, 18 Sep 2024 13:39:06 +0200 Wojciech Panfil <wojciech.pan...@intel.com> wrote:
> Issue: > Two threads: > > - A, executing rte_eal_alarm_cancel, > - B, executing eal_alarm_callback. > > Such case can cause starvation of thread B. Please see that there is a > small time window between lock and unlock in thread A, so thread B must > be switched to within a very small time window, so that it can obtain > the lock. > > Solution to this problem is use sched_yield(), which puts current thread > (A) at the end of thread execution priority queue and allows thread B to > execute. > > The issue can be observed e.g. on hot-pluggable device detach path. > On such path, rte_alarm can used to check if DPDK has completed > the detachment. Waiting for completion, rte_eal_alarm_cancel > is called, while another thread periodically calls eal_alarm_callback > causing the issue to occur. > > Signed-off-by: Wojciech Panfil <wojciech.pan...@intel.com> Make sense. Alarm is non-EAL thread, and so is hotplug. Acked-by: Stephen Hemminger <step...@networkplumber.org> Does the timer_stop code have similar issues? Probably only if users do unexpected things like map multiple logical lcores to same CPU.
