[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Contribution - L2TPv3 transport
From: |
Anton Ivanov (antivano) |
Subject: |
Re: [Qemu-devel] Contribution - L2TPv3 transport |
Date: |
Tue, 4 Mar 2014 09:47:09 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 |
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.