From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 1C609316B for ; Mon, 28 Jan 2019 01:20:28 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A24C320946; Sun, 27 Jan 2019 19:20:27 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 27 Jan 2019 19:20:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=lRNHM3EqWxwhiJbmL92Pni14kg5o5RbnLpIXmQ4v/t4=; b=e4Ge4xFt2OeM fuyWYl/4ijXRirXHU2HOdpfy6H9sLS9SGzP5EvFN4/KxNKkOH7pfraSu3J68pBSJ YS5ZRyv8BpKrlcz9Vbnqh+56XQb/ORVuJ8buKwhE+EE9YWpnpcD8rvnjLy3606kW sk/BTzfl0UwUufB00HBRCMwaqvireW8= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=lRNHM3EqWxwhiJbmL92Pni14kg5o5RbnLpIXmQ4v/ t4=; b=TMBfd2n4/KmRMr3C1T0e1UnXNsCr7pY1Uz76D6Lz893pIDHURfZtt6RtP ONSHv20c5d82BAfZoU7L6Xn1TSiNXqlsklIaFmf8y+i6aWyQt5QOQUD1EK+dA7wc O+BDW/N4n1c6fey+PGrcGuCY/oR5WLLcbY2U/WMtZ4rXUbsCANlmc1pd9/EFgzi/ h0H1WhncWNO524ui7ALMuvwbzdqnnkJ/xzphQCwBl8+cpfGyPNV/VgPVgQ0tCB/L Sc1h84flajjnn1ewJN3jrBv+8GKbkUx+51kxCXjahvLeeNB9bWMzQRr5PRgCyl9A iLMbRoLY7MoHFYTRIl74+seJgTjsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrieelgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfh gggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceo thhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuffhomhgrihhnpeguphgukhdroh hrghenucfkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BB83D1027C; Sun, 27 Jan 2019 19:20:25 -0500 (EST) From: Thomas Monjalon To: Qi Zhang Cc: dev@dpdk.org, declan.doherty@intel.com, ferruh.yigit@intel.com, ktraynor@redhat.com, benjamin.h.shelton@intel.com, narender.vangati@intel.com Date: Mon, 28 Jan 2019 01:20:24 +0100 Message-ID: <1648146.NeMYav50z5@xps> In-Reply-To: <20180920045959.106252-1-qi.z.zhang@intel.com> References: <20180920045959.106252-1-qi.z.zhang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] doc: update API deprecation for device reset 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: Mon, 28 Jan 2019 00:20:28 -0000 Hi, I don't remember why this deprecation notice did not get any feedback in the 18.11 cycle. It looks to be outdated now. In case you still plan some changes, I give my opinion below. 20/09/2018 06:59, Qi Zhang: > Device reset may have the dependency, for example, a VF reset expects > PF ready, or a NIC function as a part of a SOC need to wait for other > parts of the system be ready, these are time-consuming tasks and will > block current thread. > > So we rename rte_eth_dev_reset to rte_eth_dev_reset_async as an async > API, that makes things easy for an application that what to reset the > device from the interrupt thread since typically a > RTE_ETH_EVENT_INTR_RESET handler is invoked in interrupt thread. > > RFC patch: > http://patchwork.dpdk.org/patch/44989/ > > Signed-off-by: Qi Zhang I remmember I did not like this function when it was introduced. I think the cases addressed by rte_eth_dev_reset() should be handled with hotplug mechanism. > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > +* ethdev: In v19.02 ``rte_eth_dev_reset`` is renamed to Is it still planned for 19.05? > + ``rte_eth_dev_reset_async``. As the name, it is an async API. Why removing the old function? We could avoid breaking applications by adding an async flavor of the function. > + Application should not assume device reset is finished after > + ``rte_eth_dev_reset_async`` return, it should always wait for a > + RTE_ETH_EVENT_RESET_COMPLETE event and check the reset result. This could be done in the synchronous flavor with sleeps in a loop.