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 7A07DC76192 for ; Wed, 17 Jul 2019 11:17:01 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id D9BC22173B for ; Wed, 17 Jul 2019 11:17:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=marvell.com header.i=@marvell.com header.b="KtNdT2c3"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=marvell.onmicrosoft.com header.i=@marvell.onmicrosoft.com header.b="Ba04YtCk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9BC22173B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marvell.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 308D61B9AC; Wed, 17 Jul 2019 13:17:00 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 888661B9AA for ; Wed, 17 Jul 2019 13:16:58 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6HBEjRE027186; Wed, 17 Jul 2019 04:16:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=QRxpI/MIXUI9CYmYYC1lT+x+V8ZvWy5uen4EeMo08+A=; b=KtNdT2c31U5QMJ1yc6kERKCGMLJ0OF5f2/VVrMfqkSagg61R6axDMIgtsLwKbonk1aL2 TlqQDbOlIHkNwNqeoMO1Skg+UYOzDHbSQQ8HcaoRTIKlm875jvRnbksFApdbMLgnGMf7 Vp2S+JyPgrUMNbZNYrnR34CaML9H51+RcHACqEpesp04bplpCCsdPUg4y+pVmxCUrxLe HI4kZEIMc5o5GivcygUrjIh7n5xhW9lGvUZYIoIneKdgdqTIHiXqDSJe9xKWsPD5MecH 0RIzySnLR9S8VB7YzhDwe05b9Ugvs1KXFTLpsTExgqGTM5y0rWCekiXmNaQzOjx9d05v nw== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 2ts07vfwws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jul 2019 04:16:55 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Jul 2019 04:16:53 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.58) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 17 Jul 2019 04:16:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fhQAdFxK/GNJRDtXo/33G4Ro2M4+34lIwqueVkMEkDaLIYH38llf9zaUubGnU+R8QT1i4xvRoF/C2DVjri59ylsZnZxaTuohIMd8m86D5SXXSRsxioSAM/dLQxsYDwpF9K97eOj5Mj9ctix9Hi2YvAptm9t+EysArsCCbanv4D5fAQ08BNiak/gzpL/HqX00sCIQALCfJnR6ttdmox63awJcMfapGNBoGSJOTs33Rbavj9M5v2FrsDUVWW8H8ZzHgVM3H+Bk6COZTDsmHA7CGc32QcpjwIx9RIVMbv0yzNlqL0W1zlyePKKoTKGVlJAcIOdG3qXcxhcBWjNukahMyA== 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=QRxpI/MIXUI9CYmYYC1lT+x+V8ZvWy5uen4EeMo08+A=; b=IdrUc3/xTOP36UthR8sW+Pb8ht0cJPn74D2IBcR4XzYiAUIoY4CAl5/i57c+CsR2+ZNUV0rwLdoFqxmyAEBinrqXBZGx4CHL0SRIfFEneNV7otnZ1fBDEpBJCuv0YzKdwPDIW9fo0KuA4PNf+vrXHK9xJj/1VPYmkBfAzzRgEyNeri8nRPxuqQrN1lgzljRSzqTlJJR9DnLFG++Dik4c5xiqdKA5xBaoQyQWzdsI0s7AH/oei32vgqazGzv3wTny3twD9h8qSvqBf3exEx+YRsCFKdQ4JHvWD8dno/hHbIVCqPzTWVhC4uJcX1A8CAQBpgJKQdNDI87yaT+RYbgCOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=marvell.com;dmarc=pass action=none header.from=marvell.com;dkim=pass header.d=marvell.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QRxpI/MIXUI9CYmYYC1lT+x+V8ZvWy5uen4EeMo08+A=; b=Ba04YtCkv0C8n9x7fYS/lmtYxazeIWP6lUL/5Y++Kzs0vYL1EwLUk63fQk+H41GFn3GEC1qZpHSGzOpuKveBFZ2t8RcK5sdULDk4igQthlOTwK+QOAjf3y/YZZlRevMUtzDEqWtk2Rpc5lbgHCXggKvwKktnfPkhCOMwDA5WXrQ= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2392.namprd18.prod.outlook.com (20.179.91.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 17 Jul 2019 11:16:52 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::2d42:12b6:aa2e:2862]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::2d42:12b6:aa2e:2862%4]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 11:16:52 +0000 From: Jerin Jacob Kollanukkaran 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" Thread-Topic: [RFC PATCH v3 2/3] eal: add mask and unmask interrupt APIs Thread-Index: AQHVO/XIb9GeLyW36Uqi1XtdG9Kqj6bOUK4AgAAD+yCAABCQAIAAChEggAAQ1wCAAAaUUIAAC7+AgAALR1CAAAmXAIAAAXtQ Date: Wed, 17 Jul 2019 11:16:52 +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: x-originating-ip: [106.200.248.176] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 396ab2f4-7b09-431f-83c6-08d70aa844e3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2392; x-ms-traffictypediagnostic: BYAPR18MB2392: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39850400004)(366004)(346002)(376002)(13464003)(199004)(189003)(478600001)(486006)(7736002)(53546011)(102836004)(66476007)(99286004)(8676002)(68736007)(6246003)(14454004)(6116002)(86362001)(26005)(6506007)(64756008)(186003)(3846002)(71200400001)(71190400001)(53936002)(81166006)(11346002)(4326008)(446003)(74316002)(5660300002)(256004)(76116006)(7696005)(25786009)(14444005)(9686003)(52536014)(305945005)(6436002)(55016002)(66946007)(33656002)(8936002)(81156014)(2906002)(110136005)(229853002)(66556008)(66446008)(476003)(76176011)(316002)(54906003)(66066001)(309714004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2392; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7P5eIQfjEA0nMGkRcxoIXldtKDA6krLyEJvySJ/MU0T2ks48EAEmbiple/obOX6PzSEu5zVaCQ+7eXTpEVAgBY0KOk4DyQAicYqGnSYHoDRmOY2jjYtChTZ/9DYcOtuaUI4CVxT1SZcDgaPI6v5IK4c4Eyxb5EeHiduvmxwUThHPjknINPvYL5a3Y8N92+AbDZ4bx+hrs9msJdZ6aC4nEpj9U6nK3w8fTjVSbYILbdUM5pne+Gtp5aCNzh9m+Mx+0U4qfaZpfEUdh2V3N/dvhaU2Pqwg0xdAzqnmr/YB23tJl0NGJZxau6HgTEWCpi9wSJMc3Zcjd31o5x+TepNYoz6OKCfIvMOBYuUvcgONVJAHTZK6u8iBKNidmW5obAznXAWiVSywLMNcSpjCVoQnu4v+hmo1SFppB66LTch4G3I= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 396ab2f4-7b09-431f-83c6-08d70aa844e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 11:16:52.0610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jerinj@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2392 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-17_04:2019-07-17,2019-07-17 signatures=0 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: Hyong Youb Kim (hyonkim) > Sent: Wednesday, July 17, 2019 4:36 PM > To: Jerin Jacob Kollanukkaran ; 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: Jerin Jacob Kollanukkaran > > Sent: Wednesday, July 17, 2019 7:44 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 > > > > > > I think, it vary from the perspective of IRQ Chip(or controller) > > > > vs NIC > > > > register(Source) PoV. > > > > Since the API starts from rte_intr_* it is more of controller so > > > > _ack_ make sense Other reason for ack: > > > > 1) It will enforce that it needs to be called form ISR > > > > 2) It would be have been really correct to unmask if > > > > VFIO+MSIx+Linux supports it > > > > 3) if it is ack, no need to add unmask counterpart, the _mask_ API > > > > > > > > > > Just curious, what you mean by irq controller? Ack/mask/unmask PIOs > > > all > > go > > > > Programmable Interrupt Controller. Like Intel 8259A, GIC from ARM etc > > The drivers in linux/drivers/irqchip/ > > > > > to the NIC. It is the NIC that asserts/de-asserts irq.. > > > > > > > > > > > > > Besides the name, are we agreeing that we want these? > > > > > - Unmask if INTx > > > > > > > > Yes > > > > > > > > > - Nothing if MSI/MSI-X > > > > Yes for MSI over VFIO > > > > No for MSI over UIO/igb_uio > > > > > > > > > > I guess I was not clear. For MSI/MSI-X, we do not want to do > > > mask/unmask regardless of vfio-pci/igb_uio. Below is my comment > > > about linux/windows/freebsd from an earlier email. Do you disagree? > > > I am sure there are plenty of kernel NIC driver guys here. Please > > > correct me if I am mistaken... > > > > > > For some reason, igb_uio kernel driver mask the interrupt for MSIx. > > We need to ack or unmask if needs to work with MSIX + IGB_UIO. > > > > See > > pci_uio_alloc_resource() > > if (dev->kdrv =3D=3D RTE_KDRV_IGB_UIO) > > dev->intr_handle.type =3D RTE_INTR_HANDLE_UIO; > > else { > > dev->intr_handle.type =3D RTE_INTR_HANDLE_UIO_INTX; > > > > igbuio_pci_irqcontrol() for masking in kernel. > > >=20 > igb_uio does not auto-mask MSI/MSI-X. I have not tested igbuio as we don't specific NIC + IGB_UIO platform. The observation based on following code. see code under HAVE_PCI_MSI_MASK_I= RQ static int igbuio_pci_irqcontrol(struct uio_info *info, s32 irq_state) { struct rte_uio_pci_dev *udev =3D info->priv; struct pci_dev *pdev =3D udev->pdev; #ifdef HAVE_PCI_MSI_MASK_IRQ struct irq_data *irq =3D irq_get_irq_data(udev->info.irq); #endif pci_cfg_access_lock(pdev); if (udev->mode =3D=3D RTE_INTR_MODE_MSIX || udev->mode =3D=3D RTE_I= NTR_MODE_MSI) { #ifdef HAVE_PCI_MSI_MASK_IRQ if (irq_state =3D=3D 1) pci_msi_unmask_irq(irq); else pci_msi_mask_irq(irq); #else igbuio_mask_irq(pdev, udev->mode, irq_state); #endif } if (udev->mode =3D=3D RTE_INTR_MODE_LEGACY) pci_intx(pdev, !!irq_state); pci_cfg_access_unlock(pdev); return 0; } >=20 > static irqreturn_t > igbuio_pci_irqhandler(int irq, void *dev_id) { > struct rte_uio_pci_dev *udev =3D (struct rte_uio_pci_dev *)dev_id= ; > struct uio_info *info =3D &udev->info; >=20 > /* Legacy mode need to mask in hardware */ > if (udev->mode =3D=3D RTE_INTR_MODE_LEGACY && > !pci_check_and_mask_intx(udev->pdev)) > return IRQ_NONE; >=20 > uio_event_notify(info); >=20 > /* Message signal mode, no share IRQ and automasked */ > return IRQ_HANDLED; > } >=20 > Also tested just now with igb_uio. The driver does not need to call > rte_intr_enable(), and it keeps getting interrupts without any issues. If you are sure, we can make MSIX+IGB_UIO as NOP in rte_intr_ack() > Am I missing something? >=20 > -Hyong >=20 > > So it is more of making inline with igb_uio kernel driver AND not > > break The existing drivers which was using rte_intr_enable in ISR with > > MSIX+IGB_UIO > > > > I do agree with that for edge trigged interrupt mask may not require > > from kernel. > > But I am not sure why it is added in igb_uio kernel driver. May be it > > is just legacy. > > Anyway this wont change schematics, when igb_uio kenrel fixed then the > > counter Part can be changed in rte_intr_ack(). Ie. it is transparent > > to drivers. > > > > > > > > > I don't have very strong opinion unmask vs ack. I prefer to have > > > > ack due the reasons stated above. > > > > If you really have strong opinion on using unmask, we will stick > > > > with that to make forward progress. > > > > Let us know. > > > > > > > > > > I have no strong opinion either. > > > > OK. Lets stick with rte_intr_ack(). > > > > > > > > Thanks.. > > > -Hyong