From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [PATCH 0/3] vhost cleanups and separate module Date: Tue, 07 May 2013 14:13:44 +0930 Message-ID: <87zjw7o0vz.fsf@rustcorp.com.au> References: <1367559269-8325-1-git-send-email-asias@redhat.com> <87sj20prhj.fsf@rustcorp.com.au> <20130506091911.GB10601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: target-devel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org To: "Michael S. Tsirkin" Return-path: In-Reply-To: <20130506091911.GB10601@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: kvm.vger.kernel.org "Michael S. Tsirkin" writes: > On Mon, May 06, 2013 at 03:41:36PM +0930, Rusty Russell wrote: >> Asias He writes: >> > Asias He (3): >> > vhost: Remove vhost_enable_zcopy in vhost.h >> > vhost: Move VHOST_NET_FEATURES to net.c >> > vhost: Make vhost a separate module >> >> I like these cleanups, MST pleasee apply. > > Absolutely. Except it's 3.11 material and I can only > usefully create a -next branch once -rc1 is out. > >> I have some other cleanups which are on hold for the moment pending >> MST's vhost_net simplification. MST, how's that going? > > Not too well. The array of status bytes which was designed to complete > packets in order turns out to be a very efficient datastructure: > > It gives us a way to signal completions that is completely lockless for > multiple completers, and using the producer/consumer model saves extra > scans for the common case. > > Overall I can save some memory and clean up some code but can't get rid > of the producer/consumer idices (currently named upend/done indices) > which is what you asked me to do. > Your cleanups basically don't work with zcopy because they > ignore the upend/done indices? > Would you like to post them, noting they only work with zcopy off, and > we'll look for a way to apply them, together? Not quite; it's just that I don't understand that code. It seemed to be achieving something (ordered completion) which was entirely unnecessary, so I went on with other things while you removed it. Now that's not possible, I'll revisit. AFAICT we should always do zero copy. Though I do wonder if we should use a dedicated hook to get an skb into the tun driver and generate it ourselves, rather than going sg -> iov -> skb. Cheers, Rusty.