On Fri, Feb 28, 2014 at 08:28:11AM +0000, Anton Ivanov (antivano) wrote: > 3. Qemu to communicate with the local host, remote vms, network devices, > etc at speeds which for a number of use cases exceed the speed of the > legacy tap driver.
This surprises me. It's odd that tap performs significantly worse. I guess you have two options for using kernel L2TPv3 support: 1. Use a bridge and tap to forward between the L2TPv3 interface and the QEMU. 2. Use macvtap on top of the L2TPv3 interface (if possible). Option #2 should be faster. Now about the tap userspace ABI, is the performance bottleneck that the read(2) system call only receives one packet at a time? The tap file descriptor is not a socket so recvmmsg(2) cannot be used on it directly. I have wondered in the past whether something like packet mmap would be possible on a tap device. At that point userspace just waits for notifications and the actual packets don't require any syscalls. > Our suggestion would be that this over time obsoletes the UDP variety of > the "socket" driver. Yes, thank you! L2TPv3 looks like a good replacement for the "socket" driver. Will review and respond to your patch in detail. Stefan
