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....@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
>
>
