[dpdk-dev] Fw: Proposal for a big eal / ethdev cleanup

[Jan Viktorin]

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 <viktorin at 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