On Fri, Oct 19, 2018 at 9:02 AM Burakov, Anatoly <anatoly.bura...@intel.com> wrote:
> On 18-Oct-18 5:41 PM, Alejandro Lucero wrote: > > > > > > On Thu, Oct 18, 2018 at 5:26 PM Burakov, Anatoly > > <anatoly.bura...@intel.com <mailto: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 > > <mailto: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. > > > > I definitely think the way you describe would be a better way to fix > this (i.e. use kdrv in PCI config functions rather than intr handle type). > > I will send another patch then. Thanks! > -- > Thanks, > Anatoly >
