xen-devel
RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
To: |
"Santos, Jose Renato G" <joserenato.santos@xxxxxx> |
Subject: |
RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure |
From: |
Rusty Russell <rusty@xxxxxxxxxxxxxxx> |
Date: |
Tue, 05 Jun 2007 12:27:08 +1000 |
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:25:36 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<08CA2245AFCF444DB3AC415E47CC40AFBD30B4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
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> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
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.
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|