From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) by dpdk.org (Postfix) with ESMTP id 1318511DE for ; Fri, 17 Mar 2017 03:48:29 +0100 (CET) Received: by mail-ot0-f172.google.com with SMTP id x37so77672228ota.2 for ; Thu, 16 Mar 2017 19:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2rL/JhN8i2R9Bvr+2QV38YitZCvleGHzLVD1gGz3fNQ=; b=hG9WMTD3MWkKAxx/9WX6Fn1JqaqSnzwpIGFOywB+gbQbHTPOmAUgSQRdSP8wzleYop l8j0zBgnCaNDY+gdt2UOeVJyl4rBK/rKT6jFET1PpeTzOpdCzxh0sMHcXGwvuPpcI+bu GnAlKRWKsUYorFSQ08qLgIgYDZ1CqaUZZsKoRdK9e4aujgzZBTB2tB4+fMNSv3vj0GG7 DA+IjoPk3+0tzof7HEBt3CVZ3z301401VTouCYMCgR+Dom5O/P4oqfgONDD0UP0hBEMZ ju8meocTLDlg40SdF44GUGQGQOCY2ynUb4lgYfNaetAMw/CGb8OogelwwDYI6yr918+1 oDZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2rL/JhN8i2R9Bvr+2QV38YitZCvleGHzLVD1gGz3fNQ=; b=I6Xm7LhIcm3viKBGxEXe+HeBEWVZNF4ZZErEgiyfjcaUguc6qHOzmLRLiKthujii9R wRx5cpfrrbOl/63DdoOZpMVDFVPaX4kQO4YIcnsSh+SFYv0Q+xbudZ9S3N8S4/3vAnkj e44O17mmpcxN5mn0X21y+DjAqSXlwB7vu0AFOGqYYTeoC220OKZMOcUSEM/nctftiu/4 lfY+0c+/I2uu24H2ntPhmvE18WgO/DmdHPkSd9dCD5Zo3lonHXE48aZETqid0K4a29LW AMf3KwZD/qiRK+9qHbY0dj76hZ70WdA6SykVk6No2NsyLmWuPoNBQYf0qyHSTf6Zo1DP FEpg== X-Gm-Message-State: AFeK/H3A1j1NTmFGRtFG20H+Q+TQWumTwlpi9D5oT6i55U8ZZwRyIV8EfrFAcGXm6kwp/zvJB2IVD4z4qEdE4w== X-Received: by 10.157.5.231 with SMTP id 94mr6938239otd.131.1489718908387; Thu, 16 Mar 2017 19:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.55.195 with HTTP; Thu, 16 Mar 2017 19:48:28 -0700 (PDT) In-Reply-To: <20170317020611.GV18844@yliu-dev.sh.intel.com> References: <20170317020611.GV18844@yliu-dev.sh.intel.com> From: Gopakumar Choorakkot Edakkunni Date: Thu, 16 Mar 2017 19:48:28 -0700 Message-ID: To: Yuanhan Liu Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:48:29 -0000 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, because dpdk will ensure that it will do virtio reset before init when it comes up right ? Regarding the vhost commits you mentioned - do we still need those fixes if we have the "virtio reset before init" mechanism ? 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 >