From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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" To: "cunming.liang@intel.com" CC: "dev@dpdk.org" , "mhall@mhcomputing.net" , "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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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" To: Thomas Monjalon Cc: Matthew Hall , "dev@dpdk.org" Subject: Re: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_ex= it to shut down IRQ thread Date: Mon, 11 Jul 2016 04:07:29 +0000 Message-ID: (raw) In-Reply-To: <7816883.NtLY7W8fN8@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 > Cc: Matthew Hall ; 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. > > >