From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3A84AA04BC; Tue, 29 Sep 2020 18:06:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C10B71BFEC; Tue, 29 Sep 2020 18:06:44 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 81B001BAF5 for ; Tue, 29 Sep 2020 18:06:42 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 739CFFD9; Tue, 29 Sep 2020 12:06:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 29 Sep 2020 12:06:40 -0400 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=fm2; bh= Vy7utsSc8TUjEUGcifiG05hj6mipj1rQGBY/e7JGHME=; b=CqokNuzy5lYDsalK OFErSkHoXiJWX4rhaqK06mSwIldGZ7bpXQA7JoxlNm86kuByWQQq3O3f2XTwdyjH z4o1eRYSn+Vlqxxvi5ZDIU6UoE2UxcqKGcWRr7MMRrlVJ8ET1yYRL3bDUKWo1OOF q+bM32psw//WCl6ab02WPwtiEPgCmtiKBDg05HYfUgHx9hA5pr9r5Uu+hv1Fvkba 5jdbG9FaNmp7lv347CcYYc2hmiLlA/CyLw/WHXvZhTl4dMSP52pD6qyQLjDcI5Cg FUS41z7RPLSVx1ENTgSrjATsoBUJLvD/YNSvakZWLGQAHVeb3Bo7Y2b+9OnSH8TQ 8PR3bQ== 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=fm3; bh=Vy7utsSc8TUjEUGcifiG05hj6mipj1rQGBY/e7JGH ME=; b=lq5s1Lm4v23XeCSQZQq7OJeyBvn2VxJEBpet/ipXJPBKFcBUrBBrAwUjC 8OYu8slBrH5yOM3/uJ1F0ggSj8dsHxQSknNihHKziqXTPl9LFTW/fQx98EcIjVD6 DiSevBr/M78YrFcUMVu36LeyRwQiUEy9PVxILNU90WXxK1yscaZu85aCMsVcspPX A7ovmcu60RAKhzXul+dULWPk7nk8+CcdbQyBUZqJewVdnxLtMouKicRgPskeoAc1 082Ee4elZvV5r+oZHGhvyuQZvmiElBQJXp1jF43XuwYPQ3fCWehrGuZdJuKbAcDE wyRVHrlf3xZbRk1ovA6pUoTWbhwKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdekgdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 B70BA306467D; Tue, 29 Sep 2020 12:06:38 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, arybchenko@solarflare.com Date: Tue, 29 Sep 2020 18:06:37 +0200 Message-ID: <3009264.rAMxf2BjXc@thomas> In-Reply-To: <7452c24f-b5ad-36b1-7e14-af375f902f75@intel.com> References: <20200913220711.3768597-1-thomas@monjalon.net> <20200928231437.414489-28-thomas@monjalon.net> <7452c24f-b5ad-36b1-7e14-af375f902f75@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 27/29] ethdev: remove forcing stopped state upon close 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 29/09/2020 18:01, Ferruh Yigit: > On 9/29/2020 12:14 AM, Thomas Monjalon wrote: > > When closing a port, it is supposed to be already stopped, > > and marked as such with "dev_started" state zeroed. > > > > Resetting "dev_started" before calling the driver close operation > > was hiding the case of not properly stopped port being closed. > > The flag "dev_started" is not changed anymore in "rte_eth_dev_close()". > > > > Signed-off-by: Thomas Monjalon > > --- > > lib/librte_ethdev/rte_ethdev.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > > index d7668114ca..0b8e8e3e8d 100644 > > --- a/lib/librte_ethdev/rte_ethdev.c > > +++ b/lib/librte_ethdev/rte_ethdev.c > > @@ -1716,7 +1716,6 @@ rte_eth_dev_close(uint16_t port_id) > > dev = &rte_eth_devices[port_id]; > > > > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_close); > > - dev->data->dev_started = 0; > > (*dev->dev_ops->dev_close)(dev); > > > > rte_ethdev_trace_close(port_id); > > > > The driver 'remove()' function may be calling the driver 'stop()' dev_ops > internally, so the device will be stopped properly but the 'dev_started' status > won't be updated because ethdev API is not called. If the driver is managing it internally, it should reset the state as well. > This API assumes device stopped and updates the state accordingly, it is not > good but removing it also won't be good for the case device already stopped. > > What do you think calling 'rte_eth_dev_stop()' from 'rte_eth_dev_close()'? I think it would be confusing. Better to let the application and the driver manage "stop" at their best. > Although not sure how to handle driver 'remove()' case. What are you referring to exactly?