From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [PATCH 4/5] kvm: qemu: Use vringfd to eliminate copies Date: Wed, 18 Jun 2008 15:43:42 +1000 Message-ID: <200806181543.42520.rusty@rustcorp.com.au> References: <1213365481-23460-1-git-send-email-markmc@redhat.com> <200806161210.57926.rusty@rustcorp.com.au> <4856728F.4020501@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Mark McLoughlin , Avi Kivity , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from ozlabs.org ([203.10.76.45]:34605 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbYFRFn7 (ORCPT ); Wed, 18 Jun 2008 01:43:59 -0400 In-Reply-To: <4856728F.4020501@us.ibm.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Tuesday 17 June 2008 00:02:55 Anthony Liguori wrote: > 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 :-) They didn't actually work. You need to block until the data isn't being used any more (thread pool anyone?), or implement an aio interface. > 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. If the guest wants notification of xmit, yes you need another syscall for that. But it often doesn't (note: current vring tun ignored the NO_NOTIFY flag, but one thing at a time). > 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. Note that we can do TSO in userspace, too. No syscall reduction, but an VM exit reduction. Cheers, Rusty.