From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <thomas@monjalon.net>
Cc: dev@dpdk.org, arybchenko@solarflare.com,
 Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
 Rosen Xu <rosen.xu@intel.com>, Shijith Thotton <sthotton@marvell.com>,
 Srisivasubramanian Srinivasan <srinivasan@marvell.com>,
 Rasesh Mody <rmody@marvell.com>, Shahed Shaikh <shshaikh@marvell.com>,
 Heinrich Kuhn <heinrich.kuhn@netronome.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>,
 Sachin Saxena <sachin.saxena@nxp.com>, Gagandeep Singh <g.singh@nxp.com>,
 Akhil Goyal <akhil.goyal@nxp.com>, Alfredo Cardigliano
 <cardigliano@ntop.org>, Ray Kinsella <mdr@ashroe.eu>,
 Neil Horman <nhorman@tuxdriver.com>, John McNamara
 <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com>,
 "John W. Linville" <linville@tuxdriver.com>,
 Ciara Loftus <ciara.loftus@intel.com>, Qi Zhang <qi.z.zhang@intel.com>,
 Shepard Siegel <shepard.siegel@atomicrules.com>,
 Ed Czeck <ed.czeck@atomicrules.com>,
 John Miller <john.miller@atomicrules.com>,
 Igor Russkikh <igor.russkikh@aquantia.com>,
 Pavel Belous <pavel.belous@aquantia.com>,
 Steven Webster <steven.webster@windriver.com>,
 Matt Peters <matt.peters@windriver.com>,
 Somalapuram Amaranath <asomalap@amd.com>,
 Ajit Khaparde <ajit.khaparde@broadcom.com>,
 Somnath Kotur <somnath.kotur@broadcom.com>, Chas Williams <chas3@att.com>,
 "Wei Hu (Xavier)" <xavier.huwei@huawei.com>, Wei Zhao <wei.zhao1@intel.com>,
 Jeff Guo <jia.guo@intel.com>, Marcin Wojtas <mw@semihalf.com>,
 Michal Krawczyk <mk@semihalf.com>, Guy Tzalik <gtzalik@amazon.com>,
 Evgeny Schemeilin <evgenys@amazon.com>, Igor Chauskin <igorch@amazon.com>,
 John Daley <johndale@cisco.com>, Hyong Youb Kim <hyonkim@cisco.com>,
 Gaetan Rivet <grive@u256.net>, Xiao Wang <xiao.w.wang@intel.com>,
 Ziyang Xuan <xuanziyang2@huawei.com>,
 Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>,
 Guoyang Zhou <zhouguoyang@huawei.com>, "Min Hu (Connor)"
 <humin29@huawei.com>, Yisen Zhuang <yisen.zhuang@huawei.com>,
 Beilei Xing <beilei.xing@intel.com>, Jingjing Wu <jingjing.wu@intel.com>,
 Qiming Yang <qiming.yang@intel.com>, Jakub Grajciar <jgrajcia@cisco.com>,
 Matan Azrad <matan@mellanox.com>, Shahaf Shuler <shahafs@mellanox.com>,
 Viacheslav Ovsiienko <viacheslavo@mellanox.com>, Zyta Szpak
 <zr@semihalf.com>, Liron Himi <lironh@marvell.com>,
 Stephen Hemminger <sthemmin@microsoft.com>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Long Li <longli@microsoft.com>,
 Martin Spinler <spinler@cesnet.cz>, Tetsuya Mukawa <mtetsuyah@gmail.com>,
 Harman Kalra <hkalra@marvell.com>, Jerin Jacob <jerinj@marvell.com>,
 Nithin Dabilpuram <ndabilpuram@marvell.com>,
 Kiran Kumar K <kirankumark@marvell.com>,
 Bruce Richardson <bruce.richardson@intel.com>,
 Jasvinder Singh <jasvinder.singh@intel.com>,
 Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
 Keith Wiles <keith.wiles@intel.com>,
 Maxime Coquelin <maxime.coquelin@redhat.com>,
 Chenbo Xia <chenbo.xia@intel.com>, Zhihong Wang <zhihong.wang@intel.com>,
 Yong Wang <yongwang@vmware.com>
References: <20200913220711.3768597-1-thomas@monjalon.net>
 <20200913220711.3768597-17-thomas@monjalon.net>
 <c1ee8da5-c34e-bf87-fb51-dcecbf58ea99@intel.com> <3974758.YRqNSdGFa7@thomas>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <fc7dc18e-a0ad-a71a-9ae1-2543f1789734@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.