From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 647B3108F; Mon, 23 Jan 2017 09:25:50 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A4FB14E4C4; Mon, 23 Jan 2017 08:25:50 +0000 (UTC) Received: from [10.36.116.152] (ovpn-116-152.ams2.redhat.com [10.36.116.152]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0N8Pm0B031672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 03:25:49 -0500 To: Yuanhan Liu , dev@dpdk.org References: <1485074820-8956-1-git-send-email-yuanhan.liu@linux.intel.com> <1485074820-8956-3-git-send-email-yuanhan.liu@linux.intel.com> Cc: stable@dpdk.org From: Maxime Coquelin Message-ID: Date: Mon, 23 Jan 2017 09:25:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1485074820-8956-3-git-send-email-yuanhan.liu@linux.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 23 Jan 2017 08:25:50 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 2/3] vhost: fix long stall of vhost-user negotiation 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: Mon, 23 Jan 2017 08:25:50 -0000 On 01/22/2017 09:46 AM, Yuanhan Liu wrote: > 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") > > Cc: stable@dpdk.org > Signed-off-by: Yuanhan Liu > --- > lib/librte_vhost/vhost_user.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Maxime Coquelin Thanks, Maxime