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 69E89A00E6 for ; Tue, 9 Jul 2019 13:40:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 527094C94; Tue, 9 Jul 2019 13:40:25 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 1B11A37A2 for ; Tue, 9 Jul 2019 13:40:22 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 04:40:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,470,1557212400"; d="scan'208";a="165740773" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.82]) ([10.237.220.82]) by fmsmga008.fm.intel.com with ESMTP; 09 Jul 2019 04:40:18 -0700 To: Jerin Jacob Kollanukkaran , David Marchand Cc: dev , Thomas Monjalon , Ben Walker References: <20190708142450.51597-1-jerinj@marvell.com> From: "Burakov, Anatoly" Message-ID: <0947c33d-b3be-1acc-f98e-3635cc5658d2@intel.com> Date: Tue, 9 Jul 2019 12:40:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: fix IOVA as VA mode selection 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" On 09-Jul-19 12:13 PM, Jerin Jacob Kollanukkaran wrote: >> -----Original Message----- >> From: Burakov, Anatoly >> Sent: Tuesday, July 9, 2019 3:15 PM >> To: Jerin Jacob Kollanukkaran ; David Marchand >> >> Cc: dev ; Thomas Monjalon ; Ben >> Walker >> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: fix IOVA as VA mode >> selection >> >> On 08-Jul-19 8:13 PM, Jerin Jacob Kollanukkaran wrote: >>> See below, >>> >>> Please send the email as text to avoid formatting issue.(No HTML) >>> >>> From: David Marchand >>> Sent: Tuesday, July 9, 2019 12:09 AM >>> To: Jerin Jacob Kollanukkaran >>> Cc: dev ; Thomas Monjalon ; >> Ben >>> Walker ; Burakov, Anatoly >>> >>> Subject: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: fix IOVA as VA mode >>> selection >>> >>> ________________________________________ >>> >>> On Mon, Jul 8, 2019 at 4:25 PM wrote: >>> From: Jerin Jacob >>> >>> Existing logic fails to select IOVA mode as VA if driver request to >>> enable IOVA as VA. >>> >>> IOVA as VA has more strict requirement than other modes, so enabling >>> positive logic for IOVA as VA selection. >>> >>> This patch also updates the default IOVA mode as PA for PCI devices as >>> it has to deal with DMA engines unlike the virtual devices that may >>> need only IOVA as DC. >>> >>> We have three cases: >>> - driver/hw supports IOVA as PA only >>> >>> [Jerin] It is not driver cap, it is more of system cap(IOMMU vs non >>> IOMMU). We are already addressing that case >> >> I don't get how this works. How does "system capability" affect what the >> device itself supports? Are we to assume that *all* hardware support IOVA >> as VA by default? "System capability" is more of a bus issue than an individual >> device issue, is it not? > > What I meant is, supporting VA vs PA is function of IOMMU(not the device attribute). > Ie. Device makes the bus master request, if IOMMU available and enabled in the SYSTEM , > It goes over IOMMU and translate the IOVA to physical address. > > Another way to put is, Is there any _PCIe_ device which need/requires > RTE_PCI_DRV_NEED_IOVA_AS_PA in rte_pci_driver.drv_flags > > Previously, as far as i can tell, the flag was used to indicate support for IOVA as VA mode, not *requirement* for IOVA as VA mode. For example, there are multiple patches [1][2][3][4] (i'm sure i can find more!) that added IOVA as VA support to various drivers, and they all were worded it in this exact way - "support for IOVA as VA mode", not "require IOVA as VA mode". As far as i can tell, none of these drivers *require* IOVA as VA mode - they merely use this flag to indicate support for it. Specifically, from my perspective, the "support for IOVA as VA mode" has in practice always indicated support for VFIO (or similar drivers) as far as the PCI bus is concerned. As in, the device *could* use IOVA as VA mode, but since it may be bound to igb_uio (which doesn't support IOVA as VA), the IOVA as VA mode may not be supported for a particular device. So, a particular device *cannot support* IOVA as VA if it's bound to igb_uio or uio_pci_generic (or VFIO in noiommu mode). This is not *just* a capability thing, but also kernel driver issue. Now suddenly it turns out that someone somewhere "knew" that "IOVA as VA" flag in PCI drivers is supposed to indicate *requirement* and not support, and it appears that this knowledge was not communicated nor documented anywhere, and is now treated as common knowledge. [1] http://patchwork.dpdk.org/patch/53206/ [2] http://patchwork.dpdk.org/patch/50274/ [3] http://patchwork.dpdk.org/patch/50991/ [4] http://patchwork.dpdk.org/patch/46134/ -- Thanks, Anatoly