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 25911A04B1; Thu, 24 Sep 2020 14:01:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 925271D9EE; Thu, 24 Sep 2020 14:01:06 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 05D211D628 for ; Thu, 24 Sep 2020 14:01:04 +0200 (CEST) IronPort-SDR: Dg37ksFb6srEDUR5v3s4FkHj39rq+DwVDte1HM88410f/p+3bvbHtN0CuELH1SpcEBBNmDgXdn Cha3ltrlUQdg== X-IronPort-AV: E=McAfee;i="6000,8403,9753"; a="160466325" X-IronPort-AV: E=Sophos;i="5.77,297,1596524400"; d="scan'208";a="160466325" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 05:00:56 -0700 IronPort-SDR: hdLvsiIrQWsRHeaa1qqJ1uhdbuyBAB99M7OTO+UaUxt32F1w2szqQUp9+xNxqEQI8KsOEdgzHw FmpzQXyZe4GA== X-IronPort-AV: E=Sophos;i="5.77,297,1596524400"; d="scan'208";a="512131218" 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 05:00:43 -0700 To: Thomas Monjalon Cc: dev@dpdk.org, arybchenko@solarflare.com, Rahul Lakkireddy , Rosen Xu , Shijith Thotton , Srisivasubramanian Srinivasan , Rasesh Mody , Shahed Shaikh , Heinrich Kuhn , Hemant Agrawal , Sachin Saxena , Gagandeep Singh , Akhil Goyal , Alfredo Cardigliano , Ray Kinsella , Neil Horman , John McNamara , Marko Kovacevic , "John W. Linville" , Ciara Loftus , Qi Zhang , Shepard Siegel , Ed Czeck , John Miller , Igor Russkikh , Pavel Belous , Steven Webster , Matt Peters , Somalapuram Amaranath , Ajit Khaparde , Somnath Kotur , Chas Williams , "Wei Hu (Xavier)" , Wei Zhao , Jeff Guo , Marcin Wojtas , Michal Krawczyk , Guy Tzalik , Evgeny Schemeilin , Igor Chauskin , John Daley , Hyong Youb Kim , Gaetan Rivet , Xiao Wang , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , "Min Hu (Connor)" , Yisen Zhuang , Beilei Xing , Jingjing Wu , Qiming Yang , Jakub Grajciar , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Zyta Szpak , Liron Himi , Stephen Hemminger , "K. Y. Srinivasan" , Haiyang Zhang , Long Li , Martin Spinler , Tetsuya Mukawa , Harman Kalra , Jerin Jacob , Nithin Dabilpuram , Kiran Kumar K , Bruce Richardson , Jasvinder Singh , Cristian Dumitrescu , Keith Wiles , Maxime Coquelin , Chenbo Xia , Zhihong Wang , Yong Wang References: <20200913220711.3768597-1-thomas@monjalon.net> <20200913220711.3768597-17-thomas@monjalon.net> <3974758.YRqNSdGFa7@thomas> From: Ferruh Yigit Message-ID: Date: Thu, 24 Sep 2020 13:00:41 +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: <3974758.YRqNSdGFa7@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 16/20] ethdev: remove old close behaviour 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/23/2020 9:41 PM, Thomas Monjalon wrote: > 23/09/2020 18:44, Ferruh Yigit: >> On 9/13/2020 11:07 PM, Thomas Monjalon wrote: >>> * Note 3: >>> The port is supposed to be in a stopped state when it is closed. >>> If it is not the case, it is free to the PMD implementation >>> how to react when trying to close a non-stopped port: >>> either try to stop it automatically or just return an error. >> >> For this note, 'rte_eth_dev_close()' assumes port stopped and sets >> "dev->data->dev_started = 0;" blindly. >> >> should we verify this, or perhaps should call 'rte_eth_dev_stop()' >> within the 'rte_eth_dev_close()' to be sure. > > Good point. I wonder why dev_started is changed in the close. > It is set in rte_eth_dev_stop(), that should be enough. > But clearly it is a different issue which should be adressed separately. > OK >> Also many PMDs doesn't check primary process check in the close, which >> should be fixed too, I wonder if it can be fixed in this series? > > You mean forbid close operation from secondary process? > No need to forbid I think, and the not shared resource cleanup for secondary can be done in close function, but PMDs should have checks for the close calls from secondary processes to not free everything.