From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 920F3A0C47; Thu, 14 Oct 2021 12:31:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30E964112E; Thu, 14 Oct 2021 12:31:54 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 6BEF940041 for ; Thu, 14 Oct 2021 12:31:52 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19EABLDq004425; Thu, 14 Oct 2021 03:31:48 -0700 Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2108.outbound.protection.outlook.com [104.47.70.108]) by mx0b-0016f401.pphosted.com with ESMTP id 3bpjk182s7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 03:31:48 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3/xExzi8JKXVV27H73RixpOJy4vPzqccvxKExXEZXYbxNbBEYyh6dT4nSlq+99d1mGM6u4mxNnJrAl1BSeyP3QS33fpM5lnDOTNqS4NS5+uSn2C4lf/C6TTbZmn786A7JYIh4lqzYVyQhD/MzYa45wm9iVni7lDPHQIoYx+Y/pexH/1ojVIn3szcy8h4Gk9HCxII3/f4esEyeefpHaDVoOYKVphz6K0VQM0q3PJOovG+6gUcfmJ+gYX0WrQwhJa+qQydzc0HOnMbHOGGhWNsfyhvffTYWzJm5FsN4QECIaGi9WiVh7Myhea5uC06Pa0gCJ7KIH1M2ZFW/8IK4ZYag== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zZr41a+L/QT4OKDjoYB6wl8Meq4Ex9C4Vbo8q+8ayVQ=; b=T4ZjOg8JauaW/jLM8PlMV/XnoaonLNBqaGmwI1nOCLDzSfYYItUu6oe8EHk8THGxWR5AIB37AKCsAOL9VgGnnpW3IP2s6IEm4VZOq1rZut2mgev+70TnR4G5mv/G83FLTqPu5x0PbH/UQLQUsLR9lsGJFBMJSQxqqTKpCrcu+q0X7KjP4pDid6WemWd706PYnBOoC0u+P28RZcpREYOrSLLTlNfqFrmbWSBjj28fAgdU7DraeNEBysEd/XjCW9O6IOP5fJjSNSjJNIC6XJbLWWCXQMWwtb9mY36+0ucj/Ov23Pb4N9ma/3ag2x3HnTlOXKsb9Wxc+VLWotR+YdCnAA== 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=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zZr41a+L/QT4OKDjoYB6wl8Meq4Ex9C4Vbo8q+8ayVQ=; b=EcReaqkucf+KlqgZ2kR6MPKAda+i2FfjYQTLXLhA/hVgBS2bjB5qYKfvNRFSzTsQScC2rhFslsX2Pcl+4pHctgp6MJwL2XDvE3YrAY+VQnoyPNaAfNI5K0oCJkcg+nWSVbH9Tw8UybiangVoRUMALAqUpOWRxK7fOAsY/uA3Rpk= Received: from BN9PR18MB4204.namprd18.prod.outlook.com (2603:10b6:408:119::18) by BN8PR18MB2482.namprd18.prod.outlook.com (2603:10b6:408:9b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Thu, 14 Oct 2021 10:31:45 +0000 Received: from BN9PR18MB4204.namprd18.prod.outlook.com ([fe80::29f4:8e3d:264f:26b1]) by BN9PR18MB4204.namprd18.prod.outlook.com ([fe80::29f4:8e3d:264f:26b1%8]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 10:31:44 +0000 From: Harman Kalra To: Thomas Monjalon CC: David Marchand , "dev@dpdk.org" , Raslan Darawsheh , Ray Kinsella , Dmitry Kozlyuk , "viacheslavo@nvidia.com" , "matan@nvidia.com" Thread-Topic: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement get set APIs Thread-Index: AQHXv3z/vwDxAXEBi0ulm3+8amQc96vRLyBggAAJB3CAAA+/gIAA4m4AgAAQGMCAAAXhgIAAC0Yg Date: Thu, 14 Oct 2021 10:31:44 +0000 Message-ID: References: <20210826145726.102081-1-hkalra@marvell.com> <10896897.yJauvYxkRq@thomas> <4395254.EVvzvEdfqG@thomas> In-Reply-To: <4395254.EVvzvEdfqG@thomas> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7b2b6e6-1b96-4b0c-f5f9-08d98efdd183 x-ms-traffictypediagnostic: BN8PR18MB2482: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m+FKXH2KQoMcXNgDcZbnijF+DGwK2bTUAlFBEVoVzUxnkr9NyppCZsKoQKLNM6oJ2trK8S+DaaqU1BldxtNSxCtkT4lWM3LPxvWLGjEDGh4ItQ027GphC+9uSwomAyS+nHLKWrR61zRb9ruKLplDlEqj+3vWTDP7uxv+umxFcV6D5wT9xYM6iGgFaWZNfnGWb7fA4Qz7oSD2UWUNRF+dzRvY3utxYG5LbSFZKLNnI4gRf7M4QPDucxKRQQwYCGHQ0lQXEGVdf26WzAqaWeyzXriXUy8padRhuRWZMDiHFawvlY3mWX8qJ6VuG3mGgidI0G/T1si8tlzlgyjwnXBAuEQwwAuf9YdFsyGvURqV76IWkoAp2QTKP5ezOQS0c3l4oXj430HlocKQWwIu4HJ+wyqfd78P6E3q1MYVhf97Gfumv7u/FH5RKpg/XqoDymyWshj4Qq+0Y8iAZb/+I9qa2xQBbJN8JSBqE+mRJqG6SETj/dlVQiTWAOPy/FkNp/moxMwKAhQxN4jt3iI07buE59kB5LqAUGcZ8UKQPp8nCuzyzKaphbPDtnujDq8nSMI1HkNJxpGmH4mEIcOqOvkbFknBuewXALiWexK5DOr1SZflmnANIgjxJTTIILm+X5uhAIi8p8mczI7rn4p3k33rG9TFiqmd92WcQByCNtJnWHaw1kJwabNnxQKL6uQs4CD3DlABLvz9jrIG/sx1QlDemQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR18MB4204.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(71200400001)(66476007)(55016002)(64756008)(66446008)(66946007)(76116006)(66556008)(8676002)(8936002)(186003)(83380400001)(26005)(122000001)(5660300002)(4326008)(508600001)(38100700002)(54906003)(53546011)(6916009)(38070700005)(316002)(6506007)(33656002)(52536014)(9686003)(7696005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?R0r5HECeSQJu7DOFfe0mVyWIZvJgo4G843T3SywejvMUKVKgis6GQdjpjv2f?= =?us-ascii?Q?Cx2s56b3uveFWU+htThtGFI0i2j+ozTxy6jRX3V+py3gi299H2vI+kMdeeKF?= =?us-ascii?Q?2LdJyG7OYF0CAh+VduVW0uNeVyeZmoztOlhCiMCX5HwcCBJgtwoJ2aFoNdtT?= =?us-ascii?Q?czJwkO2Og3yOovqlg8YdU5vLFReZFQKO6mHCHEaQ67nwffji7inz2rbFJBQR?= =?us-ascii?Q?cPEOqU0m4AwlxaQ3w99M0xgSGZcr11UtEY7NLahEFqDwTBEKaVAu6CXtfmZo?= =?us-ascii?Q?VPmN5fQTZDHBraOM14O7i9sgYnMJdne/OL16i6loR3z+oj2t77Al1QJOo9OR?= =?us-ascii?Q?Lu2EQER4d0WKiBwDfenAY19PdBZ5ojxy6kXr8Q9mCfMw2NxwZP2XaQLst0If?= =?us-ascii?Q?ba+W8BzmUzjRZAHYsIDu7hAxjw8j7jJj6T2xC2kfKElw2yw8VlgsD03xj9GG?= =?us-ascii?Q?8LGEM9+bVZh8uMyoX9rB0x6gec5Ya/10SyJvrx43AF2IXa2gX55fK3K3OVVa?= =?us-ascii?Q?hg//ln6Yi3YHBoOWQvt8uw8toHeu/eFGpU6LCIOYfMSmhXKZFb7FOPu0fPcA?= =?us-ascii?Q?JeZKawIbKfC/pjbHhQQPCpV5qXt7wJQkAOhP2JfTKHKo3QskH5J4s9wF5pCb?= =?us-ascii?Q?Ut45CF4+uBFEia6n/XzEndkapFm6UHzvzyEzpGPko1xKF6m4CLUrSnWbFHp1?= =?us-ascii?Q?L8oY3hwHz3ZLzrhHYwAlP1r1w0iMJ2jwn0r4+5/abmbVre/LH/UglS0AX3x5?= =?us-ascii?Q?LFk2zd40MZA2QnlG66bOBd3sTx8Z7KpUKR3Tys1lW+6Pzc7t17CLBYr8v5sn?= =?us-ascii?Q?GfOFDHTZJrU2rk6UgU5QVv9ZqTsC9r402+2hHOmS4vwszUpj0JXxxHLwg9Zt?= =?us-ascii?Q?Z5ZTGR5Fz2Q5mnpm8/gZ5aSNXTCCFDIcoF+3ruLeGIFuqcJt/iRgySdqeQBe?= =?us-ascii?Q?HHUhM31sBUmCEXGZ6+mI+kxxzGNMcr7pNXNXJeUvqQT+ABjrawMlRX7y2iSN?= =?us-ascii?Q?k4f21Z2Y82WM4kAqSVLSsk94P9SlxrfL3Px9fBq75iExW77v+g9KoAr10UEH?= =?us-ascii?Q?4LV3SxhRJnHedOPgzUONCHwnRQ1yX5Xcw0AAkmlaQo7cUwz1zZXshKhtRUUP?= =?us-ascii?Q?Fam0zZeeNPHWWVSzJANJsblxxe/bAF6o4oPD8OMCz1U2OIM3OI5iG3vNAwyZ?= =?us-ascii?Q?ZBtv8vFRAIRTFXDqH4rhprOoiU3tjQtX4aQ3redTAbaAnxftyaqua3TvlER7?= =?us-ascii?Q?HZyOkN/25CtyTZwPi2io15kWyGeWPz2MWu1RAV22AEI2xz3qZNSw3WB+rggT?= =?us-ascii?Q?hsM=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR18MB4204.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7b2b6e6-1b96-4b0c-f5f9-08d98efdd183 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 10:31:44.0959 (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: JaZoJp9pzoVMRb9dzxanalVB5yS8nILlChv0eIfKGyU/Lc2kjOQ45Gfi/HwRpTnmKSeJYrS53BAYIc0fEaMh8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR18MB2482 X-Proofpoint-ORIG-GUID: _sTvoftmReqCs4sL5CNU9aI1KbQLK1kd X-Proofpoint-GUID: _sTvoftmReqCs4sL5CNU9aI1KbQLK1kd X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-14_03,2021-10-14_01,2020-04-07_01 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement get set APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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: Thomas Monjalon > Sent: Thursday, October 14, 2021 3:11 PM > To: Harman Kalra > Cc: David Marchand ; dev@dpdk.org; Raslan > Darawsheh ; Ray Kinsella ; Dmitry > Kozlyuk ; viacheslavo@nvidia.com; > matan@nvidia.com > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implemen= t > get set APIs >=20 > 14/10/2021 11:31, Harman Kalra: > > From: Thomas Monjalon > > > 13/10/2021 20:52, Thomas Monjalon: > > > > 13/10/2021 19:57, Harman Kalra: > > > > > From: dev On Behalf Of Harman Kalra > > > > > > From: Thomas Monjalon > > > > > > > 04/10/2021 11:57, David Marchand: > > > > > > > > On Mon, Oct 4, 2021 at 10:51 AM Harman Kalra > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > +struct rte_intr_handle > > > > > > > > > > > +*rte_intr_handle_instance_alloc(int > > > size, > > > > > > > > > > > + > > > > > > > > > > > +bool > > > > > > > > > > > +from_hugepage) { > > > > > > > > > > > + struct rte_intr_handle *intr_handle; > > > > > > > > > > > + int i; > > > > > > > > > > > + > > > > > > > > > > > + if (from_hugepage) > > > > > > > > > > > + intr_handle =3D rte_zmalloc(NULL, > > > > > > > > > > > + size * size= of(struct rte_intr_handle), > > > > > > > > > > > + 0); > > > > > > > > > > > + else > > > > > > > > > > > + intr_handle =3D calloc(1, size * > > > > > > > > > > > + sizeof(struct rte_intr_handle)); > > > > > > > > > > > > > > > > > > > > We can call DPDK allocator in all cases. > > > > > > > > > > That would avoid headaches on why multiprocess does > > > > > > > > > > not work in some rarely tested cases. > > > [...] > > > > > > > I agree with David. > > > > > > > I prefer a simpler API which always use rte_malloc, and make > > > > > > > sure interrupts are always handled between rte_eal_init and > > > rte_eal_cleanup. > > > [...] > > > > > > There are couple of more dependencies on glibc heap APIs: > > > > > > 1. "rte_eal_alarm_init()" allocates an interrupt instance > > > > > > which is used for timerfd, is called before > > > > > > "rte_eal_memory_init()" which does the memseg init. > > > > > > Not sure what all challenges we may face in moving alarm_init > > > > > > after memory_init as it might break some subsystem inits. > > > > > > Other option could be to allocate interrupt instance for > > > > > > timerfd on first alarm_setup call. > > > > > > > > Indeed it is an issue. > > > > > > > > [...] > > > > > > > > > > There are many other drivers which statically declares the > > > > > > interrupt handles inside their respective private structures > > > > > > and memory for those structure was allocated from heap. For > > > > > > such drivers I allocated interrupt instances also using glibc h= eap > APIs. > > > > > > > > Could you use rte_malloc in these drivers? > > > > > > If we take the direction of 2 different allocations mode for the > > > interrupts, I suggest we make it automatic without any API parameter. > > > We don't have any function to check rte_malloc readiness I think. > > > But we can detect whether shared memory is ready with this check: > > > rte_eal_get_configuration()->mem_config->magic =3D=3D RTE_MAGIC This > > > check is true at the end of rte_eal_init, so it is false during probi= ng. > > > Would it be enough? Or should we implement rte_malloc_is_ready()? > > > > Hi Thomas, > > > > It's a very good suggestion. Let's implement "rte_malloc_is_ready()" > > which could be as simple as " rte_eal_get_configuration()->mem_config- > >magic =3D=3D RTE_MAGIC" check. > > There may be more consumers for this API in future. >=20 > You cannot rely on the magic because it is set only after probing. > For such API you need to have another internal flag to check that malloc = is > setup. Yeah, got that. You mean in case of bus probing although rte_malloc is setu= p but eal_mcfg_complete() is calledt done yet. So we should set another mallo= c specific flag at the end of rte_eal_memory_init(). Correct? But just for understanding, as David suggested that we preserve keep this f= lag then why not use it, have rte_malloc and malloc bits and make a decision. Let driver has the flexibility to choose. Do you see any harm in this? Thanks Harman >=20