From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id CF73DA04B1;
	Fri, 14 Aug 2020 00:29:05 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id F28D61C0C4;
	Fri, 14 Aug 2020 00:29:04 +0200 (CEST)
Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com
 [67.231.144.234]) by dpdk.org (Postfix) with ESMTP id DEFA11C0BC
 for <dev@dpdk.org>; Fri, 14 Aug 2020 00:29:02 +0200 (CEST)
Received: from pps.filterd (m0174892.ppops.net [127.0.0.1])
 by mx0a-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id
 07DMKic8021617; Thu, 13 Aug 2020 18:29:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com;
 h=from : to : cc :
 subject : date : message-id : content-type : mime-version; s=06252019;
 bh=NY/wBrBGMu6AtsuSWvMFgV/9HQq2N/4XFAXmN2EFbNM=;
 b=Ak0k9zQJQJorZ5G8bnczkXi+aqWxEP5XxKNa0gtl73lNOc+J6LfnUXqkJdspOBjrTScR
 E8RKANe6y8jXoqET/yB+vcs8Wg3inyrQIPSNJwfs+O0uDNRyPsBQs6KTOQVYf1+6f3dz
 x/4bMtawuyS8QzBJq4Ej01m0CU5Io3uc8dMy8RauxAVmWCREv4IaKF0cAeX/pWQyKWU7
 QEZU9Aii11OTl/aLz83xHbi2DYkGyOBldHRCip900EWWoJR4YYyIbwEdw+SwTn9pNdtn
 OgayTzEprB+z/bjwRcm2vmywTLKdG4387H6eXhbQlcNHimHkyZwZaw/z52lg6xRUNyNW SA== 
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177])
 by mx0a-00103a01.pphosted.com with ESMTP id 32uy09kq0f-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 13 Aug 2020 18:29:01 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=RwDFwALt0pAlGSvAcc3uL6k2bedmkOReXXREBdhnB99PMjFAAA40lOnzgh0Wu2moyAL0ICHaDAR0PG1de51AKKYOjoeLf0CY04kUbgPt9dl9O3q2jz1ICHxnxtyzgGGpmojU52CmmBsEhnx+yPVMFBGV7dZll9k1l2qFObyevcn/rupUkXF8en1kvyWj8wxmdxozIS8Mi2HJ1EFENGM/SJmLOzXxDNaqu8yMVbMDe/gOMsxctntGrY8mGXVH2Xl4+hBBJMYkGM6p7HNeYeVLexbN+a+rsGwTF7F3dxPkRJzeA8NExJOPyX+bRkxCix9ZeiOvzLaXzVk4Wl7b/Y712g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NY/wBrBGMu6AtsuSWvMFgV/9HQq2N/4XFAXmN2EFbNM=;
 b=JI5wV2zQrgBGsG38MawtE6+VddHqZJHUy4CeSKOZSwNGgG1X5Iu8TUDNHY3cBL9fmLZtE/v+MJg2Pz3cb5TlnONKUm9Pru4y+bR74lO05xnm+zj3MVD+U9r3J6iVIFdWBjsHsUZISFXgnsBuSR1I8KlK7VdgHhDOOD2mLt9gEgLGssvobdbGrSnezdNXNkVquzRWyyKRp4SzgD5XP2a/BUhDxU6OSQ+BAvUF+b5Us1//fIQJZJXLATINmsJpeijfFbmpleCTITztV2Zk7CuBiMdUgpDs/IjiEfV0G83oaD4ZX0ViTEKUuGRbaB1qrJzgy7zwRRnhyIv/8xceosA0nw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com;
 dkim=pass header.d=ciena.com; arc=none
Received: from BL0PR04MB4706.namprd04.prod.outlook.com (2603:10b6:208:49::32)
 by BL0PR04MB4482.namprd04.prod.outlook.com (2603:10b6:208:45::31)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Thu, 13 Aug
 2020 22:28:58 +0000
Received: from BL0PR04MB4706.namprd04.prod.outlook.com
 ([fe80::dd16:4e9d:fd1b:1c24]) by BL0PR04MB4706.namprd04.prod.outlook.com
 ([fe80::dd16:4e9d:fd1b:1c24%4]) with mapi id 15.20.3283.015; Thu, 13 Aug 2020
 22:28:58 +0000
From: "Bly, Mike" <mbly@ciena.com>
To: "cunming.liang@intel.com" <cunming.liang@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "mhall@mhcomputing.net"
 <mhall@mhcomputing.net>, "thomas.monjalon@6wind.com"
 <thomas.monjalon@6wind.com>
Thread-Topic: Re: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add
 rte_eal_intr_exit to shut down IRQ thread
