From: Matthew Hall <mhall@mhcomputing.net>
To: dev@dpdk.org
Cc: thomas.monjalon@6wind.com, cunming.liang@intel.com
Subject: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread
Date: Thu, 17 Mar 2016 15:55:31 -0700 [thread overview]
Message-ID: <20160317225531.GA10279@mhcomputing.net> (raw)
In-Reply-To: <1455399524-3252-1-git-send-email-mhall@mhcomputing.net>
>From Cunming:
> I'm trying to understand the motivation.
>
> I don't think you're going to gracefully exit intr thread but leave all
> other eal threads live. We don't have API to new launch intr thread again.
The doc comment added for rte_eal_intr_exit already explains this. According
to the doc I wrote, use of the function is limited to shutting everything
down.
> So I guess your app is using own pthread(none EAL thread), you're trying to
> safely shutdown the whole application by your signal handler.
No, the app is using DPDK pthreads, and trying to shutdown everything safely
and cleanly w/ its signal handler, across DPDK and many other services in the
app.
Unfortunately, right now from my experience it is impossible to get everything to
cleanly shutdown, one an interrupt thread is activated. Because interrupt
threads violate violate POSIX semantics:
1) It ignores EINTR and immediately forcibly restarts a poll() syscall. If the
signal is delivered to the interrupt thread of the process by the kernel, this
makes the thread uninterruptible to process the signal. Stuck running forever.
2) It does not properly set PTHREAD_CREATE_DETACHED for a background thread.
So it holds the process open for its infinite loop of poll(). Stuck running
forever.
3) There is no way to access the thread_id from intr_thread. So then you can't
call pthread_cancel on it to shut it down. Stuck running forever.
> For this purpose, the device shall close safely(turn off intr) during the
> time, intr thread still wait but no event will be raised.
In theory yes. In practice no. Because the intr thread violated POSIX rules
for background processing threads per above.
> In this view, it seems not necessary to have this new. Can you explain more
> detail for the purpose?
Based on my testing, I disagree. I could not get reliable shutdowns without
this, or I wouldn't have coded it. (:
Matthew.
next prev parent reply other threads:[~2016-03-17 22:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-13 21:38 [dpdk-dev] [PATCH " Matthew Hall
2016-02-13 21:38 ` [dpdk-dev] [PATCH 2/3] eal_interrupts: mark EAL interrupt thread as a daemon thread Matthew Hall
2016-02-13 21:38 ` [dpdk-dev] [PATCH 3/3] rte_epoll_wait: allow EINTR to be passed to caller Matthew Hall
2016-02-28 21:17 ` [dpdk-dev] [PATCH 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread Thomas Monjalon
2016-03-08 15:09 ` Thomas Monjalon
2016-03-09 9:05 ` Liang, Cunming
2016-03-17 22:55 ` Matthew Hall [this message]
2016-03-21 7:58 ` [dpdk-dev] [dpdk-dev, " Liang, Cunming
2016-03-22 7:39 ` Matthew Hall
2016-03-23 3:24 ` Liang, Cunming
2016-07-08 17:36 ` Thomas Monjalon
2016-07-11 4:07 ` Liang, Cunming
2020-08-13 22:28 Bly, Mike
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160317225531.GA10279@mhcomputing.net \
--to=mhall@mhcomputing.net \
--cc=cunming.liang@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).