From patchwork Thu Jun 23 13:57:21 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Herakliusz Lipiec X-Patchwork-Id: 113348 X-Patchwork-Delegate: maxime.coquelin@redhat.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EA5E5A0093; Thu, 23 Jun 2022 15:52:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9194940146; Thu, 23 Jun 2022 15:52:58 +0200 (CEST) Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 78A8840042; Thu, 23 Jun 2022 15:52:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655992376; x=1687528376; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=iD1+hsvCR7F7ybFW0RV8gTgnN2GC0Vf8XVdQR54TFIo=; b=jhg5Gl3tt4Df5ImgflykLDuutJ6Dl551wlmZc7IHNoZ5T6rQX5G3oHek n0BR2Jl9A41QAEEZ24zz3usNgvtHAS2HLx10h2qCBaJseHAWU2mSviTV6 haHgJnx8gNZc3zNHomIbf7zN7bxujM0mEM0I6oxlKrsUO+baZCbERPKoD fa2p7l9PKLZWotSRJeAhw6PSDIQmtTcsa7uGJ2//BVyzg+SF2cnvWHf3M XHOWies/kS8L8sl6gBQpIiL7dkUzy84ujHbXRXaXXflC9DHDDkOcB0Qkc awqbdopjWJJeNpALo5hK9aCQv0qtWHXSCr/AqmJ3c8SauJYakzlUccN2F g==; X-IronPort-AV: E=McAfee;i="6400,9594,10386"; a="342406572" X-IronPort-AV: E=Sophos;i="5.92,216,1650956400"; d="scan'208";a="342406572" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2022 06:52:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,216,1650956400"; d="scan'208";a="592715619" Received: from silpixa00399499.ir.intel.com (HELO silpixa00399499.ger.corp.intel.com) ([10.237.223.138]) by fmsmga007.fm.intel.com with ESMTP; 23 Jun 2022 06:52:53 -0700 From: Herakliusz Lipiec To: maxime.coquelin@redhat.com, chenbo.xia@intel.com Cc: dev@dpdk.org, Herakliusz Lipiec , stable@dpdk.org Subject: [PATCH v2] doc/prog_guide: fix readability in lib vhost prog guide Date: Thu, 23 Jun 2022 14:57:21 +0100 Message-Id: <20220623135721.1779466-1-herakliusz.lipiec@intel.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220527173120.30050-1-herakliusz.lipiec@intel.com> References: <20220527173120.30050-1-herakliusz.lipiec@intel.com> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org fix grammar issues and readbility in vhost library programmer guide Fixes: 768274ebbd5e ("vhost: avoid populate guest memory") Cc: stable@dpdk.org Signed-off-by: Herakliusz Lipiec Reviewed-by: Chenbo Xia --- doc/guides/prog_guide/vhost_lib.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst index 606edee940..4675347ee5 100644 --- a/doc/guides/prog_guide/vhost_lib.rst +++ b/doc/guides/prog_guide/vhost_lib.rst @@ -351,7 +351,7 @@ vhost-user implementation has two options: * The vhost supported features must be exactly the same before and after the restart. For example, if TSO is disabled and then enabled, - nothing will work and issues undefined might happen. + nothing will work and undefined issues might happen. No matter which mode is used, once a connection is established, DPDK vhost-user will start receiving and processing vhost messages from QEMU. @@ -382,12 +382,12 @@ Guest memory requirement * Memory pre-allocation - For non-async data path, guest memory pre-allocation is not a - must. This can help save of memory. If users really want the guest memory - to be pre-allocated (e.g., for performance reason), we can add option - ``-mem-prealloc`` when starting QEMU. Or, we can lock all memory at vhost - side which will force memory to be allocated when mmap at vhost side; - option --mlockall in ovs-dpdk is an example in hand. + For non-async data path guest memory pre-allocation is not a + must but can help save memory. To do this we can add option + ``-mem-prealloc`` when starting QEMU, or we can lock all memory at vhost + side which will force memory to be allocated when it calls mmap + (option --mlockall in ovs-dpdk is an example in hand). + For async data path, we force the VM memory to be pre-allocated at vhost lib when mapping the guest memory; and also we need to lock the memory to @@ -395,8 +395,8 @@ Guest memory requirement * Memory sharing - Make sure ``share=on`` QEMU option is given. vhost-user will not work with - a QEMU version without shared memory mapping. + Make sure ``share=on`` QEMU option is given. The vhost-user will not work with + a QEMU instance without shared memory mapping. Vhost supported vSwitch reference ---------------------------------