From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,URIBL_SBL,URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 724EEC76186 for ; Wed, 17 Jul 2019 08:45:53 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id CC8F82173E for ; Wed, 17 Jul 2019 08:45:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=cisco.com header.i=@cisco.com header.b="hEqozdec"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=cisco.onmicrosoft.com header.i=@cisco.onmicrosoft.com header.b="EiJQn0YC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC8F82173E Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=cisco.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CEB421B53; Wed, 17 Jul 2019 10:45:51 +0200 (CEST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by dpdk.org (Postfix) with ESMTP id 6017EDE3 for ; Wed, 17 Jul 2019 10:45:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5862; q=dns/txt; s=iport; t=1563353150; x=1564562750; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q1FlA3Vk9tImalkTwkRidHSRNKm5a1+pGWplIPURlMA=; b=hEqozdecJGIFRbR22dwdOEOwPv/+WuiGG1Waj1656WaacJIfUL5OnAnK 9axxOszajBpJtzTivZAsw3vwZYknzdNAtQ1lmLD/vdGaiOH3L9HAzDpxl xgBFF/y7jVK/WirMIFtFSViWHQqBOcWCO7a0FlwTL7aVhizZ+3rXq8cvF Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AWnuiIx17v5taFGOvsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQCVz8Kv3ragQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADx3y5d/4gNJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FEUAOBQiAECyqHYwOOGYJbfpZSgUKBEANUCQEBAQwBAS0?= =?us-ascii?q?CAQGEQAKCRCM4EwEDAQEEAQECAQVthTwMhUoBAQEBAxIVEwYBATcBCwQCAQg?= =?us-ascii?q?RBAEBHxAyFwEFCAIEAQ0FCBqEawMdAaF5AoE4iGCBcDOCeQEBBYEGAYQJGII?= =?us-ascii?q?TCYE0i18XgUA/gRABRoIXNT6EHQ8aJIMXgiaMFESHQZZOCQKCGZQngi2HJY4?= =?us-ascii?q?4jTWXUAIEAgQFAg4BAQWBZyGBWHAVO4JsgkEMF4NOihwBNnKBKYo7glIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,273,1559520000"; d="scan'208";a="297767774" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2019 08:45:49 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6H8jmOJ023389 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2019 08:45:48 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 03:45:48 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 03:45:48 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 17 Jul 2019 04:45:47 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B9we20sldrksPS+fLbwFIvaci9yYZ76i9EMp4Pxt3eQAsm4oNvkf6SzrbeiY4h0cjyy5NZ3DgeEwW1r5lxvQuFfE9OpHDie4XsRrubzgWrvBU+SQe9UuKCJBJKj7Oir/A+gDwVIdPw4Yw5aA2WvN0Su5f7vBc9y8I891VDynVubKB6i/HVjpf7De5InqjUkJWMI8ISgbLrZ8oQjCwx5dxXqLcJEogCfePKcMRUC0dAI1yLcxX2yISCbvSVnPsvq5K6X7kg11nBh5tcgd37rh8kAlbDMc7wDRvwmiW+AztrTKzGsGPZchVFFDWcTDeqxIiIZVS48P9HxZXEQSONs7xA== 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=txiA9uTlRriN8DTa8FYcjzHrryuEnhuC56JShkbRboE=; b=mln0cPfENKkdeFoWoQGnWYR0iZVc/wvBzqKTA3vJAcUATT4dFWARTPTQaquaWznVsM9kG2NTcEKysK8rNxJzAJYS2c5qJtAOCzDm02NkP4frxBZrE37OrftMx4XuGaRwoGx31v5PDDVJUOZ+kZTS0aCuB6OqRWuSoLGAGI50/V1cJD80GFTaSQUVLYfzbor/r5ozxNtB0aoSQHbvl/AgOcsmaBq985JUEyqPlVE+W6Z6J0kdPWVsAJf6OPpoEQ9PJ6w1O+00282nRWwaE0s/SpCshSH4yMY5nH+/B0ySqsTphjQk+RTyqtCZb6krOOUtCtYuyL2zo2xK10ggnLYADw== 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=txiA9uTlRriN8DTa8FYcjzHrryuEnhuC56JShkbRboE=; b=EiJQn0YCPmoHNoHKtYlOGIRIL57G83Wx5ycFqwXuQekiqA4nOC12BQpkrGc8NQ6cuRhT6ZuH2kphruXrmOjRdbIhN5iqe3GSq94tIDeg/kUCKj/LQWTHueBAAlptrQpvdvGwV3OBEbq/WhPqKCEtsOh+bkZSFE0c+ooNucvzBBY= Received: from MWHPR11MB1839.namprd11.prod.outlook.com (10.175.53.12) by MWHPR11MB1295.namprd11.prod.outlook.com (10.169.237.138) 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 08:45:46 +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 08:45:46 +0000 From: "Hyong Youb Kim (hyonkim)" To: Jerin Jacob Kollanukkaran , Nithin Kumar Dabilpuram , David Marchand , Thomas Monjalon , Ferruh Yigit , Bruce Richardson CC: "John Daley (johndale)" , Shahed Shaikh , "dev@dpdk.org" Thread-Topic: [RFC PATCH v3 2/3] eal: add mask and unmask interrupt APIs Thread-Index: AQHVO/XevRYbQEFR2kiByXrzVb6deqbOSiswgAALwwCAAApQwIAAE/uAgAAJaZA= Date: Wed, 17 Jul 2019 08:45:46 +0000 Message-ID: References: <20190716164424.16776-1-ndabilpuram@marvell.com> <20190716164424.16776-2-ndabilpuram@marvell.com> In-Reply-To: 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: eb8ae11a-e243-4491-3276-08d70a932951 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR11MB1295; x-ms-traffictypediagnostic: MWHPR11MB1295: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(189003)(199004)(13464003)(76176011)(6116002)(66476007)(2906002)(102836004)(53546011)(6506007)(66446008)(64756008)(76116006)(66556008)(14454004)(66946007)(52536014)(5660300002)(46003)(186003)(7696005)(229853002)(55016002)(25786009)(305945005)(9686003)(53936002)(74316002)(256004)(7736002)(6436002)(11346002)(476003)(81166006)(81156014)(8936002)(446003)(71190400001)(478600001)(33656002)(8676002)(71200400001)(68736007)(110136005)(4326008)(54906003)(486006)(86362001)(99286004)(6246003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1295; 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: h6zDyt5pAQQ02+K3nF6XOBvd5z9MtwhwgUlQwYY95dGRtRXzVc8J0HYpSasZT22Kk2alS1+EiP6xrKI8BsDwCPmWgzpih+dMwmUEIEiz396TElaG8rQjdfpeLrbFe2RLzNbja21rCqyKpw1p5kidLX13k8Eav5r8zalpckYeb4fitpQd8EHa/I34yDpvRmvkL+Pwm7JC4u5KvhndG40JR1eoiJ+owADpCHsqMgT39OqhsWovnP/ZHkjX2ZgAAIpM+XCL8p0WcXJ2oGzOh58QMJmAGFVvQEZQ718McvkVJNVkRvWWbHNwvbpXEUb6Uo5ssSMCmrR3RvEHIC6/EpUf+9gcA3ji0aCERII7pZzkwlVpFqoWJFyAlxvVkCt6SJm+34ZEQkaPFIYw7vSiaKYeMYBAgo8HA8KBZy0txzjBw6g= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eb8ae11a-e243-4491-3276-08d70a932951 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 08:45:46.4150 (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: MWHPR11MB1295 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: alln-core-3.cisco.com Subject: Re: [dpdk-dev] [RFC PATCH v3 2/3] eal: add mask and unmask interrupt APIs 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: Jerin Jacob Kollanukkaran > Sent: Wednesday, July 17, 2019 5:03 PM > To: Hyong Youb Kim (hyonkim) ; Nithin Kumar > Dabilpuram ; David Marchand > ; Thomas Monjalon > ; Ferruh Yigit ; Bruce > Richardson > Cc: John Daley (johndale) ; Shahed Shaikh > ; dev@dpdk.org > Subject: RE: [RFC PATCH v3 2/3] eal: add mask and unmask interrupt APIs >=20 > > > > -----Original Message----- > > > > From: Hyong Youb Kim (hyonkim) > > > > Sent: Wednesday, July 17, 2019 11:26 AM > > > > To: Nithin Kumar Dabilpuram ; David > > > Marchand > > > > ; Thomas Monjalon > > ; > > > > Ferruh Yigit ; Bruce Richardson > > > > > > > > Cc: Jerin Jacob Kollanukkaran ; John Daley > > > > (johndale) ; Shahed Shaikh > > > > ; dev@dpdk.org > > > > Subject: RE: [RFC PATCH v3 2/3] eal: add mask and unmask interrupt > > > > APIs > > > > > +rte_intr_mask(const struct rte_intr_handle *intr_handle) { > > > > > + if (intr_handle && intr_handle->type =3D=3D > RTE_INTR_HANDLE_VDEV) > > > > > + return 0; > > > > > + > > > > > + if (!intr_handle || intr_handle->fd < 0 || > > > > > +intr_handle->uio_cfg_fd < > > > > 0) > > > > > + return -1; > > > > > + > > > > > + switch (intr_handle->type){ > > > > > + /* Both masking and disabling are same for UIO */ > > > > > + case RTE_INTR_HANDLE_UIO: > > > > > + if (uio_intr_disable(intr_handle)) > > > > > + return -1; > > > > > + break; > > > > > + case RTE_INTR_HANDLE_UIO_INTX: > > > > > + if (uio_intx_intr_disable(intr_handle)) > > > > > + return -1; > > > > > + break; > > > > > + /* not used at this moment */ > > > > > + case RTE_INTR_HANDLE_ALARM: > > > > > + return -1; > > > > > +#ifdef VFIO_PRESENT > > > > > + case RTE_INTR_HANDLE_VFIO_MSIX: > > > > > + case RTE_INTR_HANDLE_VFIO_MSI: > > > > > + return 0; > > > > > > > > Isn't this a little confusing? It returns success, but irq is not m= asked. > > > > > > Yes. How about changing the API to rte_intr_ack()(Acknowledge the > > > interrupt) > > > Or something similar? i.e replace rte_intr_unmask() with > > > rte_intr_ack() for this use case. > > > > > > > Not sure. I do not have a good suggestion here :-) Like to hear from > > David when he comes back, as he spent most time on this issue.. >=20 > Sure. He is on vacation. > Any reason for thinking, rte_intr_ack() may not be semantically correct? > I think, it is very much correct if there are no better suggestions. > Anyway it the name, From VFIO perspective, we know what is expected so I > think it is fine. >=20 > > > > Why not return -1 and let the caller deal with it? >=20 > If we make it as rte_intr_ack() no need to return -1 for MSIX-VFIO+Linux > as it is semantically correct. >=20 Ack can be ambiguous. For INTx, ack usually means PIO to a NIC register, saying "I got your interrupt, please de-assert irq". Besides the name, are we agreeing that we want these? - Unmask if INTx - Nothing if MSI/MSI-X So, really just "unmask if INTx". I am ok with rte_intr_unmask() if we make this intention clear. rte_unmask_if_intx() looks messy. Thanks.. -Hyong > > > > Optimist view: > > Maintainers will see the error as vfio-pci + MSI/MSI_X is on > > everyone's test list. And it forces them to confront the issue. Do I > > really need unmask here, etc. >=20 > If we make it as ack then it fine as driver does not need to know the fin= e > details. >=20 > > > > Pessimist view: > > Wastes a lot of people's time. Potentially duplicate code like this > > everywhere. > > > > if (INTx) unmask(); > > > > BTW, are you targeting 19.08 or 19.11? Not sure how much change we can > > tolerate in 19.08. >=20 >=20 > 19.08 as fundamentally it correct. Finer adjustment can made by existing > drivers if required in the testing phase. >=20 > It is trivial change as scope is limited to interrupt hander rte_intr_ena= ble() > replacement with rte_intr_ack(). For MSIX case, it should be real NOP, > so I don't think there issue. It should be much better than the existing > state, where almost everything broken. >=20 > > Requirements for 19.08 seem to be... > > - Must fix the redhat bz (lost interrupt issue with qede + MSI/MSI-X) > > - Fix potentially similar issues in other drivers too? >=20 > Proposed patch will fix the above mentioned issues. >=20 > > > > Thanks.. > > -Hyong > > > > > > As is, return code 0 means... > > > > - igb_uio: irq is masked for INTx, MSI, MSI-X > > > > - vfio-pci + INTx: irq is masked > > > > - vfio-pci + MSI/MSI-X: no changes > > > > > > > > Masking is useful only for INTx, IMO... > > > > > > > > Masking MSI/MSI-X via PCI-defined mechanisms (e.g. Mask bit in MSI-= X > > > > Table) has no practical use for drivers. > Handshaking/masking/unmasking > > is > > > > done via device/vendor specific ways, as needed. See all those > > > > ack/block/unblock/credit/... mechanisms used in various drivers/NIC= s > to > > > > control interrupts their own way. > > > > > > > > A long time ago in early PCIe days, the linux kernel did auto-maski= ng for > > > > MSI/MSI-X (i.e. mask before calling netdev irq handler). It was soo= n > > > removed > > > > as it was unnecessary overhead (expensive PIOs to NIC for every > > interrupt). > > > > Windows and FreeBSD do not do auto-masking either. > > > > > > rte_intr_ack() can abstract FreeBSD and Windows difference. > > >