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