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 43FAAA0471 for ; Wed, 17 Jul 2019 17:06:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A1081BE0D; Wed, 17 Jul 2019 17:06:15 +0200 (CEST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by dpdk.org (Postfix) with ESMTP id 8C9C61BDF6 for ; Wed, 17 Jul 2019 17:06:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4226; q=dns/txt; s=iport; t=1563375973; x=1564585573; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TB5vguXF5qcDjj78fLfKNj6UECrnyp2jq+I4SVzimTQ=; b=d+apEF3pRKagtu95FytbiovklSmQZI1YFPwvKdaKlC4IfkYV8GnFHC8X v1QqUgcN8CRZ+bSsB5zBwSUAK9beAQ9peDbRkUMpHJWRKjbrdtOA0agv2 R+8yJwX5rWF2oaFNlcMXC3EOlMuXcHT6IHAlBvt/e5NLGL96LpFGCzteI I=; IronPort-PHdr: =?us-ascii?q?9a23=3ARDo+uBQJGadsefZhLwbBWwGlRtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiwrG8JBVVpN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAAAbOS9d/4MNJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYFDKScDgUIgBAsqh2MDhFKJKUyCD36WUoEugSQDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACgkgjNAkOAQMBAQQBAQIBBW2FPAyFSgEBAQEDEigGAQE?= =?us-ascii?q?3AQsEAgEIEQQBAR8QMh0IAgQOBQgagjWCNgMdAaETAoE4iGCCI4J5AQEFhRI?= =?us-ascii?q?YghMJgTQBi14XgUA/gRABRoIXNT6ERiSDF4ImjAIggiecHgkCghmUJ4IthyW?= =?us-ascii?q?OOKUFAgQCBAUCDgEBBYFQOIFYcBWDJ4JBg3GKU3KBKY1HAQE?= X-IronPort-AV: E=Sophos;i="5.64,274,1559520000"; d="scan'208";a="298468782" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2019 15:05:51 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6HF5p6K031689 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2019 15:05:51 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 10:05:50 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 11:05:49 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 17 Jul 2019 11:05:49 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z+KctEht18PJxc+rxVmuOq6cVG9NJ/+mURTpkhfiDO0HtSbceMEB/qWAvxmHdBHVtuUfc/drzt7wWjeYlZrK6SbH91+D+ZQOWtWl2pHc0kfgwc06/W46DXjTWNYHJkKkoy5sosx7Ez4gXP+A77uLMgE4vSxYO+r7cJ3lZiMrAbFdnN29521sij/wbfht/CE5DcXr+FXD3QFdHxYnmkhr5cubPot5MHUOcC1UWBRckNRbhR/fnmUhrUcVXi1vS2/gqTPxhjh3WDHXXKsE+heg3H9JYjtd+v+Df+VY9TJoVndguMF/jnzSGxl8c8F0VzBC33zEnMckaoMbKG+76OLU5g== 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=rorH7RhqLJqX6DhRwOO/LgLafqUn1nGKR+uQv98rP8I=; b=SPlhMYi91LglVuIQ//IETSrfRJmNXPlIBdiOmgJZxEA1ZsfXQS50TPTNz5CSYTUgMu+s9poCcp8VhBsNG5L7zt11JPkDN0CQ2prUh47a0cGFLMVrnQ0yYVx4dg0pOCi6OIlZsddyFvwK6bApUGs9UCE9p0/Jv5K9XceHBVbV59xdqUHh4uPLyinzLrCtrSP1YsoL5oBKIKYxbJXeMGR7SklFeqPwwRtjl4pZi89MU9s+3HbQ5Hd8YgzL1XEbbGfmTRAPibxoHjS+bvJ4HKORdTRScaZiUyC9lbSKUWuNQLki7Or7VEMvHAf9cSgfp5/3aUNO2/fcAQiBKQrY9ItgxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rorH7RhqLJqX6DhRwOO/LgLafqUn1nGKR+uQv98rP8I=; b=VEzLRx/FR32dmhGOcRNSEHxHAN3xYVtVf6Enl8BqAMx4qmsBnbw1Ti/aiAgbNqXckIJPJkn191aAEK/cHRVtmJ3CcPH8ZSEWUVLr6KNju1NZHP64x+lyKbkU0Yb9Bc39sNKox4fI4j/mqtiZBirMtmcR2wsFf7ubrhEaFlhd5C0= Received: from MWHPR11MB1839.namprd11.prod.outlook.com (10.175.53.12) by MWHPR11MB1375.namprd11.prod.outlook.com (10.169.233.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 17 Jul 2019 15:05:48 +0000 Received: from MWHPR11MB1839.namprd11.prod.outlook.com ([fe80::3cef:35b5:8800:39f1]) by MWHPR11MB1839.namprd11.prod.outlook.com ([fe80::3cef:35b5:8800:39f1%6]) with mapi id 15.20.2094.011; Wed, 17 Jul 2019 15:05:48 +0000 From: "Hyong Youb Kim (hyonkim)" To: Nithin Kumar Dabilpuram CC: David Marchand , Thomas Monjalon , Ferruh Yigit , "Bruce Richardson" , Jerin Jacob Kollanukkaran , "John Daley (johndale)" , "Shahed Shaikh" , "dev@dpdk.org" Thread-Topic: [EXT] Re: [dpdk-dev] [PATCH v2 2/3] eal: add ack interrupt API Thread-Index: AQHVPJ1awKwl6iv5TE2qTW+wXmFZCabOwnIggAAeGoCAAARLAA== Date: Wed, 17 Jul 2019 15:05:47 +0000 Message-ID: References: <20190717115852.171416-1-ndabilpuram@marvell.com> <20190717124354.142668-1-ndabilpuram@marvell.com> <20190717124354.142668-3-ndabilpuram@marvell.com> <20190717143513.GA5114@outlook.office365.com> In-Reply-To: <20190717143513.GA5114@outlook.office365.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hyonkim@cisco.com; x-originating-ip: [2001:420:c0dc:1001::133] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b5b680e-56fe-4d1f-5a4b-08d70ac84022 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR11MB1375; x-ms-traffictypediagnostic: MWHPR11MB1375: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(376002)(366004)(13464003)(189003)(199004)(446003)(9686003)(46003)(76176011)(71190400001)(71200400001)(486006)(55016002)(6916009)(186003)(305945005)(6246003)(7736002)(2906002)(53936002)(54906003)(11346002)(25786009)(476003)(6116002)(102836004)(478600001)(6506007)(316002)(33656002)(66446008)(86362001)(66946007)(8676002)(99286004)(74316002)(14454004)(229853002)(14444005)(256004)(52536014)(5660300002)(81166006)(81156014)(68736007)(8936002)(6436002)(4326008)(7696005)(66476007)(66556008)(76116006)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1375; H:MWHPR11MB1839.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: o3Iz9Iz1rW+O2p7cEntmM0OXiCD2WUCcCgCdJ9xLDSK3XlzeL8RkGnxaxhFVh85nsbDi1CLyz/XyOUnAnOginDZO7UsvsKsLSqK6ZLSzGMJuxzABvwiyqfvxA3VMcinusCRs26zZQr+7I2wMMu85mw0/lrgN4rI7mCF7c9W7g0nDo4Oka4SLho+boTr3UMHnoOIdg0uJogzunUqhpUdyylbC3JlR8F44wKJacxGmUxYThx/t9HJKuWGW1kFzqcTD4PDW51YfDpJA6V1e9fVOuRbwR6yMAz7Xd5POH8XXbGmrn2pe723vPdkB9HxNScz96mcVehpy4Sub0iwl3EvMOcngKOflSxxsB7q8sJuJQArO32bg8xpUvTZ3zqM6DfiePczsCTYI4BzI6US6CkpdLNOnRAC8h1Id8uaY4Lgfjh0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6b5b680e-56fe-4d1f-5a4b-08d70ac84022 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 15:05:48.0363 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hyonkim@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1375 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-1.cisco.com Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 2/3] eal: add ack interrupt API 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" > -----Original Message----- > From: Nithin Kumar Dabilpuram > Sent: Wednesday, July 17, 2019 11:36 PM [...] > > > Subject: [PATCH v2 2/3] eal: add ack interrupt API > > > > > > Add new ack interrupt API to avoid using > > > VFIO_IRQ_SET_ACTION_TRIGGER(rte_intr_enable()) for > > > acking interrupt purpose for VFIO based interrupt handlers. > > > This implementation is specific to Linux. > > > > > > Using rte_intr_enable() for acking interrupt has below issues > > > > > > * Time consuming to do for every interrupt received as it will > > > free_irq() followed by request_irq() and all other initializations > > > * A race condition because of a window between free_irq() and > > > request_irq() with packet reception still on and device still > > > enabled and would throw warning messages like below. > > > [158764.159833] do_IRQ: 9.34 No irq handler for vector > > > > > > In this patch, rte_intr_ack() is a no-op for VFIO_MSIX/VFIO_MSI > interrupts > > > as they are edge triggered and kernel would not mask the interrupt > before > > > delivering the event to userspace and we don't need to ack. > > > > > > Signed-off-by: Nithin Dabilpuram > > > Signed-off-by: Jerin Jacob > > > --- > > > v2: > > > * No change > > > > > > lib/librte_eal/common/include/rte_interrupts.h | 22 +++++++ > > > lib/librte_eal/freebsd/eal/eal_interrupts.c | 9 +++ > > > lib/librte_eal/linux/eal/eal_interrupts.c | 81 > > > ++++++++++++++++++++++++++ > > > lib/librte_eal/rte_eal_version.map | 1 + > > > 4 files changed, 113 insertions(+) > > > > > > diff --git a/lib/librte_eal/common/include/rte_interrupts.h > > > b/lib/librte_eal/common/include/rte_interrupts.h > > > index c1e912c..93b31cd 100644 > > > --- a/lib/librte_eal/common/include/rte_interrupts.h > > > +++ b/lib/librte_eal/common/include/rte_interrupts.h > > > @@ -118,6 +118,28 @@ int rte_intr_enable(const struct rte_intr_handle > > > *intr_handle); > > > */ > > > int rte_intr_disable(const struct rte_intr_handle *intr_handle); > > > > > > +/** > > > + * It acks an interrupt raised for the specified handle. > > > + * > > > + * Call this function to ack an interrupt from interrupt > > > + * handler either from application or driver, so that > > > + * new interrupts are raised. > > > + * > > > + * @note For interrupt handle types VFIO_MSIX and VFIO_MSI, > > > + * this function is a no-op and returns success without > > > + * changing anything as kernel doesn't expect > > > + * them to be acked. > > > + * > > [...] > > > > Shouldn't we explain that this really is "unmask" but named "ack" becau= se > > of x and y, and that it is expected at end of INTx handler? Ack does > > not have a well-defined meaning, whereas everyone knows what unmask > > means.. > > >=20 >=20 > Ok. Is the below text fine with you ? Or please suggest. >=20 > @note For interrupt handle types VFIO_MSIX and VFIO_MSI, > this function is a no-op and returns success without > changing anything as kernel doesn't expect > them to be acked. > This needs be used atleast for PCI devices with INTx interrupt > as kernel before passing on event for INTx triggered interrupt, > masks the interrupt and expects application to unmask it so that, > further interrupts can be raised/triggered. This is also due to > the fact that INTx is level triggered interrupt where as MSI/MSIx > is not. Ideally this should have been called as intr_unmask() > representing underlying api, but since unmask operation > is not supported and not needed for VFIO MSI/MSIx interrupts > after handling, it is named as ack. >=20 How about this? PMD generally calls this function at the end of its IRQ callback. Internally, it unmasks the interrupt if possible. For INTx, unmasking is required as the interrupt is auto-masked prior to invoking callback. For MSI/MSI-X, unmasking is typically not needed as the interrupt is not auto-masked. In fact, for interrupt handle types VFIO_MSIX and VFIO_MSI, this function is no-op. Thanks for your effort.. -Hyong