From: Jan Viktorin <viktorin@rehivetech.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Shreyansh Jain <shreyansh.jain@nxp.com>,
David Marchand <david.marchand@6wind.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure
Date: Fri, 15 Jul 2016 17:33:59 +0200 [thread overview]
Message-ID: <20160715173359.4bc0eb25@pcviktorin.fit.vutbr.cz> (raw)
In-Reply-To: <1803983.1lZj4rVXKI@xps13>
On Fri, 15 Jul 2016 15:19:14 +0200
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 2016-07-08 21:09, Jan Viktorin:
> > Hello,
> >
> > based on the discussions with Shreyansh, I propose a patchset with
> > the important EAL changes. It is incomplete and I suppose to extend
> > and change certain things in the foreseeable future.
> >
> > Important notes:
> >
> > * pmd_type is removed
> > * introduced rte_vdev_driver inheriting rte_driver
> > * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER
> > * rte_driver/device integrated into rte_pci_driver/device
> > * all drivers and devices are in 2 lists - general and bus-specific
> >
> > Shreyansh, I hope I do not duplicate your work. I tried to avoid touching
> > pmd_type but it quite complicated... There is also an initial generalization
> > of rte_pci_resource. More such generalizations are to be done.
> >
> > The init/uninit functions cannot be generalized easily, I think. Both PCI
> > and VDEV have different requirements.
> >
> > No idea about hotplug...
>
> Please could you give a clear overview of how you split the work in
> your respective series?
Yes, it's a bit messy... My quick summary follows.
>
> I take the opportunity to put my notes about some initial targets of
> this refactoring:
>
> module/drivers
> attached to 1 bus: pci_driver or vdev_driver
pci_driver is done by Shreyansh/David
vdev_driver is done by myself
> rte_device = device resources / embedded in pci/vdev_driver
Extraction of rte_device is done by myself
> attached to n device interfaces (ethdev, crypto)
> 1 device resource -> n device interfaces
I am not sure, what those two points means exactly.
> hotplug resource -> lookup drivers list
> per-bus lists or 1 list?
Not sure. At least partially done by Shreyansh/David.
> devinit/devuninit generalized and moved to rte_driver
> -> rename to probe/remove
Some renames done by Shreyansh/David.
There will be no move. The vdev_driver has different kind of init/uninit
then PCI. So I cannot see a simple way how to generalize this.
I'll do the final init->probe, uninit->remove renames.
> crypto.dev_type could be dropped
I am not sure about this.
> drv_flags should be moved to rte_driver
I'll do.
> intr_init can be moved earlier in init, before affinity set
> devices
Done by Shreyansh/David.
> unique_device_name -> standard naming?
Done for PCI: rte_eal_pci_device_name by Shreyansh/David.
> difference with port_id ? -> device id for ethdev
Not sure.
> should be unique_resource_name -> 1 EAL resource may match several devices
Not sure.
> ethdev manage an interface, eal manage a hardware resource, device object in between?
Not sure about the question.
> need for bus object?
I don't think so at this stage.
> no need of driver object, module object?
The current rte_driver will not exist. Same for any kind of module.
> devargs, intr_handle, numa_node should be moved to rte_device
Yes, done by myself.
> hotplug notification to do
> notify free-able ressource?
> remove blacklist at EAL level and let application handle it
> devargs still in hotplug function, must be moved in separate API
> devargs
> new API
> new command line parameters
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
prev parent reply other threads:[~2016-07-15 15:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-08 19:09 Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 01/15] eal: extract vdev infra Jan Viktorin
2016-07-11 13:29 ` Shreyansh jain
2016-07-11 14:08 ` Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 02/15] eal: no need to test for PMD_VDEV anymore Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 03/15] eal: do not call init for PMD_PDEV drivers Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 04/15] drivers: convert PMD_VDEV drivers to use rte_vdev_driver Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 05/15] eal: move init/uninit to rte_vdev_driver Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 06/15] eal: remove PMD_REGISTER_DRIVER Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 07/15] eal: get rid of pmd_type Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 08/15] eal: define macro container_of Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 09/15] eal: rte_pci.h includes rte_dev.h Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 10/15] eal: rename and move rte_pci_resource Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 11/15] eal/pci: inherit rte_driver by rte_pci_driver Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 12/15] eal: call rte_eal_driver_register Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 13/15] eal: introduce rte_device Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 14/15] eal/pci: inherit rte_device by rte_pci_device Jan Viktorin
2016-07-08 19:09 ` [dpdk-dev] [PATCH v1 15/15] eal/pci: insert rte_device on scan Jan Viktorin
2016-07-11 13:13 ` [dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure Shreyansh jain
2016-07-15 13:19 ` Thomas Monjalon
2016-07-15 15:33 ` Jan Viktorin [this message]
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=20160715173359.4bc0eb25@pcviktorin.fit.vutbr.cz \
--to=viktorin@rehivetech.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=shreyansh.jain@nxp.com \
--cc=thomas.monjalon@6wind.com \
/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).