[dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization

[David Marchand]

Hello Shreyansh,

On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain <shreyansh.jain at nxp.com> wrote:

>  This patch is part of larger aim to:
>
>  --------------------+ <is type of>
>  eth_driver (PMD)    |-------------> rte_driver
>  crypto_driver (PMD) |               ^
>  <more in future>    |               |
>  --------------------+               | <inherits>
>                                     /
>            +-----------------------/+
>            | rte_pci_driver         |
>            | rte_vdev_driver        |
>            | rte_soc_driver         |
>            | rte_xxx_driver         |
>
>  Where PMD devices (rte_eth_dev, rte_cryptodev_dev) are connected to their
>  drivers rather than explicitly inheriting type specific driver (PCI, etc).
>
>
> About the Patches:
> ==================
>
> There are a large number of patches for this - primarily because the changes
> are quite varied and keeping them logically separate yet compilable is
> important. Most of the patches are small and those which are large touch the
> drivers (PMDs) to accommodate the structure changes:
>
>  - Patches 0001~0003 are for introducing the container_of function (so that
>    rte_device can be obtained from rte_pci_device, for example), and
>    removing unused code.
>  - Patches 0004~0007 just perform the ground work for enabling change from
>    rte_driver/eth_driver based PMDs to rte_xxx_driver based PMDs
>  - In patch 0008, all the pdev PMDs are changed to support rte_pci_driver (
>    including cryptodev, which is eventually generalized with PCI)
>  - Patch 0009~0010 merge the crypto and pci functions for registration and
>    naming.
>  - Patches 0011~0014 deal with hotplugging - hotplug no more invokes scan of
>    complete bus and has been generalized into EAl from ethdev.
>  - Patches 0015 introduces vdev init/uninit into separate C units and
>    enables its compilation. Patch 0016~0017 build on it and remove the
>    remaining legacy support for vdev/pdev distinctions.
>  - Patches 0018~0022 enable the vdev drivers to register using the
>    DRIVER_REGISTER_* operations, and remove their rte_driver->init()
>  - Patch 0023 enables the rte_driver registration into a common driver
>    linked list.
>  - Patches 0024~0025 introduce the rte_device, a generalization of
>    rte_xxx_device, and associated operation of creating rte_device linked
>    list. It also enables the drivers to use rte_device.name/numa_node
>    members rather than rte_xxx_device specific members.
>
> Notes:
> ======
>
> * Some sign-off were already provided by Jan on the original v5; But, as a
>   large number of merges have been made, I am leaving those out just in case
>   it is not sync with initial understanding.
>
> * This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is
>   removed [7].
>
> Future Work/Pending:
> ===================
>  - Presently eth_driver, rte_eth_dev are not aligned to the rte_driver/
>    rte_device model. eth_driver still is a PCI specific entity. This
>    has been highlighted by comments from Ferruh in [9].
>  - cryptodev driver too still remains to be normalized over the rte_driver
>    model
>  - Some variables, like drv_name (as highlighted by Ferruh), are getting
>    duplicated across rte_xxx_driver/device and rte_driver/device.

Overall, we are still missing some parts :
- in my initial proposition, the rte_driver would embed the
probe/remove (previsouly init/uninit) functions that would take
rte_device object as arguments (and maybe we should get rid of the
double lists, I am not yet convinced it is easy).
- the pmdinfo stuff is broken and could be implemented for vdev, I did
a quick patch that replaces the "PMD_REGISTER_DRIVER(.*)" regexp as
"DRIVER_REGISTER_.*(.*)" then I added a DRIVER_EXPORT_NAME(nm,
__COUNTER__) in the vdev register macro, it looks to work fine.
pmdinfo is a bit too pci but I think we can go with this.
- the names should go to rte_device/rte_driver objects ?



-- 
David Marchand