DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Chenbo Xia <chenbo.xia@intel.com>
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 <stephen@networkplumber.org>,
	bruce.richardson@intel.com, anatoly.burakov@intel.com,
	david.marchand@redhat.com, maxime.coquelin@redhat.com,
	matan@nvidia.com, Adrian Moreno <amorenoz@redhat.com>
Subject: Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK
Date: Wed, 02 Sep 2020 23:10:50 +0200	[thread overview]
Message-ID: <2372333.5epvb6RKAP@thomas> (raw)
In-Reply-To: <20200814191606.26312-1-chenbo.xia@intel.com>

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?




  parent reply	other threads:[~2020-09-02 21:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-14 19:16 Chenbo Xia
2020-08-14 15:00 ` Stephen Hemminger
2020-08-17  2:58   ` Xia, Chenbo
2020-08-14 19:16 ` [dpdk-dev] [RFC v1 1/2] vfio_user: Add library for vfio over socket Chenbo Xia
2020-08-14 19:16 ` [dpdk-dev] [RFC v1 2/2] emudev: Add library for emulated device Chenbo Xia
2020-09-02 21:10 ` Thomas Monjalon [this message]
2020-09-03  6:29   ` [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK Xia, Chenbo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2372333.5epvb6RKAP@thomas \
    --to=thomas@monjalon.net \
    --cc=amorenoz@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=changpeng.liu@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=cunming.liang@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=matan@nvidia.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=stephen@networkplumber.org \
    --cc=xiuchun.lu@intel.com \
    --cc=xuan.ding@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).