From: Thomas Monjalon <thomas@monjalon.net>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
Ivan Malov <ivan.malov@oktetlabs.ru>
Cc: dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>,
David Marchand <david.marchand@6wind.com>
Subject: Re: [PATCH] ethdev: fix port ID retrieval on vdev attach
Date: Wed, 11 Jul 2018 12:02:32 +0200 [thread overview]
Message-ID: <3175221.OSDE0iBHN2@xps> (raw)
In-Reply-To: <1531302573-16946-1-git-send-email-arybchenko@solarflare.com>
11/07/2018 11:49, Andrew Rybchenko:
> From: Ivan Malov <ivan.malov@oktetlabs.ru>
>
> Attaching a vdev port may result in multiple
> ports actually added because a vdev port may
> have slave devices to be attached implicitly.
>
> Ethdev attach API has to fill in the port ID
> to be read back by the user and what it does
> is take the last assigned ID from the common
> list after attach completion. Such an ID may
> belong to a slave device and not to the vdev.
>
> This mistake must be precluded by requesting
> the port ID by name of device being attached.
No, the real issue is using this function rte_eth_dev_attach.
It is broken since day 1.
Mixing EAL devargs and ethdev port cannot work by design.
If you want to attach a device, you must add it with
rte_eal_hotplug_add
and wait for the driver to probe the ports
(which can be ethdev or other classes).
We should take these actions in 18.08:
- deprecate rte_eth_dev_attach/rte_eth_dev_detach
- deprecate rte_eal_dev_attach/rte_eal_dev_detach
I did not take time to send the deprecation notices yet.
Feel free to deprecate these functions yourself.
next prev parent reply other threads:[~2018-07-11 10:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-11 9:49 [PATCH] ethdev: fix port ID retrieval on vdev attach Andrew Rybchenko
2018-07-11 10:02 ` Thomas Monjalon [this message]
2018-07-11 10:15 ` Andrew Rybchenko
2018-07-11 10:52 ` Thomas Monjalon
2018-07-11 11:10 ` Andrew Rybchenko
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=3175221.OSDE0iBHN2@xps \
--to=thomas@monjalon.net \
--cc=arybchenko@solarflare.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=ivan.malov@oktetlabs.ru \
/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.