On Thu, Oct 18, 2018 at 5:26 PM Burakov, Anatoly <anatoly.bura...@intel.com> wrote:
> On 27-Sep-18 1:30 PM, Alejandro Lucero wrote: > > 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 <alejandro.luc...@netronome.com> > > --- > > 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 >
