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 14B09A0471 for ; Wed, 17 Jul 2019 13:06:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C91705B3C; Wed, 17 Jul 2019 13:06:10 +0200 (CEST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by dpdk.org (Postfix) with ESMTP id 4A3861041 for ; Wed, 17 Jul 2019 13:06:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4009; q=dns/txt; s=iport; t=1563361568; x=1564571168; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0fUQzKmWtSA56VgPW95M5ffvyutr3Hsi3uML9B55ED4=; b=T3DrAGhTDcD7HFUnhFsVCIYGW9JZWw0tXy/CKbJRH3mm/tWVMMWEJT11 vxOX5MqZYPKeOKyfHmCI1PQcjOc4Rj9sY/0g2/WNOMClOl7zCrhx9Yv9V 8ZcKcV9xHjNt8TbezDsawVg1Kt5UBtVyoZpfFvaLyozq4EdoCJDqc7mpz M=; IronPort-PHdr: =?us-ascii?q?9a23=3A53gnqRWFy5fGEKdWZ4pewxrsJFXV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank6DcNEV15g13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAACJAC9d/5xdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FEUAOBQiAECyqHYwONfIJbl1CBQoEQA1QJAQEBDAEBLQI?= =?us-ascii?q?BAYRAAoJEIzgTAQMBAQQBAQIBBW2FPAyFSgEBAQECARIVEwYBATcBBAcEAgE?= =?us-ascii?q?IEQQBAR8QMh0IAgQBDQUIGoRrAw4PAaIkAoE4iGCBcDOCeQEBBYEGAYQEGII?= =?us-ascii?q?TCYE0i18XgUA/gRABRoJMPoQRARIBISSDF4ImlBmWTgkCghmUJ4IthyWOOI0?= =?us-ascii?q?1l1ACBAIEBQIOAQEFgWchZ3FwFYMngkEMF4NOihwBNnKBKYsEgkMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,274,1559520000"; d="scan'208";a="601413800" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2019 11:06:04 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x6HB64Eq027632 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2019 11:06:04 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 06:06:04 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 06:06:03 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 17 Jul 2019 06:06:03 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J0DQ2Cb3uGO59RkKPl+oGrbOk/A8a8/1GNP4bsfpzHHSrU0O3fLTB8goRxF3eoMwGy/gOFcyfPP3YhL1bTXRu/h28Pv/9Iz3qALzVC5E2t08HAhhnAC8gSYwPHmMynvmVzIBeLSLF01wvdQhzIRw6nuV7Og15b5+gzGuKxKAp0G6B2BNKQ6oaQJA6Fd62WHcny4onGdEYb3JUVG6NOrj0IdSUPQRfAcg9uV5hA2Epb5geBB8zl7l29pdPR+Ma4Yqfu/qKZ+6jCQWRgHGs8oAkD7Z8Mvc1AIzu0lTBv0YU+wHK7I1XSqO+4XoPq8Cg9ej3gW7KB5dd0eOqFDbuP64ig== 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=03k3WhGtk7MhkSZjdtnq4Mh6D/UajpbNj/VoosecDis=; b=ZMn3BpFHe60A4u8gjyIdvPbw4eXhPdGePryA9+nx9VMDg9JqqtFSZeGPdZvVq67NwoQsMvxkSshQzc8kJvhsawPq9A/p6Rmb8zIXAW77v3n0qD6HWA81C8CV1zABPWvzn+Gu5JvNJ7YmyP+kS5yG6z/iM019eXwIAvdxfh6LWhZtwQiQaZt4++noFaRvYLGUXgx8ySRocviJJvQ2tPtipWvKymwZlcbcjmJ9awRxxX4icH6y9nh/JijhDKAn09leoJRiy9YGvIobUfqihGIjfSB8HiGcnRuNAyLJpbjsF26SHjDVXVQMZ5DD25Ikw6+fCLRvNweRb0TWaFQHIPTDug== 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=03k3WhGtk7MhkSZjdtnq4Mh6D/UajpbNj/VoosecDis=; b=mbBNSENa43OmEAKhmCgXn+Q8R5kbXsR4wvfiYDsc6IOPdVDVMYW/zB/+vblKip0Bl2rT1knW66Ve84rQRPEordSBBlcGFhNJm5K9l8cU1S5Oj0WynXC3Vq/QDfBZFjvoab6Anzy+iVquCV4zvStmovfBV1hR/fV90qReiH1Hzfk= Received: from MWHPR11MB1839.namprd11.prod.outlook.com (10.175.53.12) by MWHPR11MB1552.namprd11.prod.outlook.com (10.172.55.18) 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 11:06:02 +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 11:06:02 +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/uAgAAJaZCAAAxRgIAAARPAgAAWDgCAAAU0wA== Date: Wed, 17 Jul 2019 11:06:02 +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: 85e4c3c0-4e74-48ea-8f92-08d70aa6c1b8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR11MB1552; x-ms-traffictypediagnostic: MWHPR11MB1552: 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)(366004)(39860400002)(346002)(136003)(376002)(189003)(199004)(13464003)(46003)(81156014)(81166006)(6436002)(99286004)(53936002)(446003)(256004)(6246003)(8676002)(53546011)(6506007)(86362001)(68736007)(8936002)(316002)(55016002)(25786009)(6116002)(76116006)(64756008)(476003)(66946007)(66556008)(478600001)(11346002)(9686003)(66446008)(66476007)(110136005)(186003)(54906003)(52536014)(4326008)(2906002)(33656002)(74316002)(486006)(5660300002)(14454004)(229853002)(102836004)(7696005)(7736002)(305945005)(76176011)(71200400001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1552; 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: T+9iL+cVVw/qbuGdcIInRWKABkgzyoybswDdkFkxN70GCce5wFUaPvgwj1TDg27eU0MA7jTE7RleAiD6e6NXX9WhgQ0JJJtxKgDQSl0j60snqBDqBC5JVuwhSRE+xreDJfhzEAmYyW0qKVEcobWjcqhOah3mkF3D+CDWDWt+XHlSFAKvzrl8Aidx4d/VV4E+u+CTVbhxc/jffepwo/5oJDKVk9zq/+wtIE/eTKipXq2OwzuIZ7AckOIvG51tEI5ugk3kEhebDdxitPV4uhOHDi4Ojs92x44ybHs2cciSy8mW9SAxTaAxkpG08pF3nZ59b84N4YrbDDbBua2TE4mc9l6FIMYzzb4PYvGI05cbi+NsjT4LTUTXif7EbgRndiZpLKQpW4V6su5M4GMe2Qqry4n8vSSeQ91ZhZhpkUKsICU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 85e4c3c0-4e74-48ea-8f92-08d70aa6c1b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 11:06:02.5900 (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: MWHPR11MB1552 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-5.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 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 >=20 > > > 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 >=20 > Programmable Interrupt Controller. Like Intel 8259A, GIC from ARM etc > The drivers in linux/drivers/irqchip/ >=20 > > 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/unmas= k > > 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... >=20 >=20 > 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. >=20 > 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; >=20 > igbuio_pci_irqcontrol() for masking in kernel. >=20 igb_uio does not auto-mask MSI/MSI-X. 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; /* 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; uio_event_notify(info); /* Message signal mode, no share IRQ and automasked */ return IRQ_HANDLED; } 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. Am I missing something? -Hyong > 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 >=20 > 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. >=20 > > > > > 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. >=20 > OK. Lets stick with rte_intr_ack(). >=20 > > > > Thanks.. > > -Hyong