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

[Anthony Liguori]

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
>
>
>
>
>