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 34D13A0471 for ; Wed, 17 Jul 2019 11:51:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EF8461DBE; Wed, 17 Jul 2019 11:51:26 +0200 (CEST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by dpdk.org (Postfix) with ESMTP id 7A1B11D9E for ; Wed, 17 Jul 2019 11:51:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3729; q=dns/txt; s=iport; t=1563357085; x=1564566685; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bXd4y++gswbbl/BsFHGRrHJTrrbM/DiJzIIz1pBrBDE=; b=O3RFa2IiXXiLrzT80bjC1tu4KjGGAcedbqlQ0RjLsOXdWAEjfzlVnK6R hZnxF+/xUsAhUzHk6IDDDECGMsh4u3FP7JfRklqStvUvwh0UxnKHr3ari jo5oN4dZuGdA121GyAssXyLgoKFV+YsZsTF5/+/jjeFBCx90mRKDbApcb 0=; IronPort-PHdr: =?us-ascii?q?9a23=3Ao5Tk6RdYDjK6KxXHtuS4cFH1lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/bz09GsdDUXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADC7i5d/5FdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FEUAOBQiAECyqHYwOOA4Jbl1CBQoEQA1QJAQEBDAEBLQI?= =?us-ascii?q?BAYRAAoJEIzgTAQMBAQQBAQIBBW2FPAyFSgEBAQECARIoBgEBNwEEBwQCAQg?= =?us-ascii?q?RBAEBHxAyFwEFCAIEAQ0FCBqEawMODwGiCQKBOIhggiOCeQEBBYEGAYQJGII?= =?us-ascii?q?TCYE0i18XgUA/gRABRoJMPoQRARIBBxokgxeCJoxYh0GWTgkCghmUJ4IthyW?= =?us-ascii?q?OOI01l1ACBAIEBQIOAQEFgWchZ3FwFYMngkEMF4NOihwBNnKBKYpKgkMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,273,1559520000"; d="scan'208";a="598221468" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2019 09:51:24 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x6H9pNe9015540 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2019 09:51:24 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 04:51:23 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 05:51:22 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 17 Jul 2019 04:51:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRcYlRSM1DlNxsEhpBB6OZ4Ph8JI3PGmG6E8zjjUcDMUWJ8w5JTgNqJ/0dq8fARmw8OhD6us2IT5kf7mO2saS/PNhWe7MlGjAXuk0fAujXabc0b51KEeg0mepSkpjcE0b/fBCtNOiumAF4/dgVEZgJOXJm86t+1BYkTBbNcVeSZUYKMo3GYf4hbpXCbHAQm8Jy3+LqP/Oj5Nk4H+iWxVNG+2eBqdze5EPP/OAl6IK1w77yCmTo9iFVqOwbLD8BJI9RqXVVoluWHBlos4uL+jqX1wKVu85qW3/71vXxYzvrGxoikT174xoqNpcSDOLxTQA0nZwCX4RpEwPleqz3/3vg== 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=i35esivL9Rx+KlIu4wEYqn7JOdxvH6nNVbKY1E8CXOM=; b=E29OscldkZ/819PunSMSkZ/BT3PVlv4dyFaHH0Ol+wEoksHfDicJwZBO01B/ftTCObU5/yweaQhf5HvVvcByRM1AheRmtsNTsBQYDmWG9olJfMFDgD6q0u72aaaBLQSouReZ7OeTgoVpeK1L5wwvR690D+DnfJyXQqon5yylz7kJcPLlMwQPBnZcl6rEc6OMys5rwK1ETK9h/2ZKtdGhCjaiW7yONK5O1xAXjKvvQhkn7jjEiTsBXAjBObfzIwYLuNbcdBXw0GY23rPUfGcKodvKT2yI9lVBT4YXBidR+hZ/W1x8qy45Ef4QN0no1kkxj08nZznbtC6crNFnS2Ka+Q== 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=i35esivL9Rx+KlIu4wEYqn7JOdxvH6nNVbKY1E8CXOM=; b=cZD7nwcLcOfgis9Eg0AKZI/SdZVcle18CF24iHrDRwa+ZmVaNLGKp9GhNegns2jnnaE4jgzfHlkvKpMEVa7U2qLUvQV6lrNNCGhvC09Qgo7PgEYPCzsMNZGO4beH2GuDGpBUj7AGfE4xCg9LKtNI2bXeL0qFgaU2Yjg1tsaq5hk= Received: from MWHPR11MB1839.namprd11.prod.outlook.com (10.175.53.12) by MWHPR11MB1311.namprd11.prod.outlook.com (10.169.237.14) 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 09:51:21 +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 09:51:21 +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/uAgAAJaZCAAAxRgIAAARPA Date: Wed, 17 Jul 2019 09:51:21 +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: c5f79229-d0a5-4131-55f4-08d70a9c52cb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR11MB1311; x-ms-traffictypediagnostic: MWHPR11MB1311: 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)(376002)(136003)(39860400002)(396003)(366004)(13464003)(189003)(199004)(2906002)(476003)(186003)(76176011)(46003)(53546011)(102836004)(6506007)(11346002)(478600001)(25786009)(7696005)(54906003)(110136005)(8676002)(4326008)(446003)(14454004)(9686003)(74316002)(305945005)(99286004)(7736002)(81156014)(81166006)(76116006)(66476007)(64756008)(33656002)(8936002)(66446008)(66556008)(6116002)(66946007)(316002)(71200400001)(71190400001)(6436002)(52536014)(86362001)(486006)(229853002)(5660300002)(256004)(55016002)(53936002)(68736007)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1311; 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: yZ7qK3VkvDWEhGbKgEHy3h8nMyrMH8SxStDbh7sfFeZ/OOssV7AeSBiDiBKA9ZoXdi2RZJ1Xe5uUfxRNwLMPMRTUW6CqgBlqVgxRUbQcZRP/GqTz0UGgbp51PYEp5j79dgcJ5sHaZLnzrjvLYE8vTkFtBDdoWvKPK3mH8G0tOjDeRvDwWXPtJgCL9AnHhCC7Itz0ywt9chtFCfQ4qsuR83Kal+1YuoDyKqMya4VIwnpTuXe/l6fFlNWZM73nXLP9GVT0mC1rlu4eY/1aMktSjr57zF697qPbCYGjtcLZW+vNGOTtMAEGUjUIPGv05UcH4uSC2LpGbLghSk+YVcpXxRT7GLo1c8KHd9i1Ukx5CJcahelyOQJmTNdWJzozmM0yT/8O0qfT9h+hSftCrP10wh+bx+MeEdDRitSheyK+wsE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c5f79229-d0a5-4131-55f4-08d70a9c52cb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 09:51:21.5367 (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: MWHPR11MB1311 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-9.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 6:21 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 > > > > Not sure. I do not have a good suggestion here :-) Like to hear fro= m > > > > David when he comes back, as he spent most time on this issue.. > > > > > > Sure. He is on vacation. > > > Any reason for thinking, rte_intr_ack() may not be semantically corr= ect? > > > 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. > > > > > > > > > > > Why not return -1 and let the caller deal with it? > > > > > > If we make it as rte_intr_ack() no need to return -1 for > > > MSIX-VFIO+Linux as it is semantically correct. > > > > > > > Ack can be ambiguous. For INTx, ack usually means PIO to a NIC register= , > > saying "I got your interrupt, please de-assert irq". >=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_ ma= ke > 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 >=20 Just curious, what you mean by irq controller? Ack/mask/unmask PIOs all go 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 >=20 > Yes >=20 > > - Nothing if MSI/MSI-X > Yes for MSI over VFIO > No for MSI over UIO/igb_uio >=20 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... --- 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/NICs to control interrupts their own way. A long time ago in early PCIe days, the linux kernel did auto-masking for MSI/MSI-X (i.e. mask before calling netdev irq handler). It was soon removed as it was unnecessary overhead (expensive PIOs to NIC for every interrupt). Windows and FreeBSD do not do auto-masking either. --- Most drivers have a single irq callback. handler() { do_action() rte_intr_umask/ack() } Suppose MSI/MSI-X is used (super likely since it is the default). With igb_uio, rte_intr_umask/ack() will actually do PIO writes to the NIC to unmask. This is unnecessary overhead. > 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 tha= t to > make forward progress. > Let us know. >=20 I have no strong opinion either. Thanks.. -Hyong