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.
