From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L6ur2-0000Wa-Ne
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:28 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L6ur1-0000WB-3N
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:28 -0500
Received: from [199.232.76.173] (port=57657 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L6ur0-0000W8-U4
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:26 -0500
Received: from rn-out-0910.google.com ([64.233.170.185]:2167)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1L6ur0-0003A9-KS
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:26 -0500
Received: by rn-out-0910.google.com with SMTP id 56so547490rnw.8
	for <qemu-devel@nongnu.org>; Sun, 30 Nov 2008 14:33:26 -0800 (PST)
Message-ID: <493314B2.1080508@codemonkey.ws>
Date: Sun, 30 Nov 2008 16:33:22 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC 1/2] pci-dma-api-v1
References: <20081127123538.GC10348@random.random>
	<f43fc5580811271114u7ecc3277kc7518fb7dbf9b4c0@mail.gmail.com>
In-Reply-To: <f43fc5580811271114u7ecc3277kc7518fb7dbf9b4c0@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Blue Swirl wrote:
> On 11/27/08, Andrea Arcangeli <aarcange@redhat.com> wrote:
>   
>> Hello everyone,
>>
>>  Once we finish fixing storage performance with a real
>>  bdrv_aio_readv/writev (now a blocker issue), a pci_dma_single can be
>>  added for zero copy networking (one NIC per VM, or VMDq, IOV
>>  etc..). The DMA API should allow for that too.
>>     
>
> The previous similar attempt by Anthony for generic DMA using vectored
> IO was abandoned because the malloc/free overhead was more than the
> performance gain. Have you made any performance measurements? How does
> this version compare to the previous ones?
>   

No, I never measured any malloc/free overhead.  I think people are more 
concerned with that than warranted.  A good malloc implementation will 
usually have O(1) complexity for similar sized allocs so malloc/free 
should not be the bottleneck.

My attempt was abandoned because the API is complex and at the time, 
zero copy wasn't the bottle neck we needed to overcome.  Fortunately, 
enough has progressed since then that it is now the bottle neck :-).

Regards,

Anthony Liguori

> I think the pci_ prefix can be removed, there is little PCI specific.
>
> For Sparc32 IOMMU (and probably other IOMMUS), it should be possible
> to register a function used in place of  cpu_physical_memory_rw,
> c_p_m_can_dma etc. The goal is that it should be possible to stack the
> DMA resolvers (think of devices behind a number of buses).
>
>
>