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 7DC51A04B1; Thu, 24 Sep 2020 15:06:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 577391DE32; Thu, 24 Sep 2020 15:06:51 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 67E781DDED for ; Thu, 24 Sep 2020 15:06:49 +0200 (CEST) IronPort-SDR: 89vDF1fnPQ0QZPkm5lW2D1l7nhfNGSwgYL5LeEm5pMXA6gXo8VZM7Cm/Gto1+ohX1GtEaDW6Ek J7CG2SBVcfuQ== X-IronPort-AV: E=McAfee;i="6000,8403,9753"; a="148842349" X-IronPort-AV: E=Sophos;i="5.77,297,1596524400"; d="scan'208";a="148842349" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 06:06:48 -0700 IronPort-SDR: 5kHpVaS9oMNDy6ASBphsD7/zGbWeGxO9+JXl6Z248Y8MASU6BRYfIcDKcREhI1fNTm+7LkyVx8 fI7d/rXGqe2Q== X-IronPort-AV: E=Sophos;i="5.77,297,1596524400"; d="scan'208";a="512150279" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.85.112]) ([10.251.85.112]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 06:06:46 -0700 To: Thomas Monjalon Cc: dev@dpdk.org, arybchenko@solarflare.com, Wenzhuo Lu , Beilei Xing , Bernard Iremonger References: <20200913220711.3768597-1-thomas@monjalon.net> <26171115.May8GztZaD@thomas> <7f70403e-79f7-b3de-6a7b-a83571251810@intel.com> <5482678.jQLLJtJmLa@thomas> From: Ferruh Yigit Message-ID: <792c4feb-a128-75c4-c00d-8ed27fea45ed@intel.com> Date: Thu, 24 Sep 2020 14:06:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <5482678.jQLLJtJmLa@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 19/20] app/testpmd: reset port status on close notification 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" On 9/24/2020 1:17 PM, Thomas Monjalon wrote: > 24/09/2020 14:07, Ferruh Yigit: >> On 9/23/2020 9:32 PM, Thomas Monjalon wrote: >>> 23/09/2020 18:45, Ferruh Yigit: >>>> On 9/13/2020 11:07 PM, Thomas Monjalon wrote: >>>>> Since rte_eth_dev_release_port() is called on all port close operations, >>>>> the event RTE_ETH_EVENT_DESTROY can be reliably used for resetting >>>>> the port status on the application side. >>>>> >>>>> The intermediate state RTE_PORT_HANDLING is removed in close_port() >>>>> because a port can also be closed by a PMD in a device remove operation. >>>>> >>>>> In case multiple ports are closed, calling remove_invalid_ports() >>>>> only once is enough. >>>>> >>>>> Signed-off-by: Thomas Monjalon >>>> >>>> <...> >>>> >>>>> @@ -3118,6 +3093,13 @@ eth_event_callback(portid_t port_id, enum rte_eth_event_type type, void *param, >>>>> rmv_port_callback, (void *)(intptr_t)port_id)) >>>>> fprintf(stderr, "Could not set up deferred device removal\n"); >>>>> break; >>>>> + case RTE_ETH_EVENT_DESTROY: >>>>> + if (rte_atomic16_cmpset(&(ports[port_id].port_status), >>>>> + RTE_PORT_STOPPED, >>>>> + RTE_PORT_CLOSED) == 0) >>>>> + printf("Port %d cannot be set to closed\n", port_id); >>>>> + printf("Port %u is closed\n", port_id); >>>>> + break; >>>> >>>> This is failing if a port closed without application port stop command, >>>> PMD may be doing port stop within the close function but since >>>> application didn't give the stop command, the port status is not >>>> 'RTE_PORT_STOPPED', hence 'port_status' is not updated correctly. >>> >>> Do you think we should give up with the atomic state transition, >>> and just assign the state as closed? >>> >> >> It can be better, if the DESTROY event received it should be in closed >> state. > > I don't understand your proposal. > Note that we are not managing ethdev states here. > Despite the misleading RTE prefix, it is a testpmd state. > I am aware this is testpmd state, but basically saying same thing, force the 'closed' state. >> Right now device can be hot removed while running, or it may be closed >> before it has been stopped, both cases state transition assumption from >> stopped->closed will be wrong, and final state will be wrong. > > I think we should force the state, not matter what it was before. > >