diff mbox series

ethdev: fix port ID retrieval on vdev attach

Message ID 1531302573-16946-1-git-send-email-arybchenko@solarflare.com (mailing list archive)
State Rejected, archived
Headers
Series ethdev: fix port ID retrieval on vdev attach |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Andrew Rybchenko July 11, 2018, 9:49 a.m. UTC 
  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.

Fixes: b0fb26685570 ("ethdev: convert to EAL hotplug")
Cc: David Marchand <david.marchand@6wind.com>
Cc: stable@dpdk.org

Reported-by: Andrew Rybchenko <arybchenko@solarflare.com>
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
 lib/librte_ethdev/rte_ethdev.c | 26 ++++----------------------
 1 file changed, 4 insertions(+), 22 deletions(-)

Comments

Thomas Monjalon July 11, 2018, 10:02 a.m. UTC | #1 
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.
Andrew Rybchenko July 11, 2018, 10:15 a.m. UTC | #2 
On 11.07.2018 13:02, Thomas Monjalon wrote:
> 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).

Yes, I totally agree. Doesn't it deserve to be fixed at least in stable?

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

Should we deprecate it right now in 18.08 and schedule removal to 18.11?
Or just add deprecation notice in 18.08, mark deprecated in 18.11 and
remove later?
Thomas Monjalon July 11, 2018, 10:52 a.m. UTC | #3 
11/07/2018 12:15, Andrew Rybchenko:
> On 11.07.2018 13:02, Thomas Monjalon wrote:
> > 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).
> 
> Yes, I totally agree. Doesn't it deserve to be fixed at least in stable?

The concern with stable is to keep it stable :)
I'm afraid this change can introduce more regressions.

> > 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.
> 
> Should we deprecate it right now in 18.08 and schedule removal to 18.11?

Yes, we should mark it as deprecated in 18.08 and plan for removal in 18.11.
It is good to get it removed from the next LTS which is 18.11.

> Or just add deprecation notice in 18.08, mark deprecated in 18.11 and
> remove later?

Later is too late :)
Andrew Rybchenko July 11, 2018, 11:10 a.m. UTC | #4 
On 11.07.2018 13:52, Thomas Monjalon wrote:
> 11/07/2018 12:15, Andrew Rybchenko:
>> On 11.07.2018 13:02, Thomas Monjalon wrote:
>>> 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).
>> Yes, I totally agree. Doesn't it deserve to be fixed at least in stable?
> The concern with stable is to keep it stable :)
> I'm afraid this change can introduce more regressions.

Makes sense. I'll drop the patch.

>>> 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.
>> Should we deprecate it right now in 18.08 and schedule removal to 18.11?
> Yes, we should mark it as deprecated in 18.08 and plan for removal in 18.11.
> It is good to get it removed from the next LTS which is 18.11.

Yes, I agree. I'll care about it.

>> Or just add deprecation notice in 18.08, mark deprecated in 18.11 and
>> remove later?
> Later is too late :)
diff mbox series

Patch

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 16b8258a7..dbb9244ec 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -46,7 +46,6 @@  int rte_eth_dev_logtype;
 
 static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
 struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
-static uint16_t eth_dev_last_created_port;
 
 /* spinlock for eth device callbacks */
 static rte_spinlock_t rte_eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
@@ -284,8 +283,6 @@  eth_dev_get(uint16_t port_id)
 
 	eth_dev->data = &rte_eth_dev_shared_data->data[port_id];
 
-	eth_dev_last_created_port = port_id;
-
 	return eth_dev;
 }
 
@@ -646,7 +643,6 @@  eth_err(uint16_t port_id, int ret)
 int
 rte_eth_dev_attach(const char *devargs, uint16_t *port_id)
 {
-	int current = rte_eth_dev_count_total();
 	struct rte_devargs da;
 	int ret = -1;
 
@@ -665,24 +661,10 @@  rte_eth_dev_attach(const char *devargs, uint16_t *port_id)
 	if (ret < 0)
 		goto err;
 
-	/* no point looking at the port count if no port exists */
-	if (!rte_eth_dev_count_total()) {
-		RTE_ETHDEV_LOG(ERR, "No port found for device (%s)\n", da.name);
-		ret = -1;
-		goto err;
-	}
-
-	/* if nothing happened, there is a bug here, since some driver told us
-	 * it did attach a device, but did not create a port.
-	 * FIXME: race condition in case of plug-out of another device
-	 */
-	if (current == rte_eth_dev_count_total()) {
-		ret = -1;
-		goto err;
-	}
-
-	*port_id = eth_dev_last_created_port;
-	ret = 0;
+	ret = rte_eth_dev_get_port_by_name(da.name, port_id);
+	if (ret != 0)
+		RTE_ETHDEV_LOG(ERR, "No port found for device (%s)\n",
+			       da.name);
 
 err:
 	free(da.args);