[dpdk-dev] [EXTERNAL] [PATCH 2/2] eal/windows: implement alarm API

[Khoa To]

> -----Original Message-----
> From: Dmitry Kozlyuk <dmitry.kozliuk at gmail.com>
> Sent: Thursday, September 24, 2020 2:39 PM
> To: Khoa To <khot at microsoft.com>
> Cc: dev at dpdk.org; Narcisa Ana Maria Vasile
> <navasile at linux.microsoft.com>; Dmitry Malloy (MESHCHANINOV)
> <dmitrym at microsoft.com>; Pallavi Kadam <pallavi.kadam at 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.