Thread-Index: AdZwD5G6iLKM92bJTuafMDeylvhnEw==
Date: Thu, 13 Aug 2020 22:28:58 +0000
Message-ID: <BL0PR04MB4706163D187F36F5D780193FCF430@BL0PR04MB4706.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: intel.com; dkim=none (message not signed)
 header.d=none;intel.com; dmarc=none action=none header.from=ciena.com;
x-originating-ip: [165.225.50.166]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 30aabbf4-271f-4e84-01ac-08d83fd84571
x-ms-traffictypediagnostic: BL0PR04MB4482:
x-microsoft-antispam-prvs: <BL0PR04MB4482BE1986F7BE3EF8B8B31ECF430@BL0PR04MB4482.namprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IuRfaA1MiFXfcvk8EoDNF/AcV5NNGR2na4sbWilv5y4hbSOE6JUJjKwOcQaQs/4uHzmRVBqw5LlwRroXgCffx8P21HyOOBeDMugNZEGzJTpkgg8b6dOw5VlcOGRG7VEdjVeD8fg4koNJXxlZDNo4qlHcYlEB7mEGLYAL+WJqdjQk/RNA3zRwXRMyFp7uBncu/P60T2yzuiCP/CXRu5eLqsffN0sVJuabfkOjbvFXixYKllXJFAb/x3o6uFPiwOaHro4H0j2JUJi5HlNs3yDhpqnzh6ttLW0ATc/Qp9jVzeeRbnfwZFU9YZd9Ivh5xjybCqXfnNpIMwc4b6SVo6V7oHGUpTQnqQdN2Rm3mMvPiGfOHFs3jubXkPNyVe2AhAge3j1uAOkXti+Xw8hM5K6SRw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:BL0PR04MB4706.namprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(366004)(39860400002)(346002)(136003)(376002)(396003)(53546011)(166002)(71200400001)(6506007)(55236004)(66946007)(66476007)(66446008)(64756008)(7066003)(66556008)(26005)(55016002)(2906002)(5660300002)(8936002)(52536014)(186003)(83380400001)(9686003)(33656002)(6916009)(54906003)(7696005)(4326008)(478600001)(76116006)(8676002)(316002)(86362001);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: BOGTBC8vYcjFpFBpsetv3ygkv+EB+bD7NRXvLdsGHEqV4dObVefZ35qProF+OPyhxLEa/g/+R+5VIGd7KJdjWfkDcjPzeOQGLVRg9IwG/lw3p5EbQ20Z9o9195FhF+BQVVwmBBIPt1VkBk3QC5VP5BQ6MhwqeygVqFCY/jc7Kxz81EjlaO4M8hGQ+lQMIVHrIPJ2BS41mchl2qcL88JI060nC1iN4FBav4NMWrXJGJjER+81M0MrMvj7bOqEqj/E8v+TZe53G73IN9el5mKymGGpI3TZt6vz3hCVDv1dRcPTVNArsyVGr80n9AfNQB+J4evAnO0zkCT+pNYZIaub7+3QOjQIpLuTG6eBbCt/djVnjzpsiaiKBaTRazDS6Ba4Tx1bDHBvnc12joqZrUu/yNn6KXKOVZ2ZAJkEpDu++PdAbMrIQmDRbzkwQjCizgNxCXj48UYJBcTYnbsMmu80M247bnx6VSGp4U1jGc7TuZQ3LU1JJszESvtU4EYRNPAAUh0RKg8kiykbvOun1heGezz1i/B7RPl09kHq5Sk5dwcebZUQ2yjmv7mEr1asONVCxMzxr6SKiiB0Df8nLmy4QXWI3LhFCY1BF6hapW/1r5UkfOiiHvfdgGiST6/T8TrcwS64cmHs500EEvwS9lnm6Q==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: ciena.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR04MB4706.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30aabbf4-271f-4e84-01ac-08d83fd84571
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 22:28:58.1895 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iNl7HYvNURe+p1xGIat7PzYwZ1vgBlE6fgfVl5BKsrkfXCXwcrogfUuexbtMkLQP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR04MB4482
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687
 definitions=2020-08-13_17:2020-08-13,
 2020-08-13 signatures=0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [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: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Has anyone created a dev-ticket to run this discussion to ground? I see bel=
ow thread went stale in 2016...



Is there a "better approach" to integrating rte_eal_intr_exit() support/con=
cepts into our applications?



-Mike



From: "Liang, Cunming" <cunming.liang@intel.com>

To: Thomas Monjalon <thomas.monjalon@6wind.com>

Cc: Matthew Hall <mhall@mhcomputing.net>, "dev@dpdk.org" <dev@dpdk.org>

Subject: Re: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_ex=
it to shut down IRQ thread<http://inbox.dpdk.org/dev/D0158A423229094DA7ABF7=
1CF2FA0DA31554689D@shsmsx102.ccr.corp.intel.com/#r>

Date: Mon, 11 Jul 2016 04:07:29 +0000

Message-ID: <D0158A423229094DA7ABF71CF2FA0DA31554689D@shsmsx102.ccr.corp.in=
tel.com> (raw<http://inbox.dpdk.org/dev/D0158A423229094DA7ABF71CF2FA0DA3155=
4689D@shsmsx102.ccr.corp.intel.com/raw>)

In-Reply-To: <7816883.NtLY7W8fN8@xps13<http://inbox.dpdk.org/dev/7816883.Nt=
LY7W8fN8@xps13/>>



Hi Thomas,



Base on the previous conversation, at least it requires v2 to reword some c=
omments.



> > >> 2. I propose to add addition comments on rte_epoll_wait() API

> > >> description. For any signal, it causes an error return, user needs

> > >> to handle.

> > > Agreed.



In addition, one conversion is not close.



> > >> the default termination handler

> > > I am not so experienced with this "default termination handler". Can

> someone

> > > clarify what it is so I could comment better about it?

> > For example, you're handling SIGINT. After finishing your necessary app

> > cleanup, then 'signal(SIGINT, SIG_DFL); raise(SIGINT);'.

> > The default signal handler can terminate the interrupt thread.



> > >> 1. Can you explain and add patch comments why default signal handler

> > >> is not good enough to terminate app.

> > > Yes if someone call tell me more about what it is so I can check it.



Thanks,

Cunming



> -----Original Message-----

> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]

