From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id E3DE711DE for ; Fri, 17 Mar 2017 03:08:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489716481; x=1521252481; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=fCuqX146ZdzuFkvOjSYiYrPY6OOkTO41dN4gHcCLsLU=; b=KlxZhx3RQ5iYdma6Uo7Rt6qNTZ9K4crwHIsyFMgjhfdQiNfGoe1smRx+ CgV8zFkgPfNFQIrrOnpIe3Cigi01Wg==; Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 19:08:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,174,1486454400"; d="scan'208";a="945285839" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga003.jf.intel.com with ESMTP; 16 Mar 2017 19:07:58 -0700 Date: Fri, 17 Mar 2017 10:06:11 +0800 From: Yuanhan Liu To: Gopakumar Choorakkot Edakkunni Cc: dev@dpdk.org Message-ID: <20170317020611.GV18844@yliu-dev.sh.intel.com> References: 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 02:08:01 -0000 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