From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EEB32A04D9; Wed, 2 Sep 2020 23:10:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 52901137D; Wed, 2 Sep 2020 23:10:58 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 3A882DE0 for ; Wed, 2 Sep 2020 23:10:56 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 4D10D58033A; Wed, 2 Sep 2020 17:10:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 02 Sep 2020 17:10:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= VoDsl5k7HXFzTxMwJ4Wirc3Ny5YpF8p4nwqQU76Ya0o=; b=KTTbqlEMB6l84H7l nbGnKRPex6lp0BPU1+4pgT3KJRLZUn9077QdYN5J8OOki8cJiPBX8VtkVkASEHei K2VybdumwzUZxHHO1RgI5eAx5izBsC+T5CzGV53Z4GLdhoCcrVxQ0uxC9uR5TB4q m9VUFdp3w7zlGDrKAXUNNUbNrD74YOsb0G/7ZEUiFc22880dh9vRlw9CCUuo+PZZ /BETBz2CH4gUm4lczdmizqL8iEmtcP2wpAI3IHUnIwhkF6i9mLMorqb0SP6hE8SB Y6eDCNvSjf4CoXHuLKczm9rrvwZbs0xEAyWybtYJy9LK/WQCFsjsFd1rg1rgwYAQ SPYVHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=VoDsl5k7HXFzTxMwJ4Wirc3Ny5YpF8p4nwqQU76Ya 0o=; b=aO9Z8+PX+47gQYJfoPE2DkHX+c8FSHvtayaoArgl5on4FJgmp90NYstMJ SGt15P47cVZQPsY/FebeRiL9hEbmiIpirC9Lr140Nnrrk3HyBqX+2IH5Dtk5XXSQ 44dAQpP7yoEMQyj+h8K1KOcHSiwNuYGY3F9I7L7o8O+1zg4apbvUjpOPewsekfuk /IvCGqXCH2cLkd0cW8bjTCyEsRSrHusTqXXgriz02mJ04OtOgd9TRyK7cnxcKZpD vo6Mmm8+OhQ+HqYfuhxORgZzhvzwcaJhv9F0NfOoVM5s6mr7ff6VzdQp+crWVNk9 mLNyi1kQ5bDAigFN77QCQUu/LA/Aw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefledgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeeutefhffehgfelkeejveehgefftefhfeeigfefjedthfdvkeeg heffleevveffudenucffohhmrghinhepshgthhgvugdrtghomhdpqhgvmhhurdhorhhgne cukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A64C0328005D; Wed, 2 Sep 2020 17:10:51 -0400 (EDT) From: Thomas Monjalon To: Chenbo Xia Cc: dev@dpdk.org, xuan.ding@intel.com, xiuchun.lu@intel.com, cunming.liang@intel.com, changpeng.liu@intel.com, zhihong.wang@intel.com, Stephen Hemminger , bruce.richardson@intel.com, anatoly.burakov@intel.com, david.marchand@redhat.com, maxime.coquelin@redhat.com, matan@nvidia.com, Adrian Moreno Date: Wed, 02 Sep 2020 23:10:50 +0200 Message-ID: <2372333.5epvb6RKAP@thomas> In-Reply-To: <20200814191606.26312-1-chenbo.xia@intel.com> References: <20200814191606.26312-1-chenbo.xia@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 14/08/2020 21:16, Chenbo Xia: > Background & Motivation > ----------------------- > In order to reduce the attack surface, QEMU community is disaggregating QEMU by > removing part of device emulation from it. The disaggregated/multi-process QEMU > is using VFIO-over-socket/vfio-user as the main transport mechanism to disaggregate > I/O services from QEMU[2]. Vfio-user essentially implements the VFIO device model > presented to the user process by a set of messages over a unix-domain socket. The > main difference between application using vfio-user and application using vfio > kernel module is that device manipulation is based on socket messages for vfio-user > but system calls for vfio kernel module. The vfio-user devices consist of a generic > VFIO device type, living in QEMU, which is called the client[3], and the core device > implementation (emulated device), living outside of QEMU, which is called the server. > > With the introduction and support of vfio-user in QEMU, QEMU is explicitly adding > support for external emulated device and data path. We are trying to leverage that > and introducing vfio-user support in DPDK. By doing so, DPDK is enabled to be an > alternative I/O device emulation library of building virtualized devices along with > high-performance data path in separate processes outside QEMU. It will be easy for > hardware vendors to provide virtualized solutions of their hardware devices by > implementing emulated device in DPDK. > > Except for vfio-user introduced in DPDK, this series also introduces the first > emulated device implementation. That is emulated AVF device (avf_emudev) implemented > by AVF emulation driver (avf_emudev driver). Emulated AVF device demos how emulated > device could be implemented in DPDK. SPDK is also investigating to implement use case > for NVMe. I am completely unaware of this change in QEMU. I've found this presentation about Multi-process QEMU by Oracle: https://static.sched.com/hosted_files/kvmforum2019/d2/kvm-mpqemu.pdf and there is the wiki page you already referenced: https://wiki.qemu.org/Features/MultiProcessQEMU I guess virtio stays inside QEMU? What is really moving out? e1000, ne2000 and vmxnet3? Why emulated AVF is needed, compared to a simple VFIO passthrough?