Re: [Qemu-devel] Contribution - L2TPv3 transport

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Mar 03, 2014 at 02:01:00PM +0000, Anton Ivanov (antivano) wrote:
> On 03/03/14 13:27, Stefan Hajnoczi wrote:
> > 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.
> 
> 
> Multipacket RX can go a very long way and it does not work on tap's 
> emulation of a raw socket. At least in 3.2 :)

Luigi and Vincenzo had ideas on making QEMU's net layer support
multipacket tx using something like TCP_CORK.  This would map to
sendmmsg(2).

Basically the net client gets multiple .receive() calls but is told to
hold off on submitting the packets.  Then, when it finally gets
uncorked, it can sendmmsg(2).  The only issue is we need to hold on to
the tx buffers longer than normal.

> > 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.
> 
> If I read the kernel source correctly the tap fd can emulate a socket 
> for some calls. However, when I try recvmmsg I get an ENOTSOCKET.

The fd is not a real socket.  Confusingly, inside the kernel the tun.c
driver has a "socket" which is used for zero-copy tx by vhost_net.