I've lost some To/CC in the e-mail, so forwarding to dpdk-dev... Begin forwarded message:
Date: Mon, 18 Jan 2016 15:58:34 +0100 From: Jan Viktorin <vikto...@rehivetech.com> To: David Marchand <david.marchand at 6wind.com> Subject: Re: Proposal for a big eal / ethdev cleanup Hello David, I am playing around a little bit with the code according to your ideas. I found quite a wierd situation with the rte_driver which makes the transition to a better infrastructure very difficult from my point of view... On Thu, 14 Jan 2016 11:38:16 +0100 David Marchand <david.marchand at 6wind.com> wrote: > Impact on PCI device/driver > > - rte_pci_device is modified to embed a rte_device (embedding makes it > possible later to cast the rte_device and get the rte_pci_device in pci > specific functions) This is OK and it can be done quite easily. > - no need for a rte_pci_driver reference in rte_pci_device, since we > have the rte_device driver This is an issue, see below. > > - rte_pci_driver is modified to embed a rte_driver The rte_driver and rte_pci_driver are related in a much different way at the moment. The meaning of rte_driver is more like an rte_module in the current DPDK. In fact, we don't have any generic rte_driver suitable for this purpose. Thus, the transition to this model needs to rename rte_driver to rte_module and to introduce a new data structure named rte_driver. Quite confusing... but this is how I understand it. (What is the current relation between rte_pci_device and rte_pci_driver? Is the rte_pci_driver a singleton? I doubt. Well, it cannot be, as it is embedded in each eth_driver.) Another way, not that beautiful... Introduce rte_generic_driver and rte_generic_device. (Or rte_gen_driver/rte_gen_device or rte_bus_driver/rte_bus_device if you want). This enables to let the rte_driver as it is and it avoids a lot of quite terrible transition patches that can break everything. > - no more devinit and devuninit functions in rte_pci_driver, they can > be moved as init / uninit functions in rte_driver The rte_driver has init/uninit already and its semantics seem to be module_init and module_uninit. Regards Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
