From: Stephen Hemminger <stephen@networkplumber.org>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: <dev@dpdk.org>, Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [dpdk-dev] [PATCH 04/13] eal: introduce driver type
Date: Tue, 20 Dec 2016 09:16:28 -0800 [thread overview]
Message-ID: <20161220091628.49b56b7e@xeon-e3> (raw)
In-Reply-To: <3017fb08-e1f2-376a-e748-7151810b440e@nxp.com>
On Tue, 20 Dec 2016 12:46:17 +0530
Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> On Tuesday 20 December 2016 03:29 AM, Stephen Hemminger wrote:
> > Since multiple buses and device types need to be supported.
> > Provide type field in driver.
> > ---
> > lib/librte_eal/common/include/rte_dev.h | 15 ++++++++++++---
> > lib/librte_eal/common/include/rte_pci.h | 1 +
> > lib/librte_eal/common/include/rte_vdev.h | 1 +
> > 3 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
> > index e5471a22..3f4e26e6 100644
> > --- a/lib/librte_eal/common/include/rte_dev.h
> > +++ b/lib/librte_eal/common/include/rte_dev.h
> > @@ -144,12 +144,21 @@ void rte_eal_device_insert(struct rte_device *dev);
> > void rte_eal_device_remove(struct rte_device *dev);
> >
> > /**
> > + * Type of device driver
> > + */
> > +enum rte_driver_type {
> > + PMD_VIRTUAL,
> > + PMD_PCI,
> > +};
>
> So the expectation is that if a new device type is introduced (anything
> other than virtual or PCI), this enum is expanded?
>
> Broadly, we have two possible ways being discussed on ML for device
> relationship with PMD/APIs:
>
> 1. the way you have done: each device belongs to a particular type (enum
> rte_driver_type) and based on its type, operations would be performed on
> it (using conditional operators, for example). We continue to have a
> common device list containing all type of devices.
It is more about providing feedback to applications in info_get which is
the only place they should care.
>
> 2. disassociating the device (rte_device) completely from its type and
> basing it on a Bus type. So, we have separate buses for each device type
> and hence no need for separation of logic based on device type.
>
> I think implementation similar to (1) existed before it was removed in
> 6751f6de.
>
> I have an (obvious) inclination towards (2) because that helps plugging
> in more drivers/device types without expecting the contributor to change
> the EAL - however trivial the change is.
>
The difference is that virtual devices don't actually live on bus.
So it is really a property of the device not a bus per say.
next prev parent reply other threads:[~2016-12-20 17:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 21:59 [dpdk-dev] [RFC v2 00/13] Generalize rte_eth_dev model Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 01/13] ethdev: increase length ethernet device internal name Stephen Hemminger
2016-12-20 6:53 ` Shreyansh Jain
2016-12-20 17:14 ` Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 02/13] rte_device: make driver pointer const Stephen Hemminger
2016-12-20 11:14 ` Jan Blunck
2016-12-19 21:59 ` [dpdk-dev] [PATCH 03/13] eal: define container_of macro Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 04/13] eal: introduce driver type Stephen Hemminger
2016-12-20 7:16 ` Shreyansh Jain
2016-12-20 17:16 ` Stephen Hemminger [this message]
2016-12-20 13:00 ` Jan Blunck
2016-12-20 17:09 ` Stephen Hemminger
2016-12-20 13:04 ` Ferruh Yigit
2016-12-19 21:59 ` [dpdk-dev] [PATCH 05/13] pmd: remove useless reset of dev_info->dev_pci Stephen Hemminger
2016-12-20 11:16 ` Jan Blunck
2016-12-19 21:59 ` [dpdk-dev] [PATCH 06/13] ethdev: make dev_info generic (not just PCI) Stephen Hemminger
2016-12-20 11:20 ` Jan Blunck
2016-12-19 21:59 ` [dpdk-dev] [PATCH 07/13] e1000: localize mapping from eth_dev to pci Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 08/13] ixgbe: localize mapping from eth_dev to pci_device Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 09/13] i40e: localize mapping of eth_dev to pci Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 10/13] virtio: localize mapping from rte_eth " Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 11/13] broadcom: localize mapping from eth_dev " Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 12/13] ethdev: change pci_dev to generic device Stephen Hemminger
2016-12-19 21:59 ` [dpdk-dev] [PATCH 13/13] hyperv: VMBUS support infrastucture Stephen Hemminger
2016-12-20 12:48 ` [dpdk-dev] [RFC v2 00/13] Generalize rte_eth_dev model Jan Blunck
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=20161220091628.49b56b7e@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=shreyansh.jain@nxp.com \
--cc=sthemmin@microsoft.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).