Re: [Qemu-devel] [5323] Implement an fd pool to get real AIO with posix-aio

[Anthony Liguori <anthony@codemonkey.ws>]

Gerd Hoffmann wrote:
> Anthony Liguori wrote:
>   
>> Gerd Hoffmann wrote:
>>     
>>> Anthony Liguori wrote:
>>>  
>>>       
>>>>> Are there plans to support vectored block requests with the thread pool
>>>>> implementation?
>>>>>         
>>>>>           
>>>> Yes, that's the primary reason for doing a new thread pool
>>>> implementation.
>>>>     
>>>>         
>>> Cool.
>>>
>>>  
>>>       
>>>> Of course, we need a zero-copy DMA API before such a
>>>> thing would make sense.
>>>>     
>>>>         
>>> Hmm, quick check of the IDE code indeed shows a copy happening there.
>>> Why is it needed?  My xen disk backend doesn't copy data.  Does that
>>> mean might have done something wrong?  Does the virtio backend copy data
>>> too?
>>>       
>> It does now, because the cost of splitting up the AIO request for each
>> element of the scatter/gather list was considerably higher than the cost
>> of copying the data to a linear buffer.
>>     
>
> Ok, so virtio will likely stop doing that soon I guess?  With the aio
> thread pool and even more with a vectored aio api the need for that
> should go away ...
>   

Right now, it's not a super high priority for us since we're getting 
good performance without it.  More important is to improve emulated SCSI 
performance, get a proper zero copy API in, get virtio merged upstream, 
and then start tackling this stuff.

>> You can only avoid doing a copy if you do something like phys_ram_base +
>> PA.
>>     
>
> I actually do this ...
>
> void *xenner_mfn_to_ptr(xen_pfn_t pfn)
> {
>     ram_addr_t offset;
>
>     offset = cpu_get_physical_page_desc(pfn << PAGE_SHIFT);
>     return (void*)phys_ram_base + offset;
> }
>
> ... which should keep working even in case there are holes in the guest
> PA address space and thus guest_pa != phys_ram_base offset.
>   

Yes, this is what we do in virtio too ATM.

>> From an architectural perspective, this is not ideal since it
>> doesn't allow for things like IOMMU emulation.  What we need, is a
>> zero-copy API at the PCI level.
>>     
>
> Sure, for IDE+SCSI emulation.  For paravirtual drivers it shouldn't be
> an issue.
>   

For Xen, I can maybe see the argument that it shouldn't go through a DMA 
API since it's completely divorced of how normal hardware works.  Since 
virtio drivers are really just a PCI device, I don't think that argument 
applies.

There are good reasons to put in the effort to get a proper DMA API to 
improve SCSI and the e1000's performance.

Regards,

Anthony Liguori

> cheers,
>   Gerd
>
>
>
>
>