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

[Yuanhan Liu]

On Thu, Mar 16, 2017 at 07:48:28PM -0700, Gopakumar Choorakkot Edakkunni wrote:
> 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,

It's not about "don't really need", it's more like "it's hard to". Just
think that it may crash at any time.

> because dpdk will ensure that it will do virtio reset before init when it
> comes up right ?

No, It just handles the abnormal case well when guest APP restarts.

> Regarding the vhost commits you mentioned - do we still need those fixes if we
> have the "virtio reset before init" mechanism ?

Yes, we still need them: just think some malicious guest may also forge
data like that.

I'm a bit confused then. Have you actually met any issue (like got stucked)
with DPDK v16.07?

	--yliu

> 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 at 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
> 
>