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.
