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 9AE87A0471 for ; Mon, 15 Jul 2019 17:03:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6E11F1B951; Mon, 15 Jul 2019 17:03:41 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 1FD743423 for ; Mon, 15 Jul 2019 17:03:40 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 44234293C; Mon, 15 Jul 2019 11:03:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 15 Jul 2019 11:03:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=KeNmNKeZmsw4YE6fBcA6C+ZW0+6WA9gMYKgLxaHEbgY=; b=kIMzyvmeal4B /yDmIz6H8WvlpuewV96DBQzh5ws9+iwTFp7YbgLQhVAaiBzVLMJMmDXc3CDdXCUp BByK6rOlCHlO27wyRxN6LUW7UI8w+O3TGj3x/Ijgs00OwTjVpNi79dTecElmae6b XusWJLp3EHVXcTXL292H/5rhVRxR6Xc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=KeNmNKeZmsw4YE6fBcA6C+ZW0+6WA9gMYKgLxaHEb gY=; b=Zf2Q28poRlUGNtciBT5gNYNHJFY3sT3W9UpJ4qQjvmSxCnd0dOzzdbe7v 3rEOXDVhdCJlJwDSl6hd6hUSeBMIpjyB3sA0cev5ZmiwfVX36erWNELvCWX2LzDX x9M2Oal7+PFORkHLfYYGp7cds9W0JCpT9q1qXs93mcaAzD1CnPvwIbatj0lrn8jH 556sm3aRdjLDTAsr8NQAcAiqXWekAaPwoSNe4DHcZ9dmC0wyu1e50Uv2PwYB1ZpK b0X2DzYnpjzJhk081NwbQhNKVCtz8DVjk7HO9tLYrRviG3EdU84erAjl2DU9c1np 7pfeNGuo2QQ//I7+eEioXwwD48OXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrheekgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinheplhhinhhugihfohhunhgurghtihhonhdrohhrghenucfkphepjeejrddufeeg rddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonh hjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 75CE6380084; Mon, 15 Jul 2019 11:03:34 -0400 (EDT) From: Thomas Monjalon 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" Date: Mon, 15 Jul 2019 17:03:32 +0200 Message-ID: <71077296.xTBSyl0q4B@xps> In-Reply-To: References: <1562795329-16652-1-git-send-email-david.marchand@redhat.com> <2927698.45TxNz31xh@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 15/07/2019 16:26, Jerin Jacob Kollanukkaran: > > > > + > > > > +IOVA Mode is selected by considering what the current usable > > > > +Devices on the system requires and/or supports. > > > > + > > > > +Below is the 2-step heuristic for this choice. > > > > + > > > > +For the first step, EAL asks each bus its requirement in terms of > > > > +IOVA mode and decides on a preferred IOVA mode. > > > > + > > > > +- if all buses report RTE_IOVA_PA, then the preferred IOVA mode is > > > > +RTE_IOVA_PA, > > > > +- if all buses report RTE_IOVA_VA, then the preferred IOVA mode is > > > > +RTE_IOVA_VA, > > > > +- if all buses report RTE_IOVA_DC, no bus expressed a preferrence, > > > > +then the > > > > + preferred mode is RTE_IOVA_DC, > > > > +- if the buses disagree (at least one wants RTE_IOVA_PA and at > > > > +least one wants > > > > + RTE_IOVA_VA), then the preferred IOVA mode is RTE_IOVA_DC (see > > > > +below with the > > > > + check on Physical Addresses availability), > > > > + > > > > +The second step is checking if the preferred mode complies with the > > > > +Physical Addresses availability since those are only available to > > > > +root user in recent kernels. > > > > + > > > > +- if the preferred mode is RTE_IOVA_PA but there is no access to > > > > +Physical > > > > + Addresses, then EAL init will fail early, since later probing of > > > > +the devices > > > > + would fail anyway, > > > > +- if the preferred mode is RTE_IOVA_DC then based on the Physical > > > > +Addresses > > > > + availability, the preferred mode is adjusted to RTE_IOVA_PA or > > RTE_IOVA_VA. > > > > + In the case when the buses had disagreed on the IOVA Mode at the > > > > +first step, > > > > + part of the buses won't work because of this decision. > > > > > > 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 == RTE_IOVA_DC) { > iova_mode = phys_addrs ? RTE_IOVA_PA : RTE_IOVA_VA; > RTE_LOG(DEBUG, EAL, > "Buses did not request a specific IOVA 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? > # 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? > 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". > # 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. For reference, one description of addressing: https://lists.linuxfoundation.org/pipermail/iommu/2018-May/027686.html 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 details fine because I just got bored. It was a really bad experience. 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. > Other than above points, > Reviewed this patch and tested on octeontx2, It looks good to me.