[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Jan Viktorin
viktorin at rehivetech.com
Fri Apr 22 12:18:26 CEST 2016
[...]
> > >
> > > Changes since v1:
> > > - rebased on HEAD, new drivers should be okay
> > > - patches have been split into smaller pieces
> > > - RTE_INIT macro has been added, but in the end, I am not sure it is useful
> > > - device type has been removed from ethdev, as it was used only by hotplug
> > > - getting rid of pmd type in eal patch (patch 5 of initial series) has been
> > > dropped for now, we can do this once vdev drivers have been converted
> > >
> > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html
> > >
> > > Regards,
> > > --
> > > David Marchand
> > >
> > Nice, David. Looks to be some good improvements in there!
> >
> > /Bruce
>
> Looks good for me but I've failed to apply the series on top of
>
> commit 7d619406f31ddf115714b32778c33f6dc0ead470
> Author: Thomas Monjalon <thomas.monjalon at 6wind.com>
> Date: Thu Apr 14 20:49:49 2016 +0200
>
> pci: remove deprecated specific config
OK, it works, my fault.
What is the way of removing the pmd_type? Would you like to introduce something like
rte_virt_device/driver pair for this purpose? Or should they use the rte_device/rte_driver
directly?
Other points:
* The devinit/devuninit should be generalized and moved to rte_driver, right?
* Fields name, drv_flags should be moved to rte_driver.
* Fields devargs, intr_handle, numa_node should be moved to rte_device.
* Do we want getter/setters for those? Otherwise, it always looks like pci_dev->dev.numa_node.
* What about pci_driver_list and pci_device_list? Should we have separated lists for every
kind of device + driver? or should there be a single list (and so we have to put some
discriminator into the rte_device/driver)? This influences placing of the TAILQ_ENTRY(...) next.
* if we move the next into the rte_driver/device and a discriminator of their type there, all
TAILQ_FOREACH loops will look ugly as we have to check the discriminator...
Regards
Jan
>
> Jan
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
More information about the dev
mailing list