From: Stephen Hemminger <stephen@networkplumber.org>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: <dev@dpdk.org>, Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [PATCH 2/2] hyperv: VMBUS support infrastucture
Date: Thu, 15 Dec 2016 09:26:31 -0800 [thread overview]
Message-ID: <20161215092631.5cb798b2@xeon-e3> (raw)
In-Reply-To: <544b6faf-11f4-93fe-6427-7d3fcfaba388@nxp.com>
On Thu, 15 Dec 2016 12:19:44 +0530
Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> > @@ -1866,7 +1871,11 @@ typedef int (*eth_dev_uninit_t)(struct rte_eth_dev *eth_dev);
> > * - The size of the private data to allocate for each matching device.
> > */
> > struct eth_driver {
> > - struct rte_pci_driver pci_drv; /**< The PMD is also a PCI driver. */
> > + union {
> > + struct rte_pci_driver pci_drv; /**< The PMD PCI driver. */
> > + struct rte_vmbus_driver vmbus_drv;/**< The PMD VMBUS drv. */
> > + };
> > +
> > eth_dev_init_t eth_dev_init; /**< Device init function. */
> > eth_dev_uninit_t eth_dev_uninit; /**< Device uninit function. */
> > unsigned int dev_private_size; /**< Size of device private data. */
>
> It is not a scale-able model where we have to change eth_driver/eth_dev
> for every new device type, other than PCI. Maybe VMBus is _very_ close
> to PCI so no changes are required in PCI layer (common, linuxapp,
> bsdapp) - but, for others it won't stop there.
>
> At the least, rte_pci_driver/rte_pci_device should be removed from
> eth_driver & rte_eth_dev, respectively - relying on rte_driver and
> rte_device.
>
> This is the primary reason work on the SoC patchset and now the new Bus
> model is being done.
Agreed. the better long term model is to use C style inheritance where
rte_pci_driver has eth_driver inside.
The other alternative is to make the second element an opaque pointer.
But that was too big a change, and not necessary to get VMBUS to work.
Longer term refactoring will take more effort. Go ahead and address it
with a better bus model, but that probably isn't going to be ready for
a couple of releases.
next prev parent reply other threads:[~2016-12-15 17:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 23:59 [PATCH 0/2] support for Hyper-V VMBUS Stephen Hemminger
2016-12-14 23:59 ` [PATCH 1/2] ethdev: increase length ethernet device internal name Stephen Hemminger
2016-12-14 23:59 ` [PATCH 2/2] hyperv: VMBUS support infrastucture Stephen Hemminger
2016-12-15 6:49 ` Shreyansh Jain
2016-12-15 17:26 ` Stephen Hemminger [this message]
2016-12-16 18:09 ` Thomas Monjalon
2016-12-16 20:15 ` Stephen Hemminger
2016-12-17 9:17 ` Thomas Monjalon
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=20161215092631.5cb798b2@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.