From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id E30E55398 for ; Tue, 11 Jul 2017 11:09:57 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 70E387D0E4; Tue, 11 Jul 2017 09:09:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 70E387D0E4 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 70E387D0E4 Received: from [10.36.112.40] (ovpn-112-40.ams2.redhat.com [10.36.112.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0B7BA18361; Tue, 11 Jul 2017 09:09:51 +0000 (UTC) To: Santosh Shukla , thomas@monjalon.net, dev@dpdk.org Cc: bruce.richardson@intel.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com, sergio.gonzalez.monroy@intel.com, anatoly.burakov@intel.com, stephen@networkplumber.org, olivier.matz@6wind.com References: <20170710114235.18970-1-santosh.shukla@caviumnetworks.com> <20170711061631.5018-1-santosh.shukla@caviumnetworks.com> <20170711061631.5018-2-santosh.shukla@caviumnetworks.com> From: Maxime Coquelin Message-ID: <6e4a6ea0-5d42-38d4-6a82-9826b3ba234e@redhat.com> Date: Tue, 11 Jul 2017 11:09:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170711061631.5018-2-santosh.shukla@caviumnetworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 11 Jul 2017 09:09:56 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 01/11] eal/pci: introduce PCI driver iova as va flag 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: Tue, 11 Jul 2017 09:09:58 -0000 On 07/11/2017 08:16 AM, Santosh Shukla wrote: > Introducing RTE_PCI_DRV_NEED_IOVA_VA flag. Flag used when driver needs > to operate in iova=va mode. > > Why driver need iova=va mapping? > > On NPU style co-processors like Octeontx, the buffer recycling has been > done in HW, unlike SW model. Here is the data flow: > 1) On control path, Fill the HW mempool with buffers(iova as pa address) > 2) on rx_burst, HW gives you IOVA address(iova as pa address) > 3) As application expects VA to operate on it, rx_burst() needs to > convert to _va from _pa. Which is very expensive. > Instead of that if iova as va mapping, we can avoid the cost of > converting with help of IOMMU/SMMU. > > Signed-off-by: Santosh Shukla > Signed-off-by: Jerin Jacob > --- > lib/librte_eal/common/include/rte_pci.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h > index 8b123391c..ac79040dd 100644 > --- a/lib/librte_eal/common/include/rte_pci.h > +++ b/lib/librte_eal/common/include/rte_pci.h > @@ -202,6 +202,8 @@ struct rte_pci_bus { > #define RTE_PCI_DRV_INTR_RMV 0x0010 > /** Device driver needs to keep mapped resources if unsupported dev detected */ > #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020 > +/** Device driver needs iova as va */ > +#define RTE_PCI_DRV_NEED_IOVA_VA 0X0040 > Maybe not a big deal, but using NEED tends to say that the driver cannot work if not using VA as IOVA. If my understanding is correct, this is not the case, the performance will be poor but the device will be functional. Maxime