From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 98D699E7 for ; Wed, 15 Feb 2017 07:24:39 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2017 22:24:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,164,1484035200"; d="scan'208";a="1094927442" Received: from yliu-dev.sh.intel.com ([10.239.67.162]) by orsmga001.jf.intel.com with ESMTP; 14 Feb 2017 22:24:38 -0800 From: Yuanhan Liu To: Yuanhan Liu Cc: Maxime Coquelin , dpdk stable Date: Wed, 15 Feb 2017 14:26:15 +0800 Message-Id: <1487140012-13314-3-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1487140012-13314-1-git-send-email-yuanhan.liu@linux.intel.com> References: <1487140012-13314-1-git-send-email-yuanhan.liu@linux.intel.com> Subject: [dpdk-stable] patch 'vhost: fix long stall of negotiation' has been queued to stable release 16.11.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 06:24:40 -0000 Hi, FYI, your patch has been queued to stable release 16.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 02/18/17. So please shout if anyone has objections. Thanks. --yliu --- >>From a65fa5bd927ce2a496b04241bca29c94c3fbfe7e Mon Sep 17 00:00:00 2001 From: Yuanhan Liu Date: Sun, 22 Jan 2017 16:46:59 +0800 Subject: [PATCH] vhost: fix long stall of negotiation [ upstream commit b8b992e93f387b0d0dda00b9feb6adb05ffe081c ] Setting up the mapping from GPA (guest physical address) to HPA (guest physical address) could be very time consuming when the guest memory is backened with small pages (4K). The bigger the guest memory, the longer it takes. This could lead a very long vhost-user negotiation. Since the mapping is only needed in zero copy mode so far, we could avoid such time consuming settup when zero copy is turned off (which is the default case). It's actually a workaround, a right fix might be to start a new thread, and hide the big latency there. Fixes: e246896178e6 ("vhost: get guest/host physical address mappings") Signed-off-by: Yuanhan Liu Reviewed-by: Maxime Coquelin --- lib/librte_vhost/vhost_user.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c index 50cb6d1..0cb1c67 100644 --- a/lib/librte_vhost/vhost_user.c +++ b/lib/librte_vhost/vhost_user.c @@ -567,7 +567,8 @@ vhost_user_set_mem_table(struct virtio_net *dev, struct VhostUserMsg *pmsg) reg->host_user_addr = (uint64_t)(uintptr_t)mmap_addr + mmap_offset; - add_guest_pages(dev, reg, alignment); + if (dev->dequeue_zero_copy) + add_guest_pages(dev, reg, alignment); RTE_LOG(INFO, VHOST_CONFIG, "guest memory region %u, size: 0x%" PRIx64 "\n" -- 1.9.0