On Tue, 2007-06-05 at 02:05 +0000, Santos, Jose Renato G wrote: > > From: Jeremy Fitzhardinge [mailto:[EMAIL PROTECTED] > > 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
