From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <maxime.coquelin@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dpdk.org (Postfix) with ESMTP id 53FA33250
for <dev@dpdk.org>; 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 <santosh.shukla@caviumnetworks.com>, 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>
<b9c17b6c-85ca-e0af-0fef-b80181b0e43a@caviumnetworks.com>
From: Maxime Coquelin <maxime.coquelin@redhat.com>
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: <b9c17b6c-85ca-e0af-0fef-b80181b0e43a@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.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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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<santosh.shukla@caviumnetworks.com>
>>> Signed-off-by: Jerin Jacob<jerin.jacob@caviumnetworks.com>
>>> ---
>>> 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
>