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 3750D1B053 for ; Wed, 11 Jul 2018 12:53:03 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1AE612DB; Wed, 11 Jul 2018 06:53:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 11 Jul 2018 06:53:02 -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=b84r6sLS3QuD/O0sCu9jCI9J4k 2L6LLX/jcDO08ULBw=; b=ftbHzJJr8BgzyEHe4yDIyuQFwZs7azxrHbZJWmOTuA 3gzsDI+DL8hZWYil/eJj0rAbhFh2V1pn2lS5fPYZVmgaTRYeqdvcDZNL1D6Nkzas co0XZlXlAKhUwjwauAVfAB8LeneoLXhlEd2wDaeq+a0412HxWT7q0zt0CMr+XxA7 Y= 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=b84r6s LS3QuD/O0sCu9jCI9J4k2L6LLX/jcDO08ULBw=; b=C/gN+evJq5Gi9l/Y4gz1R1 JohOjU4GJ6jjZdYUE2E7IBgvrL9Tmiuywahj128eN+KTIfFEi4RbnBuINnU8GW9L X51R+W6NXTFCfpNwrDThO2RKBvnuHVrdTNHxrwWi221IjMuAqXfDeevsdWyBu6of yol7BUj5wvrHNNHiTGcg6TwgzkQs3vdqJTUso1OIwmQSQwqocTYwY1dhrau6tpG7 R1whjUdQFdQPq8eupWLnqjovrPFKCgowKB6XEsC1OZ/rMxAGpPJHbjYVe2jYGp9+ rqwke3Hh4UjnNb93Ms/pLlLbZjVsxgyuavA4g2eqyme4KLG0vInZ3XWKYGz8UkaA == 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 8D4A410268; Wed, 11 Jul 2018 06:53:00 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: Ivan Malov , dev@dpdk.org, Ferruh Yigit , David Marchand Date: Wed, 11 Jul 2018 12:52:59 +0200 Message-ID: <25134244.IkLAQZDD0l@xps> In-Reply-To: <058241bd-99a1-8553-b224-4f363a0bae79@solarflare.com> References: <1531302573-16946-1-git-send-email-arybchenko@solarflare.com> <3175221.OSDE0iBHN2@xps> <058241bd-99a1-8553-b224-4f363a0bae79@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:53:03 -0000 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 > >> > >> 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 :)