[dpdk-dev] rings PMD detaching

[dpdk-dev] rings PMD detaching

[Mauricio Vásquez]

Hello Everybody,

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.

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.
- 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.

Any idea or comment about it?

Thank you very much

Re: [dpdk-dev] rings PMD detaching

[David Marchand]

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