Re: [PATCH v2 0/9] pci cleanup and blacklist rework

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 [off-list ref] 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@RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic