[dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs

[Thomas Monjalon]

2015-08-31 08:59, Neil Horman:
> On Mon, Aug 31, 2015 at 10:23:33AM +0000, Iremonger, Bernard wrote:
> > The purpose of this RFC is to remove the need for a PCI device driver
> > from Vdev's that that do not use a PCI driver.  Removing the PCI driver
> > is implemented in the ethdev changes. I have modified some of the Vdev's
> > to verify that the ethdev changes work.
> > 
> You didn't remove the relationship of the ethdev to the pci driver though, which
> is really the problem,  An ethdev may reside on any number of bus types
> (pci/usb/vmbus/virt/none).  This patch series just papers over the fact that an
> ethdev is implicitly a pci device by making the assignment of its pci_dev
> pointer optional.  Whats really needed is a way to associate an ethdev with an
> arbitrary bus
> 
> > > What benefit accrues to those vdev
> > > PMDs that implement this change?  What penalty is imposed on those that
> > > do not change?
> > 
> > 6Wind have decided that only cleanup patches will be allowed in future

Not a 6WIND decision. This is a community project.
I gave my opinion regarding maintenance of the code.
I may be wrong but after discussions with others and recent comments, it seems
well justified.

> > for Vdevs that have a dummy PCI driver. Any change in functionality for
> > these Vdevs will not be allowed.
> > Please see email below from 6Wind
> > 
> > http://dpdk.org/ml/archives/dev/2015-July/022107.html
> > 
> I think you misread that.  I think all Thomas is asking for (correct me if I'm
> wrong Thomas), is for someone to start refactoring the ethdev registration code
> so that we can have a single init path without the need for wierd typing and
> differentiation at init time.  He's not going to stop accepting bug fixes for
> existing drivers just because it uses the existing initalization infrastructure.

Yes. Such cleanup can be enforced by rejecting new features on top of these
workarounds. But driver fixes will be accepted.

> I would even go so far as to say new drivers will be accepted for as long as the
> existing init path exists as it does.  We just need to start thinking about how
> to make bus registration independent of ethernet device registration, and while
> your patch series sort of eliminates some of that, its really not a proper
> refactoring of the sort I think Thomas is asking for

Yes
The sooner will be the better :)
Thanks for taking care of this issue.