From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWE11-000167-87 for qemu-devel@nongnu.org; Sun, 08 Feb 2009 13:04:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWE10-00015a-AW for qemu-devel@nongnu.org; Sun, 08 Feb 2009 13:04:22 -0500 Received: from [199.232.76.173] (port=32851 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWE10-00015O-4q for qemu-devel@nongnu.org; Sun, 08 Feb 2009 13:04:22 -0500 Received: from mx2.redhat.com ([66.187.237.31]:40652) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LWE0z-0000KO-Dk for qemu-devel@nongnu.org; Sun, 08 Feb 2009 13:04:21 -0500 Message-ID: <498F1EA1.8060803@redhat.com> Date: Sun, 08 Feb 2009 20:04:17 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1233826439-16856-1-git-send-email-avi@redhat.com> <498B5962.2010202@us.ibm.com> <498BFA4D.6010107@redhat.com> <498C5377.1000202@us.ibm.com> <498DFA41.3010202@redhat.com> <498E1E45.3000307@us.ibm.com> <498EA648.4030502@redhat.com> <498F1D6E.3070106@us.ibm.com> In-Reply-To: <498F1D6E.3070106@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/4] Block DMA helpers (v2) Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Anthony Liguori wrote: >> The qemu host interface is at the ring element level, leaving the >> task of gathering ring elements to make a request (and gathering >> segments to make a scatter/gather list) to users. > > I don't think that's totally accurate. Where the host and guest > interface differ is that instead of having the symmetric version of > this, namely: > > vdev->buf_added(vq, sg, out_num, in_num, data); > > Which then would require some sort of: > > put_buf(vq, data, len) > > We have a virtqueue_pop(elem) where elem contains all of the > information passed to add_buf. We have a virtqueue_push() function > that's analogous to the above put_buf() and then we have a separate > virtio_notify() function which would be the symmetric form of kick(). > The names are different but the basic functions are the same. > > Other than the difference of having split sg lists and using a > structure, I don't see how they are different. > You're right - I didn't dig deep enough. We could replace struct iovec in_sg[VIRTQUEUE_MAX_SIZE]; struct iovec out_sg[VIRTQUEUE_MAX_SIZE]; by QEMUSGList, which would be a minor improvement, but I thought things were very different for some reason. >> >> I think we should make the qemu virtio host interface talk at the >> request level, rather than the ring entry level. If we do that, >> we'll get a cleaner, easier to use interface. > > Can you give an example? I'm having a hard time seeing what you mean. An example would be how the code is structured now (as opposed to how I thought it was structured). -- error compiling committee.c: too many arguments to function