[dpdk-dev] [PATCH 00/10] Infrastructure to detect iova mapping on the bus

santosh santosh.shukla at caviumnetworks.com
Wed Jul 5 11:47:48 CEST 2017


Hi Maxime,

On Wednesday 05 July 2017 03:00 PM, Maxime Coquelin wrote:

>
> On 06/08/2017 01:05 PM, Santosh Shukla wrote:
>> Q) Why do we need such infrastructure?
>>
>> A) Some NPU hardware like OCTEONTX follows push model to get the packet
>> from the pktio device. Where packet allocation and freeing done
>> by the HW. Since HW can operate only on IOVA with help of SMMU/IOMMU,
>> when packet receives from the Ethernet device, it is the IOVA address
>> (which is PA in existing scheme).
>>
>> Mapping IOVA as PA is expensive on those HW, where every packet
>> needs to be converted to VA from PA/IOVA.
>>
>> This patchset proposes the method to autodetect the preferred
>> IOVA mode for a device. Summary of IOVA scheme:
>> - If all the devices are iommu capable and support IOMMU
>>    capable driver then selects IOVA_VA.
>> - If any of the devices are non-iommu then use default IOVA
>>    scheme ie. IOVA_PA.
>> - If no device found then IOVA scheme would be
>>    IOVA_DC (Don't care).
>
> Isn't it possible to have a per-device granularity?
> For example, with virt case, having a physical NIC using VFIO with
> iommu, and virtio devices with noiommu.
>
At device level granularity, Classification will fall under with iommu and
w/o iommu category.

Like in your example, virtio and physical NIC classified under with iommu and w/o iommu category.
And best way to detect with or w/o iommu is bus layer. That way bus could decide
upon iova mapping mode. Note that iova mapping rules are not enforced. User can
alway override iova-mode mapping.

> If the physical NIC prefers working with VAs, why forcing it to use
> PAs? Maybe I missed a limitation though.
>
With this patch set, if physical NIC + iommu/vfio then mapping mode is iova=va which is 
what you mentioned.

Thanks.

> Cheers,
> Maxime



More information about the dev mailing list