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

[Neil Horman]

On Tue, Sep 01, 2015 at 01:38:02PM +0000, Iremonger, Bernard wrote:
> Hi Neil, Thomas,
> 
> <snip>
> 
> > > 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). 
>  
> <snip>
> 
> > >  Whats really needed is a way to associate an ethdev with an arbitrary bus
> 
> <snip>
> 
> > > > 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.
> 
> <snip >
> 
> > >  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.
> 
> I am just trying to distill what the actual requirement is from the above discussion.
> 
> (1) Remove relationship of the ethdev to the pci driver.
Correct

> (2) Refactor ethdev registration code so that there is a single init  path.
Correct (or mostly correct, in rereading my initial post, there may be some
ambiguitiy here)

> (3) Make bus registration independent of ethdev registration.
Correct

> (4) Change all (17) PMD's to use the  modified structures.
> 
Correct (I assume the 17 number is accurate here)

> The rte_eal_driver_registration() code is  in librte_eal,  untouched as yet by this patch set.
> 
Correct, the code that registers an init function is a single path, which is
great.  However, that path requires that you specify a device type (in this case
PMD_PDEV or PMD_VDEV to differentiate pci vs virtual devices (it uses this for
ordering of initalization in rte_eal_dev_init, which is a hack).  What would be
preferred would be if the structure that was registered via that macro only held
a name and an init routine to initalize the driver itself. Inside that init
routine, the driver would then be responsible for registering with the
appropriate bus type (virtual/pci/usb/whatever).  A secondary function would be
registered as part of that process (akin to the linux/bsd probe() method) which
was called once for each instance of the device found on that bus.

> The rte_eth_driver_registration() code is in librte_ether.
> Should the pci fields be removed from the struct rte_eth_dev{} and struct eth_driver{},
IMO, yes, they should, as the driver can store pointers to those devices in
their private per-device data area.  That said, there may be value in including
a union of all bus types in the ethdev itself, if there are higher layer
functions that need to be aware of a given ethdevs bus type

> and put somewhere else or replaced with a union of bus  types and drivers?
> 
> Regards,
> 
> Bernard.
> 
> 
>