Bug 25

We would like to have similar TCP throughput and latency performance to
multi-queue tap devices, in both directions, guest-to-host and host-to-guest.

This is relevant for KubeVirt, as they could more safely replace the existing
network bindings with passt. Looking at slide 21 here:
  https://static.sched.com/hosted_files/kvmforum2022/01/passt_kubevirt_kvm_forum_2022_final.pdf

passt already exceeds VM-to-VM performance (measuring both paths in series) for
a regular tap device in KubeVirt's masquerade binding (that's simply tap plus
NAT done with nftables). However, we still have a gap when tap devices are
configured with 8 queues.

With vhost-user, we should be able to make this gap much smaller, because we
avoid qemu-side copies from/to the kernel.

The vhost-user back-end already supports multiple queues, by the way, so at that
point we could sensibly try out multi-threading, too.