From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Gopakumar Choorakkot Edakkunni <gopakumar.c.e@gmail.com>
Cc: dev@dpdk.org
Subject: Re: virtio "how to restart applications" - //dpdk.org/doc/virtio-net-pmd
Date: Fri, 17 Mar 2017 10:06:11 +0800 [thread overview]
Message-ID: <20170317020611.GV18844@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <CABK1yFCi1s1syB5JG=U_q7LKW=5tXEdgAczVjgH2npgEARRYDQ@mail.gmail.com>
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
next prev parent reply other threads:[~2017-03-17 2:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 19:39 virtio "how to restart applications" - //dpdk.org/doc/virtio-net-pmd Gopakumar Choorakkot Edakkunni
2017-03-17 2:06 ` Yuanhan Liu [this message]
2017-03-17 2:48 ` Gopakumar Choorakkot Edakkunni
2017-03-17 4:35 ` Yuanhan Liu
2017-03-17 4:56 ` Gopakumar Choorakkot Edakkunni
2017-03-17 5:13 ` Yuanhan Liu
2017-03-17 5:20 ` Gopakumar Choorakkot Edakkunni
2017-03-17 5:24 ` Yuanhan Liu
2017-03-17 5:30 ` Gopakumar Choorakkot Edakkunni
2017-03-17 5:40 ` Yuanhan Liu
2017-03-17 5:50 ` Gopakumar Choorakkot Edakkunni
2017-03-18 21:32 ` Gopakumar Choorakkot Edakkunni
2017-03-18 21:37 ` Gopakumar Choorakkot Edakkunni
2017-03-18 23:43 ` Gopakumar Choorakkot Edakkunni
2017-03-22 5:32 ` Gopakumar Choorakkot Edakkunni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170317020611.GV18844@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=gopakumar.c.e@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).