Re: [Qemu-devel] Contribution - L2TPv3 transport

["Anton Ivanov (antivano)" <antivano@cisco.com>]

On 04/03/14 09:36, Stefan Hajnoczi wrote:
> 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.

Cool, I will be happy to give a hand with that.

My main problem so far trying to implement it has been the timers - the 
qemu internal timer API has no relative timers, only absolute. So you 
end up with a very high cost of setting and checking a delayed xmit timer.

>
>>> 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.
That explains it.

Otherwise I am nearly done incorporating all comments. An updated 
version should be available some time this week.

A.