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

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

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [kvm-devel] [PATCH RFC 1/3] virtio infrastructure
From: Avi Kivity <avi@xxxxxxxxxxxx>
Date: Mon, 04 Jun 2007 14:25:32 +0300
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "jmk@xxxxxxxxxxxxxxxxxxx" <jmk@xxxxxxxxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
Delivery-date: Mon, 04 Jun 2007 04:23:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1180955964.25878.27.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> <46610E8D.10706@xxxxxxxxxxxx> <1180777836.9228.44.camel@xxxxxxxxxxxxxxxxxxxxx> <46625192.5020108@xxxxxxxxxxxx> <1180866540.17442.74.camel@xxxxxxxxxxxxxxxxxxxxx> <4662A86A.7010706@xxxxxxxxxxxx> <1180914836.17442.104.camel@xxxxxxxxxxxxxxxxxxxxx> <4663E18D.4030007@xxxxxxxxxxxx> <1180955964.25878.27.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.0 (X11/20070419)
Rusty Russell wrote:
Networking hardware generally services descriptors in a FIFO manner.

Well, ethernet guarantees order.  Not sure about others tho...


OT: Does that hold for bonded interfaces too?

virtio may not (for example, it may offload copies of larger packets to a dma engine such as I/OAT, resulting in a delay, but copy smaller packets immediately). that means that there will be some mismatch between virtio drivers and real hardware drivers.

I think your point is that the completion bitmap (or indeed, the current
approach) does not maintain order?  Hmm, this is more convincing to me
than cache arguments, since some devices might want ordering and want
more than a single io in flight.

Well, it wasn't really; sorry for being unclear. My point was that virtio interfaces will not match hardware exactly.

My objection is to "scan all slots, occupied or not, for completion". I think virtio should present completed descriptors without the need for scanning, even if it means looking a bit different from a typical ethernet driver.


--
error compiling committee.c: too many arguments to function


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