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-boun...@dpdk.org] On Behalf Of Iremonger, Bernard Sent: Thursday, September 3, 2015 7:33 PM To: Thomas Monjalon; Neil Horman Cc: dev at 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.