From patchwork Tue Jun 7 04:05:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yuanhan Liu X-Patchwork-Id: 13273 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 6D0976CC7; Tue, 7 Jun 2016 06:04:23 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A50B86CCD for ; Tue, 7 Jun 2016 06:04:20 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 06 Jun 2016 21:04:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,431,1459839600"; d="scan'208";a="996647241" Received: from yliu-dev.sh.intel.com ([10.239.67.162]) by fmsmga002.fm.intel.com with ESMTP; 06 Jun 2016 21:04:18 -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: Tue, 7 Jun 2016 12:05:06 +0800 Message-Id: <1465272308-3572-5-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1465272308-3572-1-git-send-email-yuanhan.liu@linux.intel.com> References: <1463120192-24200-1-git-send-email-yuanhan.liu@linux.intel.com> <1465272308-3572-1-git-send-email-yuanhan.liu@linux.intel.com> Subject: [dpdk-dev] [PATCH v3 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",