Re: [dpdk-dev] [PATCH] bus/pci: optimize pci device probe

[David Marchand <david.marchand@redhat.com>]

On Sun, Apr 26, 2020 at 10:06 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 26/04/2020 20:41, Jerin Jacob:
> > On Sun, Apr 26, 2020 at 11:38 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > 26/04/2020 19:38, jerinj@marvell.com:
> > > > From: Jerin Jacob <jerinj@marvell.com>
> > > >
> > > > If the PCI device is not attached to any driver then there is no
> > > > point in probing it. As an optimization, skip the PCI device probe if
> > > > the PCI device driver of type RTE_KDRV_NONE.
> > > >
> > > > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> > > > ---
> > > > Notes:
> > > > ------
> > > > - virtio drivers does special treatment based on RTE_KDRV_UNKNOWN, That is
> > > > the reason allowing RTE_KDRV_UNKNOWN in this patch.
> > > > - virio devices uses RTE_KDRV_UNKNOWN for some special meaning, IMO, if it would
> > > >   be better, if
> > > > a) Introduce the KDRV for virio
> > > > b) If the PCIe device of driver type NONE or UNKNOWN then not even add in pci
> > > > list
> > > > in the scan, It will improve the boot time by avoiding operation on
> > > > unwanted device like sorting the PCI devices, scanning it, probe it, managing
> > > > it etc.
> > >
> > > mlx4/mlx4 uses RTE_KDRV_UNKNOWN.
> >
> > OK.
> >
> > > > - Initial problem reported at http://patches.dpdk.org/patch/64999/ as
> > > > boot time printf clutter on octeontx2 devices with a lot PCI devices which are
> > > > of type RTE_KDRV_NONE.
> > >
> > > Add a logtype for PCI driver and adjust log level accordingly
> > > to your preferences.
> > >
> > > > @@ -271,6 +271,8 @@ pci_probe_all_drivers(struct rte_pci_device *dev)
> > > >       FOREACH_DRIVER_ON_PCIBUS(dr) {
> > > > +             if (dev->kdrv == RTE_KDRV_NONE)
> > > > +                     continue;
> > > >               rc = rte_pci_probe_one_driver(dr, dev);
> > >
> > > Nack
> >
> > I understand mlx4/mlx5 is using RTE_KDRV_UNKNOWN, Here we are skipping
> > the RTE_KDRV_NONE,
> > What is the use case for probing the devices with RTE_KDRV_NONE?
>
> Maybe you are right. I don't remember the use case.
> I think I remember these virtio and vmxnet3 PMD were not using UIO:
>         http://git.dpdk.org/old/virtio-net-pmd/tree/virtio_user.c
>         http://git.dpdk.org/old/vmxnet3-usermap/tree/pmd/vmxnet3.c
>
> We need to know which case is using following code:
>
>     case RTE_KDRV_NONE:
> #if defined(RTE_ARCH_X86)
>         ret = pci_ioport_map(dev, bar, p);
> #endif
>         break;
>
> David, please could you refresh our memory?

The in-tree virtio-net driver directly calls rte_pci_map_device /
rte_pci_ioport_map depending on virtio legacy/modern modes.
This is why the virtio pci driver does not ask for
RTE_PCI_DRV_NEED_MAPPING to the pci bus.


In ioport mode, there were two options for historical reasons because
of the virtio driver you mention.
This driver did not rely on uio, and this behavior was later merged to
the current in-tree driver.
It ended up (not clean) in the pci bus driver because virtio was the
only user of this code.


Removing this special case could break x86 applications running with
legacy virtio.


On the plus side, we have been announcing for some time in virtio:
RTE_PMD_REGISTER_KMOD_DEP(net_virtio, "* igb_uio | uio_pci_generic | vfio-pci");


-- 
David Marchand