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

[Gopakumar Choorakkot Edakkunni]

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 ?

~# ovs-vswitchd --version
ovs-vswitchd (Open vSwitch) 2.4.1
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
> >
> >
>