Virtio is a para-virtualization framework initiated by IBM, and supported by KVM hypervisor. In the Data Plane Development Kit (DPDK), we provide a virtio Poll Mode Driver (PMD) as a software solution, comparing to SRIOV hardware solution, for fast guest VM to guest VM communication and guest VM to host communication.
Vhost is a kernel acceleration module for virtio qemu backend. The DPDK extends kni to support vhost raw socket interface, which enables vhost to directly read/ write packets from/to a physical port. With this enhancement, virtio could achieve quite promising performance.
For basic qemu-KVM installation and other Intel EM poll mode driver in guest VM, please refer to Chapter “Driver for VM Emulated Devices”.
In this chapter, we will demonstrate usage of virtio PMD driver with two backends, standard qemu vhost back end and vhost kni back end.
For details about the virtio spec, refer to the latest VIRTIO (Virtual I/O) Device Specification.
As a PMD, virtio provides packet reception and transmission callbacks.
In Rx, packets described by the used descriptors in vring are available for virtio to burst out.
In Tx, packets described by the used descriptors in vring are available for virtio to clean. Virtio will enqueue to be transmitted packets into vring, make them available to the device, and then notify the host back end if necessary.
In this release, the virtio PMD driver provides the basic functionality of packet reception and transmission.
The following prerequisites apply:
This section demonstrates kni vhost back end example setup for Phy-VM Communication.
Host2VM Communication Example Using kni vhost Back End
Host2VM communication example
Load the kni kernel module:
insmod rte_kni.ko
Other basic DPDK preparations like hugepage enabling, uio port binding are not listed here. Please refer to the DPDK Getting Started Guide for detailed instructions.
Launch the kni user application:
examples/kni/build/app/kni -l 0-3 -n 4 -- -p 0x1 -P --config="(0,1,3)"
This command generates one network device vEth0 for physical port. If specify more physical ports, the generated network device will be vEth1, vEth2, and so on.
For each physical port, kni creates two user threads. One thread loops to fetch packets from the physical NIC port into the kni receive queue. The other user thread loops to send packets in the kni transmit queue.
For each physical port, kni also creates a kernel thread that retrieves packets from the kni receive queue, place them onto kni’s raw socket’s queue and wake up the vhost kernel thread to exchange packets with the virtio virt queue.
For more details about kni, please refer to Kernel NIC Interface.
Enable the kni raw socket functionality for the specified physical NIC port, get the generated file descriptor and set it in the qemu command line parameter. Always remember to set ioeventfd_on and vhost_on.
Example:
echo 1 > /sys/class/net/vEth0/sock_en
fd=`cat /sys/class/net/vEth0/sock_fd`
exec qemu-system-x86_64 -enable-kvm -cpu host \
-m 2048 -smp 4 -name dpdk-test1-vm1 \
-drive file=/data/DPDKVMS/dpdk-vm.img \
-netdev tap, fd=$fd,id=mynet_kni, script=no,vhost=on \
-device virtio-net-pci,netdev=mynet_kni,bus=pci.0,addr=0x3,ioeventfd=on \
-vnc:1 -daemonize
In the above example, virtio port 0 in the guest VM will be associated with vEth0, which in turns corresponds to a physical port, which means received packets come from vEth0, and transmitted packets is sent to vEth0.
In the guest, bind the virtio device to the uio_pci_generic kernel module and start the forwarding application. When the virtio port in guest bursts Rx, it is getting packets from the raw socket’s receive queue. When the virtio port bursts Tx, it is sending packet to the tx_q.
modprobe uio
echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
modprobe uio_pci_generic
python usertools/dpdk-devbind.py -b uio_pci_generic 00:03.0
We use testpmd as the forwarding application in this example.
Running testpmd
Use IXIA packet generator to inject a packet stream into the KNI physical port.
The packet reception and transmission flow path is:
IXIA packet generator->82599 PF->KNI Rx queue->KNI raw socket queue->Guest VM virtio port 0 Rx burst->Guest VM virtio port 0 Tx burst-> KNI Tx queue ->82599 PF-> IXIA packet generator
Host2VM Communication Example Using qemu vhost Back End
qemu-system-x86_64 -enable-kvm -cpu host -m 2048 -smp 2 -mem-path /dev/
hugepages -mem-prealloc
-drive file=/data/DPDKVMS/dpdk-vm1
-netdev tap,id=vm1_p1,ifname=tap0,script=no,vhost=on
-device virtio-net-pci,netdev=vm1_p1,bus=pci.0,addr=0x3,ioeventfd=on
-device pci-assign,host=04:10.1 \
In this example, the packet reception flow path is:
IXIA packet generator->82599 PF->Linux Bridge->TAP0’s socket queue-> Guest VM virtio port 0 Rx burst-> Guest VM 82599 VF port1 Tx burst-> IXIA packet generator
The packet transmission flow is:
IXIA packet generator-> Guest VM 82599 VF port1 Rx burst-> Guest VM virtio port 0 Tx burst-> tap -> Linux Bridge->82599 PF-> IXIA packet generator
Virtio driver has 6 Rx callbacks and 3 Tx callbacks.
Rx callbacks:
Tx callbacks:
By default, the non-vector callbacks are used:
Vector callbacks will be used when:
The corresponding callbacks are:
There is no vector callbacks for packed virtqueue for now.
Example of using the vector version of the virtio poll mode driver in testpmd:
testpmd -l 0-2 -n 4 -- -i --rxq=1 --txq=1 --nb-cores=1
In-order callbacks only work on simulated virtio user vdev.
For split virtqueue:
For packed virtqueue, the default callbacks already support the in-order feature.
There are three kinds of interrupts from a virtio device over PCI bus: config interrupt, Rx interrupts, and Tx interrupts. Config interrupt is used for notification of device configuration changes, especially link status (lsc). Interrupt mode is translated into Rx interrupts in the context of DPDK.
Note
Virtio PMD already has support for receiving lsc from qemu when the link status changes, especially when vhost user disconnects. However, it fails to do that if the VM is created by qemu 2.6.2 or below, since the capability to detect vhost user disconnection is introduced in qemu 2.7.0.
To support Rx interrupts, #. Check if guest kernel supports VFIO-NOIOMMU:
Linux started to support VFIO-NOIOMMU since 4.8.0. Make sure the guest kernel is compiled with:
CONFIG_VFIO_NOIOMMU=y
Properly set msix vectors when starting VM:
Enable multi-queue when starting VM, and specify msix vectors in qemu cmdline. (N+1) is the minimum, and (2N+2) is mostly recommended.
$(QEMU) ... -device virtio-net-pci,mq=on,vectors=2N+2 ...
In VM, insert vfio module in NOIOMMU mode:
modprobe vfio enable_unsafe_noiommu_mode=1 modprobe vfio-pci
In VM, bind the virtio device with vfio-pci:
python usertools/dpdk-devbind.py -b vfio-pci 00:03.0
Here we use l3fwd-power as an example to show how to get started.
Example:
$ l3fwd-power -l 0-1 -- -p 1 -P --config="(0,0,1)" \ --no-numa --parse-ptype
Below devargs are supported by the PCI virtio driver:
vdpa:
A virtio device could also be driven by vDPA (vhost data path acceleration) driver, and works as a HW vhost backend. This argument is used to specify a virtio device needs to work in vDPA mode. (Default: 0 (disabled))
Below devargs are supported by the virtio-user vdev:
path:
It is used to specify a path to connect to vhost backend.
mac:
It is used to specify the MAC address.
cq:
It is used to enable the control queue. (Default: 0 (disabled))
queue_size:
It is used to specify the queue size. (Default: 256)
queues:
It is used to specify the queue number. (Default: 1)
iface:
It is used to specify the host interface name for vhost-kernel backend.
server:
It is used to enable the server mode when using vhost-user backend. (Default: 0 (disabled))
mrg_rxbuf:
It is used to enable virtio device mergeable Rx buffer feature. (Default: 1 (enabled))
in_order:
It is used to enable virtio device in-order feature. (Default: 1 (enabled))
packed_vq:
It is used to enable virtio device packed virtqueue feature. (Default: 0 (disabled))
Logically virtio-PMD has 9 paths based on the combination of virtio features (Rx mergeable, In-order, Packed virtqueue), below is an introduction of these features:
If packed virtqueue is not negotiated, below split virtqueue paths will be selected according to below configuration:
If packed virtqueue is negotiated, below packed virtqueue paths will be selected according to below configuration:
Refer to above description, virtio path and corresponding Rx/Tx callbacks will be selected automatically. Rx callbacks and Tx callbacks for each virtio path are shown in below table:
Virtio paths | Rx callbacks | Tx callbacks |
---|---|---|
Split virtqueue mergeable path | virtio_recv_mergeable_pkts | virtio_xmit_pkts |
Split virtqueue non-mergeable path | virtio_recv_pkts | virtio_xmit_pkts |
Split virtqueue in-order mergeable path | virtio_recv_pkts_inorder | virtio_xmit_pkts_inorder |
Split virtqueue in-order non-mergeable path | virtio_recv_pkts_inorder | virtio_xmit_pkts_inorder |
Split virtqueue vectorized Rx path | virtio_recv_pkts_vec | virtio_xmit_pkts |
Packed virtqueue mergeable path | virtio_recv_mergeable_pkts_packed | virtio_xmit_pkts_packed |
Packed virtqueue non-meregable path | virtio_recv_pkts_packed | virtio_xmit_pkts_packed |
Packed virtqueue in-order mergeable path | virtio_recv_mergeable_pkts_packed | virtio_xmit_pkts_packed |
Packed virtqueue in-order non-mergeable path | virtio_recv_pkts_packed | virtio_xmit_pkts_packed |
Virtio feature implementation:
All virtio paths support status are shown in below table:
Virtio paths | 16.11 ~ 18.05 | 18.08 ~ 18.11 | 19.02 ~ 19.11 |
---|---|---|---|
Split virtqueue mergeable path | Y | Y | Y |
Split virtqueue non-mergeable path | Y | Y | Y |
Split virtqueue vectorized Rx path | Y | Y | Y |
Split virtqueue simple Tx path | Y | N | N |
Split virtqueue in-order mergeable path | Y | Y | |
Split virtqueue in-order non-mergeable path | Y | Y | |
Packed virtqueue mergeable path | Y | ||
Packed virtqueue non-mergeable path | Y | ||
Packed virtqueue in-order mergeable path | Y | ||
Packed virtqueue in-order non-mergeable path | Y |
If you meet performance drop or some other issues after upgrading the driver or configuration, below steps can help you identify which path you selected and root cause faster.