[dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization
David Marchand
david.marchand at 6wind.com
Mon Sep 12 09:32:36 CEST 2016
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
More information about the dev
mailing list