From patchwork Fri May 13 06:16:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yuanhan Liu X-Patchwork-Id: 12731 X-Patchwork-Delegate: yuanhan.liu@linux.intel.com Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id B2AFA95EF; Fri, 13 May 2016 08:11:32 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id B916495CE for ; Fri, 13 May 2016 08:11:29 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 12 May 2016 23:11:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,612,1455004800"; d="scan'208";a="975524159" Received: from yliu-dev.sh.intel.com ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 12 May 2016 23:11:28 -0700 From: Yuanhan Liu To: dev@dpdk.org Cc: huawei.xie@intel.com, Traynor Kevin , marcandre.lureau@redhat.com, Yuanhan Liu , "Michael S. Tsirkin" Date: Thu, 12 May 2016 23:16:30 -0700 Message-Id: <1463120192-24200-5-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1463120192-24200-1-git-send-email-yuanhan.liu@linux.intel.com> References: <1462603224-29510-1-git-send-email-yuanhan.liu@linux.intel.com> <1463120192-24200-1-git-send-email-yuanhan.liu@linux.intel.com> Subject: [dpdk-dev] [PATCH v2 4/6] vhost: workaround stale vring base X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" When DPDK app crashes (or quits, or gets killed), a restart of DPDK app would get stale vring base from QEMU. That would break the kernel virtio net completely, making it non-work any more, unless a driver reset is done. So, instead of getting the stale vring base from QEMU, Huawei suggested we could get a much saner (and may not the most accurate) vring base from used->idx. That would work because: - there is a memory barrier between updating used ring entries and used->idx. So, even though we crashed at updating the used ring entries, it will not cause any issue, as the guest driver will not process those stale used entries, for used-idx is not updated yet. - DPDK process vring in order, that means a crash may just lead some packet retransmission for Tx and drop for Rx. Cc: "Michael S. Tsirkin" Suggested-by: Huawei Xie Signed-off-by: Yuanhan Liu Acked-by: "Michael S. Tsirkin" Acked-by: Huawei Xie --- v2: log on packets resent for Tx and drop for Rx --- lib/librte_vhost/virtio-net.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c index 835ab3a..bd7e55e 100644 --- a/lib/librte_vhost/virtio-net.c +++ b/lib/librte_vhost/virtio-net.c @@ -561,6 +561,15 @@ vhost_set_vring_addr(int vid, struct vhost_vring_addr *addr) return -1; } + if (vq->last_used_idx != vq->used->idx) { + RTE_LOG(WARNING, VHOST_CONFIG, + "last_used_idx (%u) and vq->used->idx (%u) mismatches; " + "some packets maybe resent for Tx and dropped for Rx\n", + vq->last_used_idx, vq->used->idx); + vq->last_used_idx = vq->used->idx; + vq->last_used_idx_res = vq->used->idx; + } + vq->log_guest_addr = addr->log_guest_addr; LOG_DEBUG(VHOST_CONFIG, "(%d) mapped address desc: %p\n",