From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CB48C06510 for ; Tue, 2 Jul 2019 15:58:28 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id D6A692082F for ; Tue, 2 Jul 2019 15:58:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6A692082F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 54C8E1B9D4; Tue, 2 Jul 2019 17:58:26 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A35491B9C7 for ; Tue, 2 Jul 2019 17:58:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2019 08:58:23 -0700 X-IronPort-AV: E=Sophos;i="5.63,443,1557212400"; d="scan'208";a="315282983" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.30]) ([10.237.221.30]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/AES256-SHA; 02 Jul 2019 08:58:21 -0700 To: Nithin Dabilpuram , Thomas Monjalon Cc: dev@dpdk.org, Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , ndabilpuram@marvell.com, jerinj@marvell.com References: <20190513112112.7069-1-ndabilpuram@marvell.com> <1750613.yctpDDeXOX@xps> <20190517085547.GA26094@gmail.com> <3849744.ELThORf4eq@xps> <20190520125053.GA1399@gmail.com> <20190529081620.GA5044@gmail.com> From: "Yigit, Ferruh" Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@linux.intel.com; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQkI71rKFiEE 0jZTh0IuwoTjmYHH+TPrQ98TYR8FAlznMMQFCwkIBwMFFQoJCAsFFgIDAQAACgkQ+TPrQ98T YR/B9Q//a57esjq996nfZVm7AsUl7zbvhN+Ojity25ib2gcSVVsAN2j6lcQS4hf6/OVvRj3q CgebJ4o2gXR6X12UzWBJL7NE8Xpc70MvUIe0r11ykurQ9n9jUaWMjxdSqBPF93hU+Z/MZe5M 1rW5O2VJLuTJzkDw3EYUCbHOwPjeaS8Qqj3RI0LYbGthbHBIp9CsjkgsJSjTT5GQ8AQWkE7I z+hvPx6f1rllfjxFyi4DI3jLhAI+j1Nm+l+ESyoX59HrLTHAvq4RPkLpTnGBj9gOnJ+5sVEr GE0fcffsNcuMSkpqSEoJCPAHmChoLgezskhhsy0BiU3xlSIj1Dx2XMDerUXFOK3ftlbYNRte HQy4EKubfZRB8H5Rvcpksom3fRBDcJT8zw+PTH14htRApU9f8I/RamQ7Ujks7KuaB7JX5QaG gMjfPzHGYX9PfF6KIchaFmAWLytIP1t0ht8LpJkjtvUCSQZ2VxpCXwKyUzPDIF3co3tp90o7 X07uiC5ymX0K0+Owqs6zeslLY6DMxNdt8ye+h1TVkSZ5g4dCs4C/aiEF230+luL1CnejOv/K /s1iSbXQzJNM7be3FlRUz4FdwsfKiJJF7xYALSBnSvEB04R7I2P2V9Zpudkq6DRT6HZjBeJ1 pBF2J655cdoenPBIeimjnnh4K7YZBzwOLJf2c6u76fe5Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXOcvZgUJBvIWKAAKCRD5M+tD3xNhHxhBD/9toXMIaPIVFd9w1nKsRDM1GE6gZe4jie8q MJpeHB9O+936fSXA0W2X0het60wJQQ45O8TpTcxpc9nGzcE4MTaLAI3E8TjIXAO0cPqUNLyp g0DXezmTw5BU+SKZ51+jSKOtFmzJCHOJZQaMeCHD+G3CrdUHQVQBb5AeuH3KFv9ltgDcWsc8 YO70o3+tGHwcEnyXLdrI0q05wV7ncnLdkgVo+VUN4092bNMPwYly1TZWcU3Jw5gczOUEfTY7 sgo6E/sGX3B+FzgIs5t4yi1XOweCAQ/mPnb6uFeNENEFyGKyMG1HtjwBqnftbiFO3qitEIUY xWGQH23oKscv7i9lT0gg2D+ktzZhVWwHJVY/2vWSB9aCSWChcH2BT+lWrkwSpoPhy+almM84 Qz2wF72/d4ce4L27pSrS+vOXtXHLGOOGcAn8yr9TV0kM4aR+NbGBRXGKhG6w4lY54uNd9IBa ARIPUhij5JSygxZCBaJKo+X64AHGkk5bXq+f0anwAMNuJXbYC/lz4DEdKmPgQGShOWNs1Y1a N3cI87Hun/RBVwQ0a3Tr1g6OWJ6xK8cYbMcoR8NZ7L9ALMeJeuUDQR39+fEeHg/6sQN0P0mv 0sL+//BAJphCzDk8ztbrFw+JaPtgzZpRSM6JhxnY+YMAsatJRXA0WSpYP5zzl7yu/GZJIgsv VQ== Message-ID: Date: Tue, 2 Jul 2019 16:58:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190529081620.GA5044@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] app/testpmd: change port detach interface 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 5/29/2019 9:16 AM, Nithin Dabilpuram wrote: > Hi Thomas, > > On Mon, May 20, 2019 at 06:20:53PM +0530, Nithin Dabilpuram wrote: >> On Fri, May 17, 2019 at 10:59:38AM +0200, Thomas Monjalon wrote: >>> 17/05/2019 10:55, Nithin Dabilpuram: >>>> On Wed, May 15, 2019 at 09:27:22AM +0200, Thomas Monjalon wrote: >>>>> 15/05/2019 08:52, Nithin Dabilpuram: >>>>>> Hi Thomas, >>>>>> On Tue, May 14, 2019 at 05:39:30PM +0200, Thomas Monjalon wrote: >>>>>>> Hi, >>>>>>> >>>>>>> 13/05/2019 13:21, Nithin Dabilpuram: >>>>>>>> With the latest published interface of >>>>>>>> rte_eal_hotplug_[add,remove](), and rte_eth_dev_close(), >>>>>>>> rte_eth_dev_close() would cleanup all the data structures of >>>>>>>> port's eth dev leaving the device common resource intact >>>>>>>> if RTE_ETH_DEV_CLOSE_REMOVE is set in dev flags. >>>>>>>> So "port detach" (~hotplug remove) should be able to work, >>>>>>>> with device identifier like "port attach" as eth_dev could have >>>>>>>> been closed already and rte_eth_devices[port_id] reused. >>>>>>> >>>>>>> "port attach" uses devargs as identifier because there >>>>>>> is no port id before creating it. But "detach port" uses >>>>>>> logically the port id to close. >>>>>> >>>>>> But if "port close" was already called on that port, >>>>>> eth_dev->state would be set as RTE_ETH_DEV_UNUSED and >>>>>> that port id could be reused. >>>>>> So after "port close" if we call "port detach", isn't it >>>>>> incorrect to use the same port id ? >>>>> >>>>> Yes it is incorrect to close a port which is already closed :) >>>>> >>>>>>>> This change alters "port detach" cmdline interface to >>>>>>>> work with device identifier like "port attach". >>>>>>> >>>>>>> The word "port" means an ethdev port, so it should be >>>>>>> referenced with a port id. >>>>>>> If you want to close an EAL rte_device, then you should >>>>>>> rename the command. >>>>>>> But testpmd purpose should be to work with ethdev ports only. >>>>>> >>>>>> Renaming the command to "detach " ? >>>>> >>>>> Yes something like that. >>>>> But why do you want to manage rte_device in testpmd? >>>>> Being able to close ports in not enough? >>>>> Please describe a scenario. >>>>> >>>> >>>> We just want to support testing hotplug detach along with >>>> hotplug attach from testpmd. Currently there is no way to detach >>>> if we close the port first. >>> >>> OK >> So can I send next revision with command renamed to "detach " ? > > Any info on this ? I can even add it as another cmd without disturbing existing > command if needed. This sounds better option to me. I see the need to remove device via 'identifier' but also still it is easier to use 'port_id' for removal when applicable, so I am for keeping it. What do you think adding a new command: 'device detach' Also testpmd doesn't dead with 'device' much, it mainly works in port level, because of this does it make sense to add another command something like: "show device info all" > >>> >>>> Another reason is that in our new PMD, for detaching one specific port, >>>> we need more than one try as the PMD might return -EAGAIN. >>>> So with the current "port detach" implementation, after closing the port, >>>> if PMD returns -EAGAIN for rte_dev_remove() call, there is no way to >>>> try it again. >>> >>> This is a bug. >>> Should we catch -EAGAIN somewhere? >> >> It is already caught in local_dev_remove() and >> rte_dev_remove() fails. Only problem as I said below is >> in testpmd if first call to detach_port_device() i.e handler of "port detach", >> rte_dev_remove() returns -EAGAIN and PMD cleaned up the resources partially like eth_dev >> resources, the second time call cannot work port_id will not be valid anymore. >> >>> >>>