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

[Neil Horman]

On Mon, Aug 31, 2015 at 10:23:33AM +0000, Iremonger, Bernard wrote:
> Hi John,
> 
> > -----Original Message-----
> > From: John W. Linville [mailto:linville at tuxdriver.com]
> > Sent: Friday, August 28, 2015 6:52 PM
> > To: Iremonger, Bernard
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs
> > 
> > On Fri, Aug 28, 2015 at 08:15:47AM +0000, Iremonger, Bernard wrote:
> > > Hi John,
> > >
> > > > -----Original Message-----
> > > > From: John W. Linville [mailto:linville at tuxdriver.com]
> > > > Sent: Thursday, August 27, 2015 6:44 PM
> > > > To: Iremonger, Bernard
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs
> > > >
> > > > On Thu, Aug 27, 2015 at 04:40:35PM +0100, Bernard Iremonger wrote:
> > > > > There is a dummy pci driver in the vdev PMD's at present.
> > > > > This RFC proposes to remove the pci driver from the vdev PMD's.
> > > > > Changes have been made to librte_ether to handle vdevs which do
> > > > > not
> > > > have a pci driver.
> > > > >
> > > > > The pdev PMD's should work as before with the changes to
> > > > > librte_ether The vdev PMD's which still have a pci driver should
> > > > > work as before with the
> > > > librte_ether changes.
> > > > >
> > > > > The following vdev PMD's have had the  pci driver removed
> > > > >
> > > > > bonding PMD
> > > > > null PMD
> > > > > pcap PMD
> > > > > ring PMD
> > > >
> > > > Any reason there is no patch for the af_packet driver?
> > > >
> > > > John
> > >
> > > I have just modified the Intel vdev PMD's.
> > > It would be best if the owners of the non Intel vdev's submitted patches
> > for their drivers.
> > 
> > What constitutes an "Intel vdev PMD"?  I thought these were all part of the
> > DPDK project?  It seems odd to me for you to pick and choose like this.
> 
> I should probably have written vdev PMD's contributed by Intel.
> I am not familiar with the other vdev PMD's and thought it best that they should be modified by their owners/maintainers if required.
> 
These are fairly rote changes,  familiarity isn't really needed here, just a
willingness to do some minor testing.  The right approach is to make the changes
to all the drivers, and cc their authors on the patch set so that they can
review it.

> > 
> > What is the overall purpose of this RFC? 
> 
> 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 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.
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

Regards
Neil

> > 
> > John
> > --
> > John W. Linville		Someday the world will need a hero, and you
> > linville at tuxdriver.com			might be all we have.  Be ready.
> 
> Regards,
> 
> Bernard.
> 
> 
>