[dpdk-dev,v3,01/11] eal/pci: introduce PCI driver iova as va flag

Message ID 20170711061631.5018-2-santosh.shukla@caviumnetworks.com (mailing list archive)
State Superseded, archived
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation fail Compilation issues

Commit Message

Santosh Shukla July 11, 2017, 6:16 a.m. UTC
  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(+)
  

Comments

Maxime Coquelin July 11, 2017, 9:09 a.m. UTC | #1
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.

Maxime
  
Santosh Shukla July 11, 2017, 10:35 a.m. UTC | #2
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?

Thanks.

> Maxime
  
Maxime Coquelin July 11, 2017, 12:07 p.m. UTC | #3
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
>
  

Patch

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
 
 /**
  * A structure describing a PCI mapping.