From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JmaMw-00029H-3C for qemu-devel@nongnu.org; Thu, 17 Apr 2008 16:06:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JmaMu-00026x-7s for qemu-devel@nongnu.org; Thu, 17 Apr 2008 16:06:05 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JmaMu-00026n-4T for qemu-devel@nongnu.org; Thu, 17 Apr 2008 16:06:04 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JmaMt-0002FE-S6 for qemu-devel@nongnu.org; Thu, 17 Apr 2008 16:06:03 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3HK61XC028432 for ; Thu, 17 Apr 2008 16:06:01 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3HK61is184704 for ; Thu, 17 Apr 2008 16:06:01 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3HK60ug030131 for ; Thu, 17 Apr 2008 16:06:01 -0400 Message-ID: <4807ADA7.7000500@us.ibm.com> Date: Thu, 17 Apr 2008 15:05:59 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/5] PCI DMA API (v3) References: <1208297491-1287-1-git-send-email-aliguori@us.ibm.com> <4806596C.4090107@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kvm-devel@lists.sourceforge.net, Marcelo Tosatti , qemu-devel@nongnu.org, Aurelien Jarno , Paul Brook Blue Swirl wrote: > > I fixed the bug, now pcnet works. Performance is improved by a few > percent. The problem was that the vector was not freed. Maybe dynamic > allocation is a bit fragile. In this case, the length of the vector is > known, so it could be allocated once at init time. But would this > work? > For you, yes, but not for me. virtio scatter/gather lists can be very long. The API tries not to make assumptions about who's allocating what so you should be able to get away without a dynamic allocation if you were sufficiently motivated. > The next step would be to add a vector version for packet receive. For > ESP/SCSI, in addition to bdrv_readv/writev, AIO versions would need to > be added. Last year I made a patch (attached) that made SLIRP use my > version of IOVector, I could update it to this model. > Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. Regards, Anthony Liguori >>> IMHO the read/write functions should be a property of the bus so that >>> they are hidden from the device, for pcnet it does not matter as we >>> have to do the swapping anyway. >>> >>> >>> >> For an IOMMU that has a per-device mapping, the read/write functions have >> to operate on a per-device basis. >> > > No, I meant that there could be a bus layer that did the memory access > and provided a specialized version of iovector_new without the > handlers. But I think we can live with this, if things get too ugly we > can add the layering later. >