From: David Marchand <david.marchand@6wind.com>
To: "Mauricio Vásquez" <mauricio.vasquezbernal@studenti.polito.it>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Jan Viktorin <viktorin@rehivetech.com>
Subject: Re: [dpdk-dev] rings PMD detaching
Date: Tue, 2 Feb 2016 06:41:01 +0100 [thread overview]
Message-ID: <CALwxeUtVo3zsANEitpknomo=die0LK-8NoH0m7FaEXk_t7JgJw@mail.gmail.com> (raw)
In-Reply-To: <CAPwdgqi1Uvg2MJiT_08AcO-kBUrAZjrZVYTBweA3-xzm=FVpuA@mail.gmail.com>
Hello Mauricio,
On Tue, Feb 2, 2016 at 2:37 AM, Mauricio Vásquez
<mauricio.vasquezbernal@studenti.polito.it> wrote:
> I was wondering if there were a way to detach (delete) a ring pmd device
> created with rte_eth_from_rings. I realized that rte_eth_dev_detach does
> not work in this case because there is a comparison between the device's
> name and the driver's name in rte_eal_vdev_uninit, then devices created
> with arbitrary names can not be uninitialized.
I would say this is the same problem than what I observed in pci code.
Doing a "driver" lookup on detach is useless (and buggy in your case),
eal should just reuse the driver that the device had been attached to.
The problem is that, for vdev, the driver is not stored in a device
object at attach time, since there is no device object.
> My question is how to implement it?, I have two ideas on mind:
> - make rte_pmd_ring_devuninit a public function, then the user can call
> this using as argument the name of the device.
Having something like this enter abi, because of a bug in eal, does
not sound like a good idea.
> - modify rte_eal_vdev_uninit in such a way that there is not any comparison
> based on the dev name, probably it will require to add some extra field in
> the rte_eth_dev structure to distinguish between the different virtual
> devices.
No, the problem lies in eal where resources are bound to drivers.
No reason to pollute ethdev (we have enough workarounds in it ;-)).
This driver lookup should just go away.
If we had the rte_device I described [1], this kind of issues would disappear.
[1] http://dpdk.org/ml/archives/dev/2016-January/031390.html
Regards,
--
David Marchand
prev parent reply other threads:[~2016-02-02 5:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 1:37 Mauricio Vásquez
2016-02-02 5:41 ` David Marchand [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='CALwxeUtVo3zsANEitpknomo=die0LK-8NoH0m7FaEXk_t7JgJw@mail.gmail.com' \
--to=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=mauricio.vasquezbernal@studenti.polito.it \
--cc=viktorin@rehivetech.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).