From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 95F643B5 for ; Fri, 17 Mar 2017 05:37:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489725434; x=1521261434; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=3R/Y/uBR25J6LW8fJmaRvp5F9Vpcklg848ooCxQH2io=; b=POhMClGQMx74O/RVrQvP2nl+lS3yPZLSujGaOX/SAU8gqGOc6gynr3xy 7+Ey6svDOQ6jZH1hymZy16ioiM+RDg==; Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 21:37:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,175,1486454400"; d="scan'208";a="76420909" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga005.jf.intel.com with ESMTP; 16 Mar 2017 21:37:12 -0700 Date: Fri, 17 Mar 2017 12:35:26 +0800 From: Yuanhan Liu To: Gopakumar Choorakkot Edakkunni Cc: dev@dpdk.org Message-ID: <20170317043526.GW18844@yliu-dev.sh.intel.com> References: <20170317020611.GV18844@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] virtio "how to restart applications" - //dpdk.org/doc/virtio-net-pmd 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: Fri, 17 Mar 2017 04:37:15 -0000 On Thu, Mar 16, 2017 at 07:48:28PM -0700, Gopakumar Choorakkot Edakkunni wrote: > Thanks a lot for the response Yuanhan. I am using dpdk v16.07. So what you are > saying is that in 16.07, we dont really need to call rte_eth_dev_close() on > exit, It's not about "don't really need", it's more like "it's hard to". Just think that it may crash at any time. > because dpdk will ensure that it will do virtio reset before init when it > comes up right ? No, It just handles the abnormal case well when guest APP restarts. > Regarding the vhost commits you mentioned - do we still need those fixes if we > have the "virtio reset before init" mechanism ? Yes, we still need them: just think some malicious guest may also forge data like that. I'm a bit confused then. Have you actually met any issue (like got stucked) with DPDK v16.07? --yliu > Or that is a seperate problem > altogether (and hence we would need those fixes) ? > > Rgds, > Gopa. > > On Thu, Mar 16, 2017 at 7:06 PM, Yuanhan Liu > wrote: > > On Thu, Mar 16, 2017 at 12:39:16PM -0700, Gopakumar Choorakkot Edakkunni > wrote: > > So the doc says we should call rte_eth_dev_close() *before* going down. > And I > > know that especially in dpdk-virtionet  in the guest + ovs-dpdk in the > host, > > the ovs ends up getting stalled/stuck (!!) if I dont close the port > before > > starting() it when the guest dpdk process comes back up. > > I'm assuming you were using an old version, something like dpdk v2.2? > IIRC, DPDK v16.04 should have fixed your issue. > > > Considering that this not done properly can screw up the HOST ovs, and I > want > > to do everything possible to avoid that, I want to be 200% sure that I > call > > close even if my process gets a kill -9 .. So obviously the only way of > doing > > that is to close the port when the dpdk process comes back up and > *before* we > > init the port. rte_eth_dev_close() is not capable of doing that as it > expects > > the port parameters to be initialized etc.. before it can be called. > > We do virtio reset before init, which is basically what rte_eth_dev_close() > mainly does. So I see no big issue here. > > The stuck issue is due to hugepage reset by the guest DPDK application, > leading all virtio vring elements being mem zeroed. The old vhost doesn't > handle it well, as a result, it got stuck. And here are some relevant > commits: > >     a436f53 vhost: avoid dead loop chain >     c687b0b vhost: check for ring descriptors overflow >     623bc47 vhost: do sanity check for ring descriptor length > >         --yliu > > > Any other > > suggestions on what can be done to close on restart rather than close on > going > > down ? Thought of bouncing this by the alias before I add a version of > close > > myself that can do this close-on-restart > >