From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 4/5] kvm: qemu: Use vringfd to eliminate copies Date: Mon, 16 Jun 2008 09:02:55 -0500 Message-ID: <4856728F.4020501@us.ibm.com> References: <1213365481-23460-1-git-send-email-markmc@redhat.com> <1213365481-23460-5-git-send-email-markmc@redhat.com> <48545422.1040109@us.ibm.com> <200806161210.57926.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark McLoughlin , Avi Kivity , kvm@vger.kernel.org To: Rusty Russell Return-path: Received: from e1.ny.us.ibm.com ([32.97.182.141]:45120 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458AbYFPODP (ORCPT ); Mon, 16 Jun 2008 10:03:15 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m5GE3Cph010910 for ; Mon, 16 Jun 2008 10:03:12 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5GE3BJ8189424 for ; Mon, 16 Jun 2008 10:03:11 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5GE3B9w003386 for ; Mon, 16 Jun 2008 10:03:11 -0400 In-Reply-To: <200806161210.57926.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: Rusty Russell wrote: > On Sunday 15 June 2008 09:28:34 Anthony Liguori wrote: > >> Have you benchmarked the driver? I wasn't seeing great performance >> myself although I think that was due to some bugs in the vringfd code. >> > > Yeah, every time I get close to benchmarking I find another bug :( But I've > spent some time optimising the normal lguest net device, so we'll have a fair > comparison. > > In theory vringfd will get us zero copy from guest sendfile out to external > machines. For anything else we're doing a copy anyway, so avoiding copying > has no great benefit. > There's nothing that prevents zero-copy to be implemented for tun without vringfd. In fact, I seem to recall that your earlier patches implemented zero-copy :-) I like the vringfd model and I think it's a good way to move forward. My concern is that it introduces an extra syscall in the TX path. Right now, we do a single write call whereas with vringfd we need to insert the TX packet into the queue, do a notify, and then wait for indication that the TX has succeeded. I know we'll win with TSO but we don't need vringfd for TSO. The jury's still out IMHO as to whether we should do vringfd or just try to merge TSO tun patches. Regards, Anthony Liguori > The interface is still worthwhile to provide zero-copy receive on intelligent > or bound NICs, but that's science fiction at the moment... > > Cheers, > Rusty. >