From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure Date: Tue, 05 Jun 2007 12:27:08 +1000 Message-ID: <1181010428.25878.137.camel@localhost.localdomain> References: <1180613947.11133.58.camel@localhost.localdomain> <08CA2245AFCF444DB3AC415E47CC40AFBD2CCF@G3W0072.americas.hpqcorp.net> <1180779167.9228.66.camel@localhost.localdomain> <08CA2245AFCF444DB3AC415E47CC40AFBD2FD4@G3W0072.americas.hpqcorp.net> <466481ED.8050209@goop.org> <08CA2245AFCF444DB3AC415E47CC40AFBD30B4@G3W0072.americas.hpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jimi Xenidis , Stephen Rothwell , Jeremy Fitzhardinge , Xen Mailing List , jmk-zzFmDc4TPjtKvsKVC3L/VUEOCMrvLtNR@public.gmane.org, Herbert Xu , kvm-devel , virtualization , Christian Borntraeger , Suzanne McIntosh , Martin Schwidefsky To: "Santos, Jose Renato G" Return-path: In-Reply-To: <08CA2245AFCF444DB3AC415E47CC40AFBD30B4-VylnnfFjWmASZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Tue, 2007-06-05 at 02:05 +0000, Santos, Jose Renato G wrote: > > From: Jeremy Fitzhardinge [mailto:jeremy-TSDbQ3PG+2Y@public.gmane.org] > > The hope is that the Xen-specific elements of the driver will > > be restricted to Xen-specific things like grant tables, and > > the bulk of the driver and its logic can be common. Whether > > that can be achieved and still retain the full > > performance/features of the entirely Xen-specific netfront > > driver remains to be seen. I haven't had a chance to look at > > doing any Xen-virtio glue yet, so I'm not really sure how it > > will work out. > > > > J > > > > Ok, if you share some common code this could be beneficial, but > in the specific case of Xen networking I believe most of netfront > code is Xen specific. I think that a generic "virtual-IO" layer > would not be beneficial in this case, but instead it would > only add extra complexity to glue the layers. This is precisely the plan: to code it up and look hard at it. If performance gets hurt, it's a lose. If performance is equal and the code is clearer, it's a win, and this is my goal. Perhaps you underestimate how much of the Xen netfront driver is actually dealing with things which *any* efficient virtio I/O netdriver will have to wrestle with. Thanks! Rusty. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/