ivampiresp/Spdk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc/vhost: update Vhost-user link and terminology

Browse Source 
Fix broken link to Vhost-user protocol documentation.
Update terminology to match protocol documentation.

Change-Id: Id1aeb0fc8bc99990577efb767ab3dde2411bd664
Signed-off-by: John Kariuki <John.K.Kariuki@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/13849
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
This commit is contained in:
John Kariuki 2022-08-03 09:06:05 -07:00 committed by Tomasz Zawadzki
parent 17948bcaa9
commit ba7331a712
1 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/vhost_processing.md
View File

@ -42,7 +42,7 @@ The initial vhost implementation is a part of the Linux kernel and uses ioctl
interface to communicate with userspace applications. What makes it possible for interface to communicate with userspace applications. What makes it possible for
SPDK to expose a vhost device is Vhost-user protocol. SPDK to expose a vhost device is Vhost-user protocol.
The [Vhost-user specification](https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/interop/vhost-user.txt;hb=HEAD) The [Vhost-user specification](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html)
describes the protocol as follows: describes the protocol as follows:
> [Vhost-user protocol] is aiming to complement the ioctl interface used to > [Vhost-user protocol] is aiming to complement the ioctl interface used to
@ -51,17 +51,19 @@ describes the protocol as follows:
> same host. It uses communication over a Unix domain socket to share file > same host. It uses communication over a Unix domain socket to share file
> descriptors in the ancillary data of the message. > descriptors in the ancillary data of the message.
> >
> The protocol defines 2 sides of the communication, master and slave. Master is > The protocol defines 2 sides of the communication, front-end and back-end.
> the application that shares its virtqueues, in our case QEMU. Slave is the > The front-end is the application that shares its virtqueues, in our case QEMU.
> consumer of the virtqueues. > The back-end is the consumer of the virtqueues.
> >
> In the current implementation QEMU is the Master, and the Slave is intended to > In the current implementation QEMU is the front-end, and the back-end is
> be a software Ethernet switch running in user space, such as Snabbswitch. > the external process consuming the virtio queues, for example a software
> Ethernet switch running in user space, such as Snabbswitch, or a block
> device back-end processing read and write to a virtual disk.
> >
> Master and slave can be either a client (i.e. connecting) or server (listening) > The front-end and back-end can be either a client (i.e. connecting) or
> in the socket communication. > server (listening) in the socket communication.
SPDK vhost is a Vhost-user slave server. It exposes Unix domain sockets and SPDK vhost is a Vhost-user back-end server. It exposes Unix domain sockets and
allows external applications to connect. allows external applications to connect.
## QEMU {#vhost_processing_qemu} ## QEMU {#vhost_processing_qemu}
@ -76,7 +78,7 @@ communicates with SPDK Vhost-SCSI device.
All initialization and management information is exchanged using Vhost-user All initialization and management information is exchanged using Vhost-user
messages. The connection always starts with the feature negotiation. Both messages. The connection always starts with the feature negotiation. Both
the Master and the Slave exposes a list of their implemented features and the front-end and the back-end expose a list of their implemented features and
upon negotiation they choose a common set of those. Most of these features are upon negotiation they choose a common set of those. Most of these features are
implementation-related, but also regard e.g. multiqueue support or live migration. implementation-related, but also regard e.g. multiqueue support or live migration.
@ -94,7 +96,7 @@ the following data:
- user offset - positive offset for the mmap - user offset - positive offset for the mmap
- size - size
The Master will send new memory regions after each memory change - usually The front-end will send new memory regions after each memory change - usually
hotplug/hotremove. The previous mappings will be removed. hotplug/hotremove. The previous mappings will be removed.
Drivers may also request a device config, consisting of e.g. disk geometry. Drivers may also request a device config, consisting of e.g. disk geometry.
@ -116,7 +118,7 @@ polled as soon as they're initialized.
## I/O path {#vhost_processing_io_path} ## I/O path {#vhost_processing_io_path}
The Master sends I/O by allocating proper buffers in shared memory, filling The front-end sends I/O by allocating proper buffers in shared memory, filling
the request data, and putting guest addresses of those buffers into virtqueues. the request data, and putting guest addresses of those buffers into virtqueues.
A Virtio-Block request looks as follows. A Virtio-Block request looks as follows.