From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 21A3E236 for ; Wed, 11 Oct 2017 09:04:39 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2017 00:04:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,360,1503385200"; d="scan'208";a="908795259" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 11 Oct 2017 00:04:38 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 11 Oct 2017 00:04:38 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 11 Oct 2017 00:04:37 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.159]) with mapi id 14.03.0319.002; Wed, 11 Oct 2017 15:04:35 +0800 From: "Tan, Jianfeng" To: santosh , "olivier.matz@6wind.com" , "dev@dpdk.org" CC: "thomas@monjalon.net" , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "aconole@redhat.com" , "stephen@networkplumber.org" , "Burakov, Anatoly" , "gaetan.rivet@6wind.com" , "shreyansh.jain@nxp.com" , "Richardson, Bruce" , "Gonzalez Monroy, Sergio" , "maxime.coquelin@redhat.com" Thread-Topic: [dpdk-dev] [PATCH v10 3/9] linuxapp/eal_pci: get iommu class Thread-Index: AQHTPpL+QoBFGNVWnE2b1ST6YRIH8aLd6K0A//+rGgCAAJOPAP//e5mAgACLMVA= Date: Wed, 11 Oct 2017 07:04:35 +0000 Message-ID: References: <20170920112356.17629-1-santosh.shukla@caviumnetworks.com> <20171006110346.13247-1-santosh.shukla@caviumnetworks.com> <20171006110346.13247-4-santosh.shukla@caviumnetworks.com> <02200f40-8158-27ec-02c1-aa5ba92e824a@caviumnetworks.com> <15d6938c-43dd-9301-71e4-b32a78765fb4@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v10 3/9] linuxapp/eal_pci: get iommu class 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: , X-List-Received-Date: Wed, 11 Oct 2017 07:04:40 -0000 > -----Original Message----- > From: santosh [mailto:santosh.shukla@caviumnetworks.com] > Sent: Wednesday, October 11, 2017 1:38 PM > To: Tan, Jianfeng; olivier.matz@6wind.com; dev@dpdk.org > Cc: thomas@monjalon.net; jerin.jacob@caviumnetworks.com; > hemant.agrawal@nxp.com; aconole@redhat.com; > stephen@networkplumber.org; Burakov, Anatoly; gaetan.rivet@6wind.com; > shreyansh.jain@nxp.com; Richardson, Bruce; Gonzalez Monroy, Sergio; > maxime.coquelin@redhat.com > Subject: Re: [dpdk-dev] [PATCH v10 3/9] linuxapp/eal_pci: get iommu class >=20 >=20 > On Wednesday 11 October 2017 11:01 AM, Tan, Jianfeng wrote: > > > > > > On 10/11/2017 12:43 PM, santosh wrote: > >> On Wednesday 11 October 2017 07:17 AM, Tan, Jianfeng wrote: > >>> Hi, > >>> > >>> Nice patch series. But I still have a small question about below flag= . > >>> > >>> > >>> On 10/6/2017 7:03 PM, Santosh Shukla wrote: > >>>> Get iommu class of PCI device on the bus and returns preferred iova > >>>> mapping mode for that bus. > >>>> > >>>> Patch also introduces RTE_PCI_DRV_IOVA_AS_VA drv flag. > >>>> Flag used when driver needs to operate in iova=3Dva mode. > >>>> > >>> Does this flag indicate a must to use VA as IOVA, or a nice-to-have o= ne? > In detail, above commit log says, "needs to operate in iova=3Dva mode", b= ut > the comment in the patch indicates this flag means "driver supports IOVA = as > VA". > >>> > >>> If it's the latter case, I would suppose all drivers support to use V= A as > IOVA, if the NICs are binded to vfio-pci (iommu mode). Please correct me = if > I'm wrong. > >>> > >> - Any iommu backed pmd could choose to use this flag. > > > > But if this is characterized by assumption for all PMDs, why do we trou= ble > to introduce this flag. > > > to hint bus layer about iova=3Dva mapping choice for _this_ driver and de= fault > is iova=3Dpa. >=20 So that sounds if this flag is set by some PMD, we must use iova=3Dva. Then how about we enable this, iova=3Dva, if only all PCI devices are binde= d to vfio-pci (iommu mode)? Thanks, Jianfeng