From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 344992BE1 for ; Wed, 11 Oct 2017 07:31:56 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 10 Oct 2017 22:31:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,360,1503385200"; d="scan'208";a="1023923310" Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.67.64.69]) ([10.67.64.69]) by orsmga003.jf.intel.com with ESMTP; 10 Oct 2017 22:31:52 -0700 To: santosh , olivier.matz@6wind.com, dev@dpdk.org 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> Cc: thomas@monjalon.net, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, aconole@redhat.com, stephen@networkplumber.org, anatoly.burakov@intel.com, gaetan.rivet@6wind.com, shreyansh.jain@nxp.com, bruce.richardson@intel.com, sergio.gonzalez.monroy@intel.com, maxime.coquelin@redhat.com From: "Tan, Jianfeng" Message-ID: <15d6938c-43dd-9301-71e4-b32a78765fb4@intel.com> Date: Wed, 11 Oct 2017 13:31:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02200f40-8158-27ec-02c1-aa5ba92e824a@caviumnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 05:31:57 -0000 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=va mode. >>> >> Does this flag indicate a must to use VA as IOVA, or a nice-to-have one? In detail, above commit log says, "needs to operate in iova=va mode", but 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 VA 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 trouble to introduce this flag. > - Reasoning for need was performance for our external mempool pmd: avoid phy2virt translation on > mbuf thus save cycles. > Agreed, and it's also for running DPDK without root privilege. Thanks, Jianfeng