DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Stephen Hemminger <stephen@networkplumber.org>
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 12:46:17 +0530	[thread overview]
Message-ID: <3017fb08-e1f2-376a-e748-7151810b440e@nxp.com> (raw)
In-Reply-To: <20161219215944.17226-5-sthemmin@microsoft.com>

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.

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.

> +
> +/**
>   * A structure describing a device driver.
>   */
>  struct rte_driver {
>  	TAILQ_ENTRY(rte_driver) next;  /**< Next in list. */
> -	const char *name;                   /**< Driver name. */
> -	const char *alias;              /**< Driver alias. */
> +	const char *name;              /**< Driver name. */
> +	const char *alias;             /**< Driver alias. */
> +	enum rte_driver_type type;     /**< Driver type. */
>  };
>
>  /**
> @@ -243,4 +252,4 @@ __attribute__((used)) = str
>  }
>  #endif
>
> -#endif /* _RTE_VDEV_H_ */
> +#endif /* _RTE_DEV_H_ */
> diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
> index 9ce88472..d377d539 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -492,6 +492,7 @@ RTE_INIT(pciinitfn_ ##nm); \
>  static void pciinitfn_ ##nm(void) \
>  {\
>  	(pci_drv).driver.name = RTE_STR(nm);\
> +	(pci_drv).driver.type = PMD_PCI; \
>  	rte_eal_pci_register(&pci_drv); \
>  } \
>  RTE_PMD_EXPORT_NAME(nm, __COUNTER__)
> diff --git a/lib/librte_eal/common/include/rte_vdev.h b/lib/librte_eal/common/include/rte_vdev.h
> index 784e837d..98fb5bb5 100644
> --- a/lib/librte_eal/common/include/rte_vdev.h
> +++ b/lib/librte_eal/common/include/rte_vdev.h
> @@ -88,6 +88,7 @@ static void vdrvinitfn_ ##vdrv(void)\
>  {\
>  	(vdrv).driver.name = RTE_STR(nm);\
>  	(vdrv).driver.alias = vdrvinit_ ## nm ## _alias;\
> +	(vdrv).driver.type = PMD_VIRTUAL;\
>  	rte_eal_vdrv_register(&vdrv);\
>  } \
>  RTE_PMD_EXPORT_NAME(nm, __COUNTER__)
>

  reply	other threads:[~2016-12-20  7:12 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 [this message]
2016-12-20 17:16     ` Stephen Hemminger
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=3017fb08-e1f2-376a-e748-7151810b440e@nxp.com \
    --to=shreyansh.jain@nxp.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    --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).