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 1913EA0471 for ; Mon, 15 Jul 2019 18:28:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 082BD2E81; Mon, 15 Jul 2019 18:28:07 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 11BDF2C6A for ; Mon, 15 Jul 2019 18:28:04 +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 x6FGPFUG002839; Mon, 15 Jul 2019 09:28:01 -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=7xymRNSTIqB+YdWFbBMuGlkirw1OAGmcX4WcgOhMm3w=; b=d4yquL4dQ6jGnM+5isqrbQD+4RnBYruSwbMlYqyWCuO6uRjiOQ2dxOI4p9Id2SCOqYFo SGuDmjGjMPQq+Rc4a0TcLaXXoKuR8Eq5zvsW6WwOzv+HYwKJHelHSHrA9H+iqej2AOaL X3jasooXRz1qQqYJTC//N7lKNUCR2K6Ff8QZEgg+9JMdxw2gNyqPjr/PqmDla3mNJzCu spozhJ50zXvGB5XAxSVkrQhOCenI8XdSm3rIoIJDCd0Tg1aY+dwKBB9M0MuGR2YD+p0N v3q/MikuYZht6N5iCgZ3V6/VkssdXXzZTL7JyOmrTlKgZP2p5M4lcZ+6yHijFLLoTLoE qA== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 2tqcnprc7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 Jul 2019 09:28:01 -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; Mon, 15 Jul 2019 09:27:58 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.51) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 15 Jul 2019 09:27:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GyJYqpUZUFcQhmvvUjcjE2vDLy+P8TCw5NjxY0AawytbRtslv3gvep3DR40xwIKS5w7ByR8z6mOIXuEeWGzw7h3GtUFZ3E8nJ9qnZyDYSLB2BoyMZWFLC5Mq2Ro9Dc5VYW0jmzFjhsKvMdlVp4cyaQviuG7FZpbCX8j5goaq7yFf6dTeCt3dMFSrAFM720aMH0NECgu4hZXyYDhnytOsGscnFX5SMq1EM2BnYu4V3O7kiSgf287yzZNpaI4LVx8Hr+jOzc15fF2mpoWD6RfZdrwW5/LsYkuGHen8wnwVtDnKqv9WIQnf+ZmSh1wcgE8a9lA1LClFcXhJFPN94jkK3w== 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=7xymRNSTIqB+YdWFbBMuGlkirw1OAGmcX4WcgOhMm3w=; b=QyPB269t7jWpXWoJInJLPfNuVP/1g/CmYXDjN1IjCoWJYs/+9Hyxsxb7KS6Z8VhRKyIPVN1l7+osxjV0ThkXOGVTvgDKaG67zgu02AnMMMGAwx3vXN+SxJ0qdbpAHgbKzTUTt2zBYMUuBQJ+YNqUsskW/JkcfJm3Hk//Q41vBO3g8bKUCXMeRypfxS1jwaRsyUt7hQOk2fdbGTrxDbt6wqTCOS5SDFCC0H5o9NbimxGhWnoIHyGipSQh3qNpnN1IKFm2QYLVmryYeCzRY6xpo3ywXEPN4QdSjvcQR5IlFZzI7mk88g0tGoAm0ebxhR4Ya8iT7GvqViSTPPo1cqGaCA== 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=7xymRNSTIqB+YdWFbBMuGlkirw1OAGmcX4WcgOhMm3w=; b=TGqK4F931t+ixcYo78kotnXOwFGvKuzr99wmfBD5mzhmsypg6myiP+kvj/DEmXpLOJUzoCj4rJbmnqWu2mAPPEQXu592I4wH1sq7i4ymkZgvQVqr5wGRwEjoh1EtcMyfvu3mCR5yOGL5y6lIVj+4Bx/QIVKa2olJ5Owe9VoIUs8= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2485.namprd18.prod.outlook.com (20.179.92.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 16:27:53 +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; Mon, 15 Jul 2019 16:27:53 +0000 From: Jerin Jacob Kollanukkaran To: Thomas Monjalon CC: "Burakov, Anatoly" , David Marchand , "dev@dpdk.org" , John McNamara , Marko Kovacevic , "Igor Russkikh" , Pavel Belous , Ajit Khaparde , Somnath Kotur , Wenzhuo Lu , John Daley , Hyong Youb Kim , Qi Zhang , Xiao Wang , Beilei Xing , Jingjing Wu , Qiming Yang , "Konstantin Ananyev" , Matan Azrad , Shahaf Shuler , Yongseok Koh , Viacheslav Ovsiienko , Alejandro Lucero , Nithin Kumar Dabilpuram , Kiran Kumar Kokkilagadda , Rasesh Mody , Shahed Shaikh , Bruce Richardson , "alialnu@mellanox.com" , "aconole@redhat.com" Thread-Topic: [PATCH 2/2] eal: fix IOVA mode selection as VA for pci drivers Thread-Index: AQHVN2lUvS4FC9UUg0eo3J1cfmDleKbG1AEAgAAcB4CABNF8gIAADJgAgAABjkCAABAFAIAAAV4Q Date: Mon, 15 Jul 2019 16:27:52 +0000 Message-ID: References: <1562795329-16652-1-git-send-email-david.marchand@redhat.com> <71077296.xTBSyl0q4B@xps> <1689145.QdohnT2lii@xps> In-Reply-To: <1689145.QdohnT2lii@xps> 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: d8e3e220-a1b9-4f3b-623a-08d7094162ba x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2485; x-ms-traffictypediagnostic: BYAPR18MB2485: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(13464003)(52314003)(43544003)(189003)(199004)(68736007)(6306002)(7696005)(55016002)(478600001)(76116006)(66946007)(66446008)(66476007)(66556008)(53546011)(6436002)(64756008)(5660300002)(6246003)(4326008)(6506007)(966005)(99286004)(7416002)(9686003)(8936002)(316002)(2906002)(81156014)(81166006)(53936002)(229853002)(6116002)(3846002)(486006)(446003)(11346002)(25786009)(52536014)(102836004)(7736002)(305945005)(476003)(8676002)(256004)(186003)(86362001)(33656002)(74316002)(76176011)(561944003)(6916009)(54906003)(26005)(66066001)(14454004)(71190400001)(71200400001)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2485; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: +7GSsJCviNIpsYP2fX/Jdj3p49P7lD6o8vcVLjYi9RuybfKXtYqUQAO9okFah/hNHM6Y7JKs2Ya0SK67z0f03/V6lBlhiL5NiNR+tnp+47C/BuKHvGs7rWm44OxzjofWAgc+lhD69zw2zPmtRNi4TyrKphLB98FOG3aJmy9NR/nfDLxrzoVyhYh2oZ9672UnUALUNNxCF5aSUQOh11bV9QLpOd9QsyRT+HOfsC+RiCK8NaicP8TT08/LRiabvtLCx6nJUGuABXEo2X6fa7xa9kgfc4ymbN+x5HYgW9aCeoR76ZIk8k7mC3krzp9DBP7LqblOVY8ckcjy1igDoBDcsnxIVpXC71ZENh51xDgwDhN6T4s6J9VVhWUeLzephU/gG9N3nCIld6urPCi03q01kUj4O8CMyQv4raJ8wHS2kBY= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d8e3e220-a1b9-4f3b-623a-08d7094162ba X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 16:27:52.5643 (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: BYAPR18MB2485 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-15_05:2019-07-15,2019-07-15 signatures=0 Subject: Re: [dpdk-dev] [PATCH 2/2] eal: fix IOVA mode selection as VA for pci drivers 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: Thomas Monjalon > Sent: Monday, July 15, 2019 9:36 PM > To: Jerin Jacob Kollanukkaran > Cc: Burakov, Anatoly ; David Marchand > ; dev@dpdk.org; John McNamara > ; Marko Kovacevic > ; Igor Russkikh > ; Pavel Belous ; > Ajit Khaparde ; Somnath Kotur > ; Wenzhuo Lu ; > John Daley ; Hyong Youb Kim ; > Qi Zhang ; Xiao Wang ; > Beilei Xing ; Jingjing Wu ; > Qiming Yang ; Konstantin Ananyev > ; Matan Azrad ; > Shahaf Shuler ; Yongseok Koh > ; Viacheslav Ovsiienko > ; Alejandro Lucero > ; Nithin Kumar Dabilpuram > ; Kiran Kumar Kokkilagadda > ; Rasesh Mody ; Shahed > Shaikh ; Bruce Richardson > ; alialnu@mellanox.com; > aconole@redhat.com > Subject: Re: [PATCH 2/2] eal: fix IOVA mode selection as VA for pci drive= rs >=20 > 15/07/2019 17:35, Jerin Jacob Kollanukkaran: > > From: Thomas Monjalon > > > 15/07/2019 16:26, Jerin Jacob Kollanukkaran: > > > > > > Is there any specific reason why we always prefer PA if > > > > > > physical addresses are available? Since we're already assuming > > > > > > that all devices support PA and VA anyway, what's the harm in > > > > > > enabling VA by > > > default? > > > > > > > > > > If PA is available, it means we are running as root. > > > > > We can assume that using root is a choice, probably related to a > > > > > preference for PA. > > > > > > > > # Even if we are running as root, Why to choose PA in case of DC? > > > > ie. Following logic is not need > > > > if (iova_mode =3D=3D RTE_IOVA_DC) { > > > > iova_mode =3D phys_addrs ? RTE_IOVA_PA : RT= E_IOVA_VA; > > > > RTE_LOG(DEBUG, EAL, > > > > "Buses did not request a specific I= OVA mode, using '%s' > > > based on physical addresses availability.\n", > > > > phys_addrs ? "PA" : "VA"); > > > > } > > > > > > Why running as root if using VA anyway? > > > We can assume the user knows what he is doing, so it is a user choice= . > > > We want to allow the user choosing, right? > > > > The user can override iova=3Dpa/va as eal argument if user needs to run= a > specific mode. > > Running as root for various other reason(just be lazy) etc. it is not > > or it should not be connected to set the mode as PA. >=20 > Good point. > I tend to prefer avoiding the use of EAL arguments because they may be > unavailable, depending on the application. Yes. The default case suffice the requirement here.ie when it DC chosen fro= m bus layer select the VA. I don't see any point in overriding that. It is a good default. Do you think any case where it need to be "changed"? If not, let stick with VA i.e until unless if there no HARD requirement for= PA. i.e Stayaway from PA WHEN possible. >=20 > > > > # When DPDK running on guest, Anyway it can not access the real > > > > PA, It will > > > be IPA. > > > > > > What is IPA? Isn't it a beer? > > > > There may a beer with that name. In this context, it is "Intermediate > physical address" > > > > > > So I don't understand logic behind choose PA when DC. > > > > To me, it make sense to choose PA when DC. > > > > > > You probably mean "choose VA". > > > > Yup. > > > > > > # To align with RTE_PCI_DRV_NEED_MAPPING flag and reflect it "need" > > > > rather than support, I think, flag can be changed to > > > > RTE_PCI_DRV_NEED_IOVA_AS_VA > > > > > > I think the most important is to have a good documentation of this > > > flag (it was not done properly when Cavium introduced it initially). > > > If you want to rename the flag, you can do it in a separate patch. > > > If renaming, I really would like to get an answer to an old question: > > > Why IO adress is called IOVA? The name "IOVA_AS_VA" looks strange. > > > > IOVA =3D IO virtual address > > Since IOVA can be PA or VA, the name IOVA_AS_VA as chosen >=20 > We could also call it "bus address" or "device address". > I think the word "IOVA" was enforced by Linux. > Anyway, my real issue when using "virtual" is that we don't really know w= hat > we are talking about: is it an IOMMU translated address on the device sid= e or > an MMU translated address on the application side? Actually in linux kernel, it creates the same mapping for device and CPU so= =20 user both can access the very same address. In this context, IOVA means, Virtual address for device. The OS can do same mapping in CPU MMU tables as= well. >=20 > I think we should better explain things. > One diagram which can help: > https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_managem > ent_unit#/media/File:MMU_and_IOMMU.svg >=20 > > > For reference, one description of addressing: > > > https://lists.linuxfoundation.org/pipermail/iommu/2018-May/027686.ht > > > ml > > > > > > About the naming, do you remember how I insisted to have a correct > > > naming of all related stuff in DPDK? It was hard to get it accepted, > > > the discussion was not nice and I stopped insisting to get all detail= s fine > because I just got bored. > > > It was a really bad experience. > > > > I agree. > > To me that bad experience was due to mostly not having enough > > technical comments On the proposal. Though I am not the author/owner of > it. > > > > > You can ask why I remind this now? Because we must take care of all > > > details, make sure our messages are well understood, and be > cooperative. > > > > No disagreement. > > If we see the history the meaning got changed/updated in this commit > > By adding intel drivers to it. I would nt say it is big ideal, It > > just C code, It can be changed based on the need. I think, what really > > import is, maintain the the feature and commitment towards fixing any > issue. > > > > commit f37dfab21c988d2d0ecb3c82be4ba9738c7e51c7 > > Author: Jianfeng Tan > > Date: Wed Oct 11 10:33:48 2017 +0000 > > > > drivers/net: enable IOVA mode for Intel PMDs > > > > If we want to enable IOVA mode, introduced by > > commit 93878cf0255e ("eal: introduce helper API for IOVA mode"), > > we need PMDs (for PCI devices) to expose this flag. > > > > Signed-off-by: Jianfeng Tan > > Acked-by: Anatoly Burakov > > Reviewed-by: Santosh Shukla >=20 > The doxygen meaning did not change from day one: > /** Device driver supports IOVA as VA */ But the commit log > meaning was: > "Flag used when driver needs to operate in iova=3Dva mode." > And the Intel commit log had a different understanding: > "If we want to enable IOVA mode, [..] we need PMDs [..] to expose > this flag." >=20 > Anyway we agree on the new meaning to be the original one the author had > in mind (i.e. "driver needs"). >=20 > > > > Other than above points, > > > > Reviewed this patch and tested on octeontx2, It looks good to me. >=20 >=20