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.