[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
- To: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>
- 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
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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