From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6A9E2A04A6; Mon, 24 Jan 2022 09:36:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 29A6140DDD; Mon, 24 Jan 2022 09:36:58 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 5E4EC40040 for ; Mon, 24 Jan 2022 09:36:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643013416; x=1674549416; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GCMf5nmda+C+MTvx6XBULHLFzcEnOljjR6HSxcAQrw0=; b=U5WZSv2ydL0yaOLdFGAnHwBbr6YdLDDiPOD1wBiwjEw/JjAShVYTP87i k0LJZyf0dtOT3owhugiN+DWJTm/AhTNximVBa7X/MPw0aLr9yP6vLcvIc 5F0YHt40Ey3msyS4PA7steMKZmIPwlkyi0srTDxtjaE2pWxALCMeiSjrv /poOjn1YKr7GjL3xZJCPezLFBr1ckxldJdHoVU2HiIJe8k10WuNj+hxgc 21VMRQwWqh/ghvBBsm+LG22RMQgNmwaNtlyOWIpCP1ajcC6imWsxYCIBn B0wYZdvAxW0WFb0rO9AC5Wa8Hue9ZeUxfKNn5Y2ujvtKvC2E6blelqbrU w==; X-IronPort-AV: E=McAfee;i="6200,9189,10236"; a="243592420" X-IronPort-AV: E=Sophos;i="5.88,311,1635231600"; d="scan'208";a="243592420" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2022 00:36:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,311,1635231600"; d="scan'208";a="627415195" Received: from npgdpdkvirtiojiayuhu117.sh.intel.com ([10.67.119.202]) by orsmga004.jf.intel.com with ESMTP; 24 Jan 2022 00:36:52 -0800 From: Jiayu Hu To: dev@dpdk.org Cc: maxime.coquelin@redhat.com, i.maximets@ovn.org, chenbo.xia@intel.com, bruce.richardson@intel.com, harry.van.haaren@intel.com, sunil.pai.g@intel.com, john.mcnamara@intel.com, xuan.ding@intel.com, cheng1.jiang@intel.com, liangma@liangbit.com, Jiayu Hu Subject: [PATCH v2 0/1] integrate dmadev in vhost Date: Mon, 24 Jan 2022 11:40:10 -0500 Message-Id: <20220124164011.1402593-1-jiayu.hu@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211230215505.329674-1-jiayu.hu@intel.com> References: <20211230215505.329674-1-jiayu.hu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Since dmadev is introduced in 21.11, to avoid the overhead of vhost DMA abstraction layer and simplify application logics, this patch integrates dmadev in vhost. To enable the flexibility of using DMA devices in different function modules, not limited in vhost, vhost doesn't manage DMA devices. Applications, like OVS, need to manage and configure DMA devices and tell vhost what DMA device to use in every dataplane function call. In addition, vhost supports M:N mapping between vrings and DMA virtual channels. Specifically, one vring can use multiple different DMA channels and one DMA channel can be shared by multiple vrings at the same time. The reason of enabling one vring to use multiple DMA channels is that it's possible that more than one dataplane threads enqueue packets to the same vring with their own DMA virtual channels. Besides, the number of DMA devices is limited. For the purpose of scaling, it's necessary to support sharing DMA channels among vrings. As only enqueue path is enabled DMA acceleration, the new dataplane functions are like: 1). rte_vhost_submit_enqueue_burst(vid, queue_id, pkts, count, dma_id, dma_vchan): Get descriptors and submit copies to DMA virtual channel for the packets that need to be send to VM. 2). rte_vhost_poll_enqueue_completed(vid, queue_id, pkts, count, dma_id, dma_vchan): Check completed DMA copies from the given DMA virtual channel and write back corresponding descriptors to vring. OVS needs to call rte_vhost_poll_enqueue_completed to clean in-flight copies on previous call and it can be called inside rxq_recv function, so that it doesn't require big change in OVS datapath. For example: netdev_dpdk_vhost_rxq_recv() { ... qid = rxq->queue_id * VIRTIO_QNUM + VIRTIO_RXQ; rte_vhost_poll_enqueue_completed(vid, qid, ...); } Change log ========== v1 -> v2: - add SW fallback if rte_dma_copy() reports error - print error if rte_dma_completed() reports error - add poll_factor while call rte_dma_completed() for scatter-gaher packets - use trylock instead of lock in rte_vhost_poll_enqueue_completed() - check if dma_id and vchan_id valid - input dma_id in rte_vhost_async_dma_configure() - remove useless code, brace and hardcode in vhost example - redefine MAX_VHOST_DEVICE to RTE_MAX_VHOST_DEVICE - update doc and comments rfc -> v1: - remove useless code - support dynamic DMA vchannel ring size (rte_vhost_async_dma_configure) - fix several bugs - fix typo and coding style issues - replace "while" with "for" - update programmer guide - support share dma among vhost in vhost example - remove "--dma-type" in vhost example Jiayu Hu (1): vhost: integrate dmadev in asynchronous datapath doc/guides/prog_guide/vhost_lib.rst | 95 ++++----- examples/vhost/Makefile | 2 +- examples/vhost/ioat.c | 218 -------------------- examples/vhost/ioat.h | 63 ------ examples/vhost/main.c | 255 ++++++++++++++++++----- examples/vhost/main.h | 11 + examples/vhost/meson.build | 6 +- lib/vhost/meson.build | 2 +- lib/vhost/rte_vhost.h | 2 + lib/vhost/rte_vhost_async.h | 132 +++++------- lib/vhost/version.map | 3 + lib/vhost/vhost.c | 148 ++++++++++---- lib/vhost/vhost.h | 64 +++++- lib/vhost/vhost_user.c | 2 + lib/vhost/virtio_net.c | 305 +++++++++++++++++++++++----- 15 files changed, 744 insertions(+), 564 deletions(-) delete mode 100644 examples/vhost/ioat.c delete mode 100644 examples/vhost/ioat.h -- 2.25.1