[dpdk-dev] [PATCH v3 0/8] Introduce emudev library and iavf emudev driver

[Stephen Hemminger]

On Thu, 14 Jan 2021 14:25:04 +0800
Chenbo Xia <chenbo.xia at intel.com> wrote:

> This series introduces a new device abstraction called emudev for emulated
> devices. A new library (librte_emudev) is implemented. The first emudev
> driver is also introduced, which emulates Intel Adaptive Virtual Function
> (iavf) as a software network device.
> 
> This series has a dependency on librte_vfio_user patch series:
> http://patchwork.dpdk.org/cover/86498/
> 
> Background & Motivation 
> -----------------------
> The disaggregated/multi-process QEMU is using VFIO-over-socket/vfio-user
> as the main transport mechanism to disaggregate IO services from QEMU.
> Therefore, librte_vfio_user is introduced in DPDK to accommodate
> emulated devices for high performance I/O. Although vfio-user library
> provides possibility of emulating devices in DPDK, DPDK does not have
> a device abstraction for emulated devices. A good device abstraction will
> be useful for applications or high performance data path driver. With
> this consideration, emudev library is designed and implemented. It also
> make it possbile to keep modular design on emulated devices by implementing
> data path related logic in a standalone driver (e.g., an ethdev driver)
> and keeps the unrelated logic in the emudev driver.
> 
> Design overview
> ---------------
> 
>                     +---------------------------------------+
>                     |   +---------------+    +-----------+  |
>                     |   |  iavf_emudev  |<-->| data path |  |
>                     |   |    driver     |    |   driver  |  |
>                     |   +---------------+    +-----------+  |
>                     |           |                           |
>                     | --------------------------- VDEV BUS  |
>                     |           |                           |
>                     |   +---------------+                   |
> +--------------+    |   | vdev:         |                   |
> | +----------+ |    |   | /path/to/vfio |                   |
> | | Generic  | |    |   +---------------+                   |
> | | vfio-dev | |    |           |                           |
> | +----------+ |    |           |                           |
> | +----------+ |    |      +----------+                     |
> | | vfio-user| |    |      | vfio-user|                     |
> | | client   | |<---|----->| server   |                     |
> | +----------+ |    |      +----------+                     |
> | QEMU/DPDK    |    | DPDK                                  |
> +--------------+    +---------------------------------------+
> 
> - Generic vfio-dev/vfio-user client/vfio-user server
>   Above concepts are all introduced in librte_vfio_user patch series:
>   http://patchwork.dpdk.org/cover/86498/
> 
> - vdev:/path/to/vfio.
>   It binds to vdev bus driver. The vdev device is defined by DPDK applications
>   through command line as '--vdev=emu_iavf, path=/path/to/socket' in iavf_emudev
>   case. Parameters in command line include device name (emu_iavf) which is used
>   to identify corresponding driver (in this case, iavf_emudev driver),
>   path=/path/to/socket which is used to open the transport interface to vfio-user
>   client in QEMU/DPDK.
> 
> - data path driver.
>   The data path handling is splited to another standalone driver for modular
>   design.
> 
> Why not rawdev for emulated device
> ----------------------------------
> Instead of introducing new class emudev, emulated device could be presented as rawdev.
> However, existing rawdev APIs cannot meet the requirements of emulated device. There are
> three API categories for emudev. They are emudev device lifecycle management, backend
> facing APIs, and emudev device provider facing APIs respectively. Existing rawdev APIs
> could only cover lifecycle management APIs and some of backend facing APIs. Other APIs,
> even if added to rawdev API are not required by other rawdev applications.
> 


This looks interesting but there has been on further work on it for three years.
I recommend that the patch be dropped for now and resubmitted if/when the vfio_user patches
get accepted.