DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Khoa To <khot@microsoft.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
	"Dmitry Malloy (MESHCHANINOV)" <dmitrym@microsoft.com>,
	Pallavi Kadam <pallavi.kadam@intel.com>
Subject: Re: [dpdk-dev] [EXTERNAL] [PATCH 2/2] eal/windows: implement alarm API
Date: Fri, 25 Sep 2020 00:38:34 +0300	[thread overview]
Message-ID: <20200925003834.2266e7a2@sovereign> (raw)
In-Reply-To: <BY5PR21MB13800D678D3C04A81FAA1413D93A0@BY5PR21MB1380.namprd21.prod.outlook.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):

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

  reply	other threads:[~2020-09-24 21:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11  0:22 [dpdk-dev] [PATCH 0/2] eal/windows: implement alarms Dmitry Kozlyuk
2020-09-11  0:22 ` [dpdk-dev] [PATCH 1/2] eal/windows: add interrupt thread skeleton Dmitry Kozlyuk
2020-09-25  1:19   ` Narcisa Ana Maria Vasile
2020-09-25  6:28     ` Dmitry Kozlyuk
2020-09-11  0:22 ` [dpdk-dev] [PATCH 2/2] eal/windows: implement alarm API Dmitry Kozlyuk
2020-09-21 19:08   ` [dpdk-dev] [EXTERNAL] " Khoa To
2020-09-24 21:38     ` Dmitry Kozlyuk [this message]
2020-09-25  2:19       ` Khoa To
2020-09-25 23:32 ` [dpdk-dev] [PATCH v2 0/2] eal/windows: implement alarms Dmitry Kozlyuk
2020-09-25 23:32   ` [dpdk-dev] [PATCH v2 1/2] eal/windows: add interrupt thread skeleton Dmitry Kozlyuk
2020-09-25 23:40     ` Narcisa Ana Maria Vasile
2020-09-25 23:32   ` [dpdk-dev] [PATCH v2 2/2] eal/windows: implement alarm API Dmitry Kozlyuk
2020-09-25 23:41     ` Narcisa Ana Maria Vasile
2020-10-14 21:36       ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200925003834.2266e7a2@sovereign \
    --to=dmitry.kozliuk@gmail.com \
    --cc=dev@dpdk.org \
    --cc=dmitrym@microsoft.com \
    --cc=khot@microsoft.com \
    --cc=navasile@linux.microsoft.com \
    --cc=pallavi.kadam@intel.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).