From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jt9WM-0003j5-Ml for qemu-devel@nongnu.org; Mon, 05 May 2008 18:50:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jt9WL-0003hm-3i for qemu-devel@nongnu.org; Mon, 05 May 2008 18:50:57 -0400 Received: from [199.232.76.173] (port=47137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jt9WL-0003hW-0Y for qemu-devel@nongnu.org; Mon, 05 May 2008 18:50:57 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jt9WK-00089k-IT for qemu-devel@nongnu.org; Mon, 05 May 2008 18:50:56 -0400 Received: by py-out-1112.google.com with SMTP id u52so1675793pyb.10 for ; Mon, 05 May 2008 15:50:56 -0700 (PDT) Message-ID: <481F8F4B.5030007@codemonkey.ws> Date: Mon, 05 May 2008 17:50:51 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [4341] qemu: generate signals on tap I/O References: <481F84F3.6060505@flac.kalibalik.dk> <481F86F3.4080007@aurel32.net> <481F8D57.40500@flac.kalibalik.dk> In-Reply-To: <481F8D57.40500@flac.kalibalik.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Aurelien Jarno Anders wrote: > Aurelien Jarno wrote: > >> That's why I reverted that commit, it was for my local tree only, I >> committed it accidentally (along with a few other patches). > > Ah, okay. I only read the subject of your reverts, which did not > mention 4341. > >>> I posted a more complete implementation a few weeks ago, anything wrong >>> with it? >>> >>> http://thread.gmane.org/gmane.comp.emulators.qemu/24567 >> >> People saying it is not the way to go, and I have still haven't decided >> myself if it is a correct solution or not. >> > > The current code is also not a correct solution. > > Well, I will just keep it in my local tree. BTW, the biggest problem with tap networking in QEMU seems to be packet loss. The fd_can_read handler is completely ignored for tap which means that if the device isn't ready to receive a packet, the packet is simply dropped. I have a patch that fixes this but the only driver that has a proper fd_can_read handler right now is virtio-net. I plan on including this tap fix in my next round of virtio patches. Addressing the packet loss issue improves TCP streaming performance by 4x. In contrast, eliminating the copy in the virtio-net device only improves performance by about 10% (although it will probably be a lot more when tun/tap supports zero-copy). Regards, Anthony Liguori > > Cheers, > Anders. > >