From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 978A25B32 for ; Wed, 17 Oct 2018 13:33:46 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CB5C821DC4; Wed, 17 Oct 2018 07:33:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 17 Oct 2018 07:33:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=nIpKSrRNOY9x/Re/WNRt0Tna1dMHX8Wjt8Em1sKnaYA=; b=hDbPWfQTKVMq N1Aj0Sgv3rJHfLhQQMS/HV+u8yCyHynodVDK/Ft1andYLehH8ITyzMcWLYvptArK yiEPyX7Yl8TrimLMt56MJMqyCkTCfYWnlJL3rNZhzJZpH5cLbRwpSyrKqncu5UDo oxkdNv2J+C1wT1JCRiYxK9m2g7XanNU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=nIpKSrRNOY9x/Re/WNRt0Tna1dMHX8Wjt8Em1sKna YA=; b=RR2QXS+6yHEFd6yNb7zGFali6FcFAWeHZsFGsOkk+z73bQBfISCelPjuo 2cbJ4tbN2xpaHdCf6g+Qu7QVAkWzVCshi0HfD2zzm6vd/Dz3n+LIjrlP2uZIgBls i5Qg76Cc7KVhsvT0P3yxuahxVbBoK2baVx8BR69hNn91gtvlJGDXJpbWyX2okZcR 4PBW6jIMrFHHaXaqJebrvCXQOlECzpxCmVyKDvd/w5Mmk7Le0ONxZd0EKodw2cCd wJPFEmx4rIigmXHawuqv23iHELS8TBfVkqYwEPwChn96ezEwboKTPT4izK5b/h23 tb4cuLj9/0ctphrl3fnwwH13MCyPw== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F2CFE4412; Wed, 17 Oct 2018 07:33:44 -0400 (EDT) From: Thomas Monjalon To: "Iremonger, Bernard" Cc: Andrew Rybchenko , "Yigit, Ferruh" , "dev@dpdk.org" , "ophirmu@mellanox.com" Date: Wed, 17 Oct 2018 13:33:48 +0200 Message-ID: <3413444.RgHUR81Cio@xps> In-Reply-To: <8CEF83825BEC744B83065625E567D7C260D1268E@IRSMSX107.ger.corp.intel.com> References: <20180907233929.21950-1-thomas@monjalon.net> <2356863.vgucDQR85H@xps> <8CEF83825BEC744B83065625E567D7C260D1268E@IRSMSX107.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/4] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 11:33:46 -0000 17/10/2018 12:30, Iremonger, Bernard: > Hi Thomas, > > From: Thomas Monjalon > > 17/10/2018 08:26, Andrew Rybchenko: > > > On 10/17/18 4:54 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. > > > > > > > > Signed-off-by: Thomas Monjalon > > > > > > I'm afraid it could be a problem which the patch, since port close > > > ensures that the port is not used for traffic forwarding. > > > Right now the check is gone and we can detach port which is used for > > > traffic forwarding on separate data cores. > > > So, almost guaranteed crash. > > > > Yes I can duplicate this check in detach_port(). > > I agree with Andrew that this will cause a crash. As I answered, I will add a check that port is stopped. > I don't understand why the sequence is changing here. > The close(), detach() sequence has been in place since the port hot plug work some years ago, user applications may already be using this sequence. I explained the reason in the commit log: Adding too much checks is wrong for a test application. We must be free to call detach without close.