> Sent: Saturday, July 09, 2016 1:36 AM

> To: Liang, Cunming <cunming.liang@intel.com>

> Cc: Matthew Hall <mhall@mhcomputing.net>; dev@dpdk.org

> Subject: Re: [dpdk-dev,1/3] rte_interrupts: add rte_eal_intr_exit to shut=
 down

> IRQ thread

>

> Cunming, what is the status of this patchset, please?

>

> 2016-03-23 11:24, Liang, Cunming:

> > Hi Mattew,

> >

> > Thank you for your time.

> >

> > On 3/22/2016 3:39 PM, Matthew Hall wrote:

> > > On Mon, Mar 21, 2016 at 03:58:44PM +0800, Liang, Cunming wrote:

> > >> the default termination handler

> > > I am not so experienced with this "default termination handler". Can

> someone

> > > clarify what it is so I could comment better about it?

> > For example, you're handling SIGINT. After finishing your necessary app

> > cleanup, then 'signal(SIGINT, SIG_DFL); raise(SIGINT);'.

> > The default signal handler can terminate the interrupt thread.

> >

> > >

> > >> If EINTR is caused by some non-term purpose signals, are you going

> > >> to exit the interrupt thread any way?

> > > We should discuss what makes sense here. I'm just trying to get some =
things

> > > working and finding EINTR was getting eaten and causing infinite loop=
ing.

> > SIGINT/SIGTERM causes EINTR return, while SIGUSR1 also can cause the

> > EINTR return. For the dedicated EAL interrupt thread, it won't be

> > expected to exit for all kinds of the cause.

> > On this view, I'm in favor of your patch which cancel the interrupt

> > thread, but don't directly return by the EINTR.

> >

> > >

> > >> Without setting 'PTHREAD_CREATE_DETACHED' won't cause the infinite

> > >> loop. However by using pthread_cancel to terminate the thread,

> > >> indeed it's necessary to set 'PTHREAD_CREATE_DETACHED'.

> > > My general understanding is that PTHREAD_CREATE_DETACHED should be

> used for

> > > any thread, which should not keep a process open by itself if it is e=
xecuting,

> > > i.e. a "daemon thread". I believe the interrupt thread qualifies as s=
uch a

> > > thread if I have understood everything right (which is hard to promis=
e when

> > > you only work in DPDK in spare time).

> > >

> > >> It looks like 'pthread_cancel' is the right way and I saw it

> > >> continue keeps current EINTR handling in EAL interrupt thread.

> > > It is one option. Depending what makes the most sense.

> > >

> > >> 1. Can you explain and add patch comments why default signal handler

> > >> is not good enough to terminate app.

> > > Yes if someone call tell me more about what it is so I can check it.

> > >

> > >> 2. I propose to add addition comments on rte_epoll_wait() API

> > >> description. For any signal, it causes an error return, user needs

> > >> to handle.

> > > Agreed.

> > >

> > >> 3. Will you do a favorite to add 'PTHREAD_CREATE_DETACHED' to all

> > >> EAL pthread too.

> > > As a spare time developer I am a bit conservative about too large of =
a scope

> > > and messing with code for other threads or features I didn't personal=
ly use or

> > > test. This is because I don't have the same QA resources as Intel / 6=
WIND /

> > > etc.. Some help from a full time developer would be great here.

> > All right, reasonable to me.

> >

> > >

> > >> Cunming

> > > Matthew.

> >

>