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

[Gopakumar Choorakkot Edakkunni <gopakumar.c.e@gmail.com>]

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 <yuanhan.liu@linux.intel.com>
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
>