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:
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.