From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 6FDEF1B53A for ; Wed, 11 Jul 2018 12:02:36 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3D456299; Wed, 11 Jul 2018 06:02:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 11 Jul 2018 06:02:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=zy/YLlpFy4lAROMmPh0HT+gLGq DYJKu+sULru1rRyRg=; b=d6xgzHGPDTr1GbMb8+SH5q2mosXLmF29m5G3s8+C/8 zT7n2hBjXUsUNx/uSd8a0x82wz2uTPD2qlqSPdGMcCOZTt7j9TXL1nSuHYrwzPJz gn7ArI8L98XnIrQXRLDUfTSrLWzGa94BmKctl5gIXaQ3/J4YSxoBPX9cKLG6ge5y w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zy/YLl pFy4lAROMmPh0HT+gLGqDYJKu+sULru1rRyRg=; b=ZFWmZlW4prrChBgdxBj9KR ECw50vAN+pX6KHJp/UDmIqf/1qB+awa1ClEohO5bqf9Mt0Byx0MM0r383ydgxG7T Rx/fz3m1QU392Yg8ZncCYgtqXosbxHGFO/bu7ceKyKE4Z/aZzQDA/jUyxrGCflh8 DVXBSFW+0lR7ObQZsaeyOAx1chvo88YW+FNXViriKdSfbbT+quvGTjDJnEzpcMmm 6wYu+MKgfhxjMRFHd7yD7ErBD+dIx3unaMAr6CBRhGPrU7d8MqhYnICQuzPQ5O1V gNdKSKYeOv2udsVA5tCf9XApB2i7icRnBnU5kKXQK4OFFUCxF94bdi0VWao8twJA == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 708EF1028B; Wed, 11 Jul 2018 06:02:33 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko , Ivan Malov Cc: dev@dpdk.org, Ferruh Yigit , David Marchand Date: Wed, 11 Jul 2018 12:02:32 +0200 Message-ID: <3175221.OSDE0iBHN2@xps> In-Reply-To: <1531302573-16946-1-git-send-email-arybchenko@solarflare.com> References: <1531302573-16946-1-git-send-email-arybchenko@solarflare.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: fix port ID retrieval on vdev attach X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 10:02:36 -0000 11/07/2018 11:49, Andrew Rybchenko: > From: Ivan Malov > > 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.