> -----Original Message----- > From: Dmitry Kozlyuk <dmitry.kozl...@gmail.com> > Sent: Thursday, September 24, 2020 2:39 PM > To: Khoa To <k...@microsoft.com> > Cc: dev@dpdk.org; Narcisa Ana Maria Vasile > <navas...@linux.microsoft.com>; Dmitry Malloy (MESHCHANINOV) > <dmit...@microsoft.com>; Pallavi Kadam <pallavi.ka...@intel.com> > Subject: Re: [EXTERNAL] [dpdk-dev] [PATCH 2/2] eal/windows: implement > alarm API > > Hi Khoa, > > Disclaimer: my experience with interrupts and alarms is limited. > > > Since all alarm callbacks are scheduled on the interrupt thread, looks like > this implementation of rte_eal_alarm_set() would create a head-of-line > blocking issue, as the callbacks are serialized one after the other. > > Is that correct? If so, while this does not violate the API contract, it > > seems > undesirable. > > Yes, the issues is valid, however, probably irrelevant. In DPDK, alarms > are considered on par with interrupts. Much like kernel ISRs, DPDK interrupt > callbacks are supposed to be short. When they need to do more work, there > are > facilities to schedule deferred work (again, somewhat like NT kernel DPC): > rte_ctrl_thread_create().
Thank you for clarification on the usage model. > > I'm wondering why in both Linux and this Windows implementation, we > don't spawn a new thread to service each alarm independently. > > These threads would need cores to be scheduled on. If we set affinity to the > primary lcore, head-of-line issue is back. If we leave that to the OS, they > may land on data-plane cores with a context switch. > > > And, regardless of the Linux implementation, should we consider another > implementation that avoids the head-of-line blocking issue? > > I don't think so. Looking at PMD code, timers are mostly used during > initialization or reconfiguration. Sounds good. The implementation looks good. I'll take another pass at the code for any additional feedbacks.