[dpdk-dev] [PATCH v3 09/12] virtio: vfio: Enable RTE_PCI_DRV_NEED_MAPPING flag in driver
On Thu, Jan 7, 2016 at 11:50 PM, Stephen Hemminger wrote: > On Thu, 7 Jan 2016 22:03:06 +0530 > Santosh Shukla wrote: > >> +#ifdef RTE_EAL_VFIO >> + .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_DETACHABLE, >> +#else >> .drv_flags = RTE_PCI_DRV_DETACHABLE, >> +#endif > > Since VFIO is determined at runtime not compile time, the flags should > be updated at runtime not compile time. > > In general, Yes, Its a wrong approach i..e. Wrapping __need_mapping flag only for vfio case. I am thinking to add vfio parser routine something similar to virtio_xxx_xx_uio_xx() / virtio_xx_xx_ioport() currently exist. This will remove RTE_EAL_VFIO ifdef clutter for this patch and [08/12] patch and also virtio pmd driver can then initialize device for vfio mode.. _but_ I still need _MAPPING flag enabled for in virtio driver as because for vfio case - I want vfio_xx_mmap() routine to create vfio container/group_id and then create vfio_dev_fd for each virtio-net-pci interface. Let me know my approach aligned to your suggestion.
[dpdk-dev] [PATCH v3 03/12] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()
On Thu, Jan 7, 2016 at 11:44 PM, Stephen Hemminger wrote: > On Thu, 7 Jan 2016 22:03:00 +0530 > Santosh Shukla wrote: > >> #else >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) >> + return 0; /* iopl syscall not supported for ARM/ARM64 */ >> +#endif >> return -1; >> #endif > > Minor net why not: > > #elif defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > return -1 > #else > > That way you won't generate two return statements and potentially > trigger warnings from static checkers. returning -1 would fail for arm/arm64. I guess you meant return 0, right? if so then would need one more return for non-x86/non-arm case. Also I am working on another patchset suggested by Jerin [1] on iopl() in v2 series, That new patchset intended to get rid-off ifdef X_86 clutter for sys/io.h and more iop() definition to arch/platform file. I don't want to include those changes in v3 series as because it seems like two different topic. [1] http://dpdk.org/dev/patchwork/patch/9533/
