WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure

To: "Rusty Russell" <rusty@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
From: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>
Date: Tue, 5 Jun 2007 02:49:45 -0000
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, jmk@xxxxxxxxxxxxxxxxxxx, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
Delivery-date: Mon, 04 Jun 2007 19:48:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1181010428.25878.137.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1180613947.11133.58.camel@xxxxxxxxxxxxxxxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AFBD2CCF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1180779167.9228.66.camel@xxxxxxxxxxxxxxxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AFBD2FD4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <466481ED.8050209@xxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AFBD30B4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1181010428.25878.137.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcenGRQT+VY/0pW5RxCDsYK2SaPqQQAAcufQ
Thread-topic: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
 

> -----Original Message-----
> From: Rusty Russell [mailto:rusty@xxxxxxxxxxxxxxx] 
> Sent: Monday, June 04, 2007 7:27 PM
> To: Santos, Jose Renato G
> Cc: Jeremy Fitzhardinge; Jimi Xenidis; Stephen Rothwell; Xen 
> Mailing List; jmk@xxxxxxxxxxxxxxxxxxx; Herbert Xu; kvm-devel; 
> virtualization; Christian Borntraeger; Suzanne McIntosh; 
> Anthony Liguori; Martin Schwidefsky
> Subject: RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
> 
> On Tue, 2007-06-05 at 02:05 +0000, Santos, Jose Renato G wrote:
> 
> > > From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx] 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.
> 
  I was not really thinking about performance. I was questioning
  how much code could realy be shared? I expected that just a small
  fraction of the code could be shared. So even if performance does
  not suffer, it would not be providing any benefit, or worse, it
  could make the code more complex due to interaction with an 
  additional layer

> 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.
> 
  Perhaps, you are right.
  I think we will know when you code it up.
  
  Regards

  Renato
  
  
> Thanks!
> Rusty.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel