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 53FA33250 for ; Tue, 11 Jul 2017 14:07:36 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2FC6A8046E; Tue, 11 Jul 2017 12:07:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2FC6A8046E Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2FC6A8046E 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 AC9826A750; Tue, 11 Jul 2017 12:07:30 +0000 (UTC) To: santosh , 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> <6e4a6ea0-5d42-38d4-6a82-9826b3ba234e@redhat.com> From: Maxime Coquelin Message-ID: <33a7341e-dd92-5943-7d39-032325591da3@redhat.com> Date: Tue, 11 Jul 2017 14:07:28 +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: 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 11 Jul 2017 12:07:35 +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 12:07:36 -0000 On 07/11/2017 12:35 PM, santosh wrote: > Hi Maxime, > > On Tuesday 11 July 2017 02:39 PM, Maxime Coquelin wrote: > >> >> >> 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. >> > Agree, How about renaming to RTE_PCI_DRV_IOVA_AS_VA, make sense? Yes, and if one day we have some hw only supporting VA, then we could introduce RTE_PCI_DRV_IOVA_AS_VA_ONLY. Thanks > > Thanks. > >> Maxime >