From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 76F1DA0679 for ; Tue, 30 Apr 2019 14:46:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D11AC5B36; Tue, 30 Apr 2019 14:46:02 +0200 (CEST) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 0837C2B9C for ; Tue, 30 Apr 2019 14:46:01 +0200 (CEST) Received: by mail-pg1-f196.google.com with SMTP id l18so6784025pgj.6 for ; Tue, 30 Apr 2019 05:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TDG49GNmKu1NoItQaRimT4vlJEnRs5RmP5dQHSJrOE8=; b=Mw+yoWzMbaQV34bqQHSwum7ERhGNjHWwudqnkhVxH6PgECFO2DxCcdE3fETAlqkkCF T7EhWb/J47ygzvV3jLoNIOsdSyShf9F+MJmwSqjv5goTOT1LIqsCkchMK7qdHb8/H+Ek /YZRK8hJNopNlddEMTs4Ye/BJbmKcFFO2xz+YR0HrA60ib0jWUSqPTUevQhUgKi2MsAm 0UB7oBfpa+Jpw0+ra2Ei1JdScBrLKtusciMg55IFwqmqqG730ygQnzyW1ZnXqyZA0jPZ XqT5VPBv98/39peuge26dHoYOQZGmvfWefVj4ZM+Ao3v2+u1rvyJs+11BZ2dLgO69iJR CdQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TDG49GNmKu1NoItQaRimT4vlJEnRs5RmP5dQHSJrOE8=; b=lpA+QDCiJd5gEXrgZH/dTWg9TSSvJm9eLtEzN0ucJcZ0XTSfADWSjwo8NewCDTPeA5 R1hP4iU6fjRjszChr/EhzpRksL1lDu2pw1RjOx+WD57tvu8Ndci2wZmGD+prL3l/iTxe +ngwc6PP0gYhXViyn6APsGPwNtDpV2Py/4dBCf/1gSRnEpXZ9OckkjhIGXBXu1cs0Vlw lvb+JvDUQH88m+xXh8GwT5EC3YjAH3yYL/NFsGn914cb4tGdNnNnacI54h962Ls5lBDP Lk4wekPWvm4kqOPfa5OfS4nGFJ5L0mwNx2r7BQBuFAbV5v9MWH8KxHoXZobXoohGwoc7 6N5A== X-Gm-Message-State: APjAAAXnBonRUWUqPqc6QkEHRTeVRnig7heFsFu1oQvMRnrvkuUGkzNX Q1SNFH/S9cBivSHuzFdqaRY= X-Google-Smtp-Source: APXvYqzJzB+MTqBdn/ZkAB0v7cZwU99izVpaYDlmOHwnZfwbgzg+P5lPzj+PxYKLjGoj+OeD+fI+Xw== X-Received: by 2002:a62:4595:: with SMTP id n21mr71458869pfi.79.1556628360211; Tue, 30 Apr 2019 05:46:00 -0700 (PDT) Received: from gmail.com ([115.113.156.2]) by smtp.gmail.com with ESMTPSA id d25sm48249538pfn.154.2019.04.30.05.45.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 05:45:59 -0700 (PDT) Date: Tue, 30 Apr 2019 18:15:42 +0530 From: Nithin Dabilpuram To: Thomas Monjalon Cc: Ferruh Yigit , "John W. Linville" , Xiaolong Ye , Qi Zhang , Shepard Siegel , Ed Czeck , John Miller , Igor Russkikh , Pavel Belous , Allain Legacy , Matt Peters , Ravi Kumar , Rasesh Mody , Shahed Shaikh , Ajit Khaparde , Somnath Kotur , Chas Williams , Rahul Lakkireddy , Hemant Agrawal , Shreyansh Jain , Wenzhuo Lu , Marcin Wojtas , Michal Krawczyk , Guy Tzalik , Evgeny Schemeilin , Gagandeep Singh , Pankaj Chauhan , John Daley , Hyong Youb Kim , Gaetan Rivet , Xiao Wang , Beilei Xing , Jingjing Wu , Qiming Yang , Konstantin Ananyev , Shijith Thotton , Srisivasubramanian Srinivasan , Matan Azrad , Shahaf Shuler , Yongseok Koh , Zyta Szpak , Liron Himi , Alan Winkowski , Tomasz Duszynski , Stephen Hemminger , "K. Y. Srinivasan" , Haiyang Zhang , Rastislav Cernay , Jan Remes , Alejandro Lucero , Tetsuya Mukawa , Jerin Jacob , Bruce Richardson , Andrew Rybchenko , Jasvinder Singh , Cristian Dumitrescu , Keith Wiles , Maciej Czekaj , Maxime Coquelin , Tiwei Bie , Zhihong Wang , Yong Wang , Anatoly Burakov , dev@dpdk.org Message-ID: <20190430124542.GA16665@gmail.com> References: <30528485.5cHeq7CNxZ@xps> <1748144.UFpUr2FPnr@xps> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <1748144.UFpUr2FPnr@xps> User-Agent: Mutt/1.10.0 (2018-05-17) Subject: Re: [dpdk-dev] CALL to eth PMD maintainers: complete closing of port 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" Message-ID: <20190430124542.LaljUGcfsT3GbliGEN_k-eV6LfSQcbKNKqiBiQP4idg@z> On Mon, Apr 29, 2019 at 10:30:00PM +0200, Thomas Monjalon wrote: > 29/04/2019 18:51, Ferruh Yigit: > > On 4/18/2019 11:59 AM, Thomas Monjalon wrote: > > > Hi all, > > > > > > Since DPDK 18.11, the behaviour of the close operation is changed > > > if RTE_ETH_DEV_CLOSE_REMOVE is enabled in the driver: > > > port is released (i.e. totally freed and data erased) on close. > > > This new behaviour is enabled per driver for a migration period. > > > > > > Looking at the code, you can see these comments: > > > /* old behaviour: only free queue arrays */ > > > RTE_ETHDEV_LOG(DEBUG, "Port closing is using an old behaviour.\n" > > > "The driver %s should migrate to the new behaviour.\n", > > > /* new behaviour: send event + reset state + free all data */ > > > > > > You can find an advice in the commit: > > > http://git.dpdk.org/dpdk/commit/?id=23ea57a2a > > > " > > > When enabling RTE_ETH_DEV_CLOSE_REMOVE, > > > the PMD must free all its private resources for the port, > > > in its dev_close function. > > > It is advised to call the dev_close function in the remove function > > > in order to support removing a device without closing its ports. > > > " > > > > > > It would be great to complete this migration for the next LTS > > > version, which will be 19.11. > > > It means the work should be ideally finished during the summer. > > > > I would like to detail a little more what needs to be done, mainly for the sake > > of the discussion, please comment if something missing/wrong. > > > > There are two exit paths for driver: > > 1) Hotplug remove the device > > rte_dev_remove() OR rte_eal_hotplug_remove() > > > > 2) Application exit: > > rte_eth_dev_close() > > > > > > (1) can be called without ethdev stop and close functions called, so the path > > should cover those functions. > > And in the PMD entry point in this path is .remove() function. In this .remove() > > function PMD should: > > - stop forwarding > > - clean PMD private resources (dev_close() ? ) > > yes > > > - clean ethdev generic resources (rte_eth_dev_release_port() ? ) > > already done in dev_close thanks to RTE_ETH_DEV_CLOSE_REMOVE > > > - remove device resources, which already done by remove APIs > > There can be some specific PMD private resources, > not cleaned when closing a port, to clean in "remove". > > > (2) ethdev won't be usable after "rte_eth_dev_close()" and it should clear PMD > > private and ethdev generic resources. > > With RTE_ETH_DEV_CLOSE_REMOVE flag 'rte_eth_dev_close()' will free generic > > ethdev resources (rte_eth_dev_release_port()) so PMD specific '.dev_close()' should: > > - stop forwarding > > - clean PMD private resources > > yes, but only port-related resources, > not those common with other ports or features of the device. I have a related query. Even after rte_eth_dev_close(), we have to call rte_eal_hotplug_remove() to free up common resource if any and remove the device from application ? And rte_eal_hotplug_remove() would still call drivers .remove function for this. > > > If agreed on above, the task is: > > - '.dev_close()' > > - stop forwarding > > - clean PMD private resources > > > > - '.remove()' > > - call '.dev_close()' > > Yes, looks right. > > > A question is if application should call 'rte_eth_dev_stop()' explicitly before > > close or should it be part of close? For (2) it makes sense app call the stop > > explicitly, but for device remove it is not clear who to stop the forwarding, > > for this case 'dev_close()' stopping forwarding makes things easier. > > "stop" is a prerequisite for "close" anyway. > In most cases, the app should manage "stop" itself to properly free > related resources. > The question is to know whether we return an error on "close" > if the port is not stopped, or we stop it implicitly. > The API says: > * Close a stopped Ethernet device. The device cannot be restarted! > We may explicit the behaviour if the port is not stopped. > >