From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arybchenko@solarflare.com> Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id D53485689 for <dev@dpdk.org>; Thu, 18 Oct 2018 09:45:59 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 11100BC006B; Thu, 18 Oct 2018 07:45:58 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Oct 2018 08:45:51 +0100 To: Thomas Monjalon <thomas@monjalon.net>, <ferruh.yigit@intel.com> CC: <dev@dpdk.org>, <ophirmu@mellanox.com>, <bernard.iremonger@intel.com>, <rahul.lakkireddy@chelsio.com> References: <20180907233929.21950-1-thomas@monjalon.net> <20181018012402.1240-1-thomas@monjalon.net> <20181018012402.1240-3-thomas@monjalon.net> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <3763fc32-1db1-1220-079f-fbb6e9fff041@solarflare.com> Date: Thu, 18 Oct 2018 10:45:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181018012402.1240-3-thomas@monjalon.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24162.003 X-TM-AS-Result: No-7.283000-8.000000-10 X-TMASE-MatchedRID: cgbqQT5W8hcOwH4pD14DsPHkpkyUphL9QKuv8uQBDjqbVPV9Ctbcx/DV hLlEzlAWCPQkmxUZFjKEepLbI+P7qIZsGQNfA1lXQpxiLlDD9FVflOpBqBHTt8UmcSma304TMqC UTVmFLuBKbXMPRHW++eXs3RL/C7f1VGs/GsqOCuYD2WXLXdz+AX0tCKdnhB58vqq8s2MNhPAir3 kOMJmHTBQabjOuIvShC24oEZ6SpSkj80Za3RRg8BqBkuaeKo1E2Cz7hFDa+gDqJEpkntCr9m0kn Jp6XwgBmWyOadqFZtg= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--7.283000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24162.003 X-MDID: 1539848759-gMQoQBey22lM Subject: Re: [dpdk-dev] [PATCH v5 2/6] app/testpmd: allow detaching a port not closed 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> X-List-Received-Date: Thu, 18 Oct 2018 07:46:00 -0000 On 10/18/18 4:23 AM, Thomas Monjalon wrote: > The testpmd application aim is for testing; > so order of operations should not be enforced. > > There was a test to forbid detaching before closing a port. > However, it may interesting to test what happens in such case. > It is possible for a PMD to automatically close the port when detaching. Yes. In the case of net/sfc it requires a patch to call sfc_dev_close() from uninit. I think network PMD maintainers should be notified to double-check drivers. > in order to avoid a crash, it is checked that the port must be stopped > before detaching (as for closing). I thought that it is sufficient to stop traffic and the port may be stopped automatically by PMD. Not sure about it, just would like to clarify my previous notes. > Signed-off-by: Thomas Monjalon <thomas@monjalon.net> [...]