On Thu, Oct 18, 2018 at 5:26 PM Burakov, Anatoly [off-list ref]
wrote:

On 27-Sep-18 1:30 PM, Alejandro Lucero wrote:

quoted

Invoking rte_pci_read/write_config functions requires device with
a intr_handle type for using VFIO or UIO driver related functions.

Secondary processes rely on primary processes for device initialization
so they do not usually require using these functions. However, some PMDs,
like NFP PMD, require using these functions even for secondary processes.

Signed-off-by: Alejandro Lucero <redacted>
---

Hi Alejandro,

I’m curious of consequences of setting intr handle to a valid value when
we don’t have an interrupt thread. Something may try to use it (although
I couldn’t find any such usage).

The point is secondary processes do not deal with interrupts so I assume
setting the type does not change anything but it allows to use PCI
read/write functions by secondary processes.

PCI config read really uses intr handle type to discover userspace
driver type – this seems ever so slightly wrong, and looks like
something that should be part of rte_device somewhere, independent of
interrupt types. Do we have any other alternative to do the same thing
(i.e. know what userspace driver is used for a particular PCI device)?

I agree current way not being specially good.

Your comment has reminded me there is another way: just using the kdrv
field from the rte_pci_device struct. I have code using that field for
doing a different thing in the NFP PMD depending on the driver in use, UIO
or VFIO. So I think a better patch would be just to modify those pci
functions for using kdrv field instead.

Adding Ferruh in the thread for commenting on this potential change.

--
Thanks,
Anatoly