Re: [RFC PATCH 0/6] remove pci driver from vdevs

["Zende, Amruta S" <amruta.zende@intel.com>]

Certain functions like "rte_eth_dev_socket_id" assume the device to be a PCI device and access pointers like rte_eth_devices[port_id].pci_dev->numa_node. 
Any such assumptions and dependencies should also be removed.

Thanks & regards,
Amruta Zende
+91-20-4305-2969

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Iremonger, Bernard
Sent: Thursday, September 3, 2015 7:33 PM
To: Thomas Monjalon; Neil Horman
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs

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

I plan to continue work on the RFC to address this.

> 
> > (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)

There are 17 PMD directories some of which have multiple PMD's.
The total number of PMD's is 23 at present.

 
> > 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.
> 

I will send a second RFC to address the eal driver registration code issues in librte_eal.

> > 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

I plan to park the issue of multiple bus types for now.
More consensus is needed on the best way forward. 
 
> 
> > and put somewhere else or replaced with a union of bus  types and
> drivers?

Regards,

Bernard.