2016-07-08 21:09, Jan Viktorin:
> Hello,
> 
> based on the discussions with Shreyansh, I propose a patchset with
> the important EAL changes. It is incomplete and I suppose to extend
> and change certain things in the foreseeable future.
> 
> Important notes:
> 
> * pmd_type is removed
> * introduced rte_vdev_driver inheriting rte_driver
> * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER
> * rte_driver/device integrated into rte_pci_driver/device
> * all drivers and devices are in 2 lists - general and bus-specific
> 
> Shreyansh, I hope I do not duplicate your work. I tried to avoid touching
> pmd_type but it quite complicated... There is also an initial generalization
> of rte_pci_resource. More such generalizations are to be done.
> 
> The init/uninit functions cannot be generalized easily, I think. Both PCI
> and VDEV have different requirements.
> 
> No idea about hotplug...

Please could you give a clear overview of how you split the work in
your respective series?

I take the opportunity to put my notes about some initial targets of
this refactoring:

module/drivers
        attached to 1 bus: pci_driver or vdev_driver
        rte_device = device resources / embedded in pci/vdev_driver
                attached to n device interfaces (ethdev, crypto)
        1 device resource -> n device interfaces
        hotplug resource -> lookup drivers list
                per-bus lists or 1 list?
        devinit/devuninit generalized and moved to rte_driver
                -> rename to probe/remove
        crypto.dev_type could be dropped
        drv_flags should be moved to rte_driver
        intr_init can be moved earlier in init, before affinity set
devices
        unique_device_name -> standard naming?
                difference with port_id ? -> device id for ethdev
                should be unique_resource_name -> 1 EAL resource may match 
several devices
        ethdev manage an interface, eal manage a hardware resource, device 
object in between?
        need for bus object?
        no need of driver object, module object?
        devargs, intr_handle, numa_node should be moved to rte_device
hotplug notification to do
        notify free-able ressource?
        remove blacklist at EAL level and let application handle it
        devargs still in hotplug function, must be moved in separate API
devargs
        new API
        new command line parameters

Reply via email to