From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: vhost net: performance with ping benchmark Date: Tue, 25 Aug 2009 09:46:04 +0300 Message-ID: <20090825064604.GB10429@redhat.com> References: <20090824081240.GA3415@redhat.com> <20090824212137.GA9835@redhat.com> <4A934AF7.2090904@codemonkey.ws> <4A936525.5030300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, Rusty Russell , Mark McLoughlin To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58794 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754561AbZHYGrh (ORCPT ); Tue, 25 Aug 2009 02:47:37 -0400 Content-Disposition: inline In-Reply-To: <4A936525.5030300@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Aug 25, 2009 at 07:14:29AM +0300, Avi Kivity wrote: > On 08/25/2009 05:22 AM, Anthony Liguori wrote: >> >> I think 2.6.32 is pushing it. > > 2.6.32 is pushing it, but we need to push it. > >> I think some time is needed to flush out the userspace interface. In >> particular, I don't think Mark's comments have been adequately >> addressed. If a version were merged without GSO support, some >> mechanism to do feature detection would be needed in the userspace API. >> > > I don't see any point in merging without gso (unless it beats userspace > with gso, which I don't think will happen). In any case we'll need > feature negotiation. > >> I think this is likely going to be needed regardless. I also think >> the tap compatibility suggestion would simplify the consumption of >> this in userspace. > > What about veth pairs? > >> I'd like some time to look at get_state/set_state ioctl()s along with >> dirty tracking support. It's a much better model for live migration >> IMHO. > > My preference is ring proxying. Not we'll need ring proxying (or at > least event proxying) for non-MSI guests. Exactly, that's what I meant earlier. That's enough, isn't it, Anthony? >> I think so more thorough benchmarking would be good too. In >> particular, netperf/iperf runs would be nice. > > Definitely. > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain.