[...]
> > > 
> > > 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

Reply via email to