From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id 93C5F2C00 for ; Thu, 17 Mar 2016 23:55:31 +0100 (CET) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 24DB9C8; Thu, 17 Mar 2016 15:55:31 -0700 (PDT) Date: Thu, 17 Mar 2016 15:55:31 -0700 From: Matthew Hall To: dev@dpdk.org Cc: thomas.monjalon@6wind.com, cunming.liang@intel.com Message-ID: <20160317225531.GA10279@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1455399524-3252-1-git-send-email-mhall@mhcomputing.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 22:55:31 -0000 >>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.