* [dpdk-dev] Fw: Proposal for a big eal / ethdev cleanup
@ 2016-01-18 15:15 Jan Viktorin
0 siblings, 0 replies; only message in thread
From: Jan Viktorin @ 2016-01-18 15:15 UTC (permalink / raw)
To: dev
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@rehivetech.com>
To: David Marchand <david.marchand@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@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@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-01-18 15:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-18 15:15 [dpdk-dev] Fw: Proposal for a big eal / ethdev cleanup Jan Viktorin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).