Hello David, I am confused a bit. I started to review the "[PATCH 0/9] prepare for rte_device / rte_driver" series and then I've noticed there are 2 patch series having "pci: no need for dynamic tailq init" patch there. But then, there is this v2 that does not have this patch. What is the right one? What should I look at. Is related?
Regards Jan On Fri, 29 Jan 2016 15:49:04 +0100 David Marchand <david.marchand at 6wind.com> wrote: > Before 2.2.0 release, while preparing for more changes in eal (and fixing > a problem reported by Roger M. [1]), I came up with this (part of) patchset > that tries to make the pci code more compact and easier to read. > > I ended up introducing some hooks in the pci layer to customize pci > blacklist / whitelist handling and make it possible to automatically > bind / unbind pci devices to igb_uio (or equivalent) when attaching > a device. > > I am still not really happy: > - the pci blacklist / whitelist makes me think we should let the > application tell eal which resources to use and get rid of the > unconditional pci scan code, which means removing rte_eal_pci_probe() > from rte_eal_init(), and remove rte_eal_dev_init() for vdevs, > - the more I look at this, the more I think automatic bind / unbind for > pci devices should be called from the pmd context. The drivers know best > what they require and what they want to do with the resources passed by > the eal (see the drv_flags / RTE_KDRV_NONE / rte_eal_pci_map_device stuff > for virtio pmd). > This behaviour would still be optional, on a per-device basis. > > So, I think that these hooks are not that good of an idea and I kept > them private for now, but anyway, sending this for comments. > > > Changes since v1: > - split the initial patchset. This current patchset now depends on > [2] sent separately which should be applied first, > - introduced hooks in pci common code, > - implemented automatic bind / unbind for "uio" pci devices > > > [1] http://dpdk.org/ml/archives/dev/2015-November/028140.html > [2] http://dpdk.org/ml/archives/dev/2016-January/032387.html > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
