From: Jan Viktorin <viktorin@rehivetech.com>
To: dev@dpdk.org
Subject: [dpdk-dev] Fw: Proposal for a big eal / ethdev cleanup
Date: Mon, 18 Jan 2016 16:15:51 +0100 [thread overview]
Message-ID: <20160118161551.4b762e42@pcviktorin.fit.vutbr.cz> (raw)
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
reply other threads:[~2016-01-18 15:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160118161551.4b762e42@pcviktorin.fit.vutbr.cz \
--to=viktorin@rehivetech.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).