From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by dpdk.org (Postfix) with ESMTP id 08D4C11DE for ; Fri, 17 Mar 2017 05:56:02 +0100 (CET) Received: by mail-ot0-f182.google.com with SMTP id o24so79158099otb.1 for ; Thu, 16 Mar 2017 21:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aoYGFw8TdX4cYryqXR4yUau+wEAIvVlXCm6THDGjzOI=; b=OkC9mxPAAvXr9rB3oxiHYZ/2I4FjVloEkrpVtCsSs/Vx749Utl6nDUTH+HSf2MR1Qh atH95cUtZJv9CBFYrPYK1TsWTHEH16leRuuMcYp+oqGEzfWDDA47dkz3X238hLthIHkm Tqfju6kPdZ6/OuTiUyCU2iKhYN78Y9/cGsTkNJfkcghIKuAQqyZ2FJEt9uc0ei7X7VKB MC0Yrxu+ua12t43qb2X9KsxV63sd04G8SrApTv76U6A7SlUjB9FL0oig+PhcrbF5URBe A60imKNPGSw0k+Fw0sPNZRZRcB4wtPk4y9UwMfPWdv61cMVa4i9LMeumGrqUSN2dNrqL p7kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aoYGFw8TdX4cYryqXR4yUau+wEAIvVlXCm6THDGjzOI=; b=OJPJcxtSVo+jaOVOT7ooxzs/t595P58jBaZcu5MNMGcJTVrWx8Uehh861P0zJXBakb Dsa8hlfkNMPHnSYH/WLM6Ipk4rhDLPkjOuCH1Ehl8yord9yw/QA2+GQwrAiPEIMkxye+ tSaXVIWKhnndvMSDzDgMA73855L7JpZOe1vaF/lEwQ5ZnrdTNWaf9CofJcyUI5bl5kK/ 7shmLm7XFPtVp1hL/6fAcLvuJAhhZ8qpuQZVm75+G+AdA+ddi9M5V88mFkwBrdSFtTfP YHzXbdgUmwiFOJj+G6PLAQRfOtLMccsNNZZ4oAdeuYao25v4iDm8/FhRu5pYxAFD5KQA T78Q== X-Gm-Message-State: AFeK/H0lqBYsLmLsn1anEgQl+F5uF3fYUJhnPOX3JQZw/JijPUHVfVwaiSCeT3lbJF/JQkSE2EDIxWcuaW5j2A== X-Received: by 10.157.21.26 with SMTP id u26mr6340461otf.187.1489726562280; Thu, 16 Mar 2017 21:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.55.195 with HTTP; Thu, 16 Mar 2017 21:56:01 -0700 (PDT) In-Reply-To: <20170317043526.GW18844@yliu-dev.sh.intel.com> References: <20170317020611.GV18844@yliu-dev.sh.intel.com> <20170317043526.GW18844@yliu-dev.sh.intel.com> From: Gopakumar Choorakkot Edakkunni Date: Thu, 16 Mar 2017 21:56:01 -0700 Message-ID: To: Yuanhan Liu Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] virtio "how to restart applications" - //dpdk.org/doc/virtio-net-pmd X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 04:56:03 -0000 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 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@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 > > > > >