[dpdk-dev] virtio "how to restart applications" - //dpdk.org/doc/virtio-net-pmd

[Yuanhan Liu]

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