From: Thomas Monjalon <thomas.monjalon at 6wind.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] SPDK & DPDK in one process
Date: Tue, 25 Oct 2016 22:53:53 +0200 [thread overview]
Message-ID: <3132089.uuuRJKvomT@xps13> (raw)
In-Reply-To: 1477351848.71904.43.camel@intel.com
[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]
Hi SPDK
2016-10-24 23:30, Walker, Benjamin:
> On Sat, 2016-10-22 at 21:19 +0300, Gregory Etelson wrote:
> > Hello
> >
> > I need to run DPDK networking and access NVMe device in the same process.
> >
> > rte_eal_init() initializes network PMD drivers normally
> > But spdk_nvme_probe() activates network devices probe for the second time and
> > rte exits with error.
> >
> > To resolve this failure I register NVMe controller driver as DPDK PMD.
> > Now I can pass NVMe device PCI address to EAL initialization with `-w'
> > parameter along with network devices
> > PMD template I use is attached below.
> >
> > Is there another way to run DPDK and SPDK in the same process ?
>
> You found the best way right now, but I'm working with the DPDK community to
> improve here. It seems like the rte_pci module doesn't handle multiple calls to
> rte_eal_pci_probe, which is what SPDK is doing. The most important change to
> DPDK that needs to happen is that rte_eal_pci_probe needs to not call the driver
> initialization function for devices that already have a driver loaded. That's a
> very easy fix that solves your problem and I'll be submitting a patch to the
> DPDK community.
>
> Longer term I think we really need to work with DPDK to clean up some of these
> PCI interfaces so they're more dynamic and can handle devices and drivers coming
> and going at run time.
Yes you are welcome to contribute to DPDK.
There is a slow work in progress to better design the EAL in order to ease
integration of new buses and allow true hotplugging.
We do these core changes step by step:
After having better designed the device object, we are changing the bus model.
Instead of having PCI the default bus, and vdev an exception, we need a
generic bus object to plug PCI, vdev and other buses in it.
Then we should design a better app event mechanism, usable for hotplug.
Another step could be an auto-binding.
And at the end we could be plugged to hardware events like udev.
next reply other threads:[~2016-10-25 20:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 20:53 Thomas Monjalon [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-10-26 17:03 [SPDK] SPDK & DPDK in one process Gregory Etelson
2016-10-24 23:30 Walker, Benjamin
2016-10-22 18:19 Gregory Etelson
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=3132089.uuuRJKvomT@xps13 \
--to=spdk@lists.01.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 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.