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