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

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

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().

> 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.