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

[Yuanhan Liu]

On Thu, Mar 16, 2017 at 09:56:01PM -0700, Gopakumar Choorakkot Edakkunni wrote:
> Hi Yuanhan,
> 
> Thanks for the confirmation about not having to do anything special to close
> the ports on dpdk going down or coming up.
> 
> As for the question about if I met any issue of ovs getting stuck - yes, my
> guest process runs dpdk 16.07 as I mentioned earlier - and if I kill my guest
> process, then the host OVS-dpdk on the host reports stall ! The OVS-dpdk and
> emu versions I use are as below. But maybe that is because of the ovs missing
> the fixes you mentioned ?

When I was saying dpdk version, I meant the DPDK version with OVS.

> ~# ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 2.4.1

And yes, the fixes are not included in the DPDK required for OVS 2.4.

	--yliu

> Compiled Nov 14 2016 06:53:31
> # kvm --version
> QEMU emulator version 2.2.0, Copyright (c) 2003-2008 Fabrice Bellard
> ~#
> 
> 
> Rgds,
> Gopa.
> 
> On Thu, Mar 16, 2017 at 9:35 PM, Yuanhan Liu <yuanhan.liu at linux.intel.com>
> wrote:
> 
>     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
>     >
>     >
> 
>