Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS

[Avi Kivity <avi@redhat.com>]

Samuel Thibault wrote:
> Ah, I thought you understood that the posix driver has the same kind of
> limitation 

It's not the same limitation.  The posix driver has no limits on DMA 
size, it will happily transfer a gigabyte of data if you ask it to.


> (and qemu is actually _bugged_ in that regard).
>   

It has a bug in that it does not correctly interpret the return value of 
pread()/pwrite().  It's a minor bug since no system supported by qemu 
will actually return a short read or write (I think) and in that  we 
hope disk errors are rare.  Nevertheless it should be fixed (it's an 
easy fix too).  However implementing DMA limits like you propose 
(IDE_DMA_BUF_SECTORS) will not fix the bug, only reduce performance.

>   
>>> I'm here just pointing out that the problem is not
>>> _only_ in the xen-specific driver, but also in the posix driver, on any
>>> OS that doesn't necessarily do all the work the caller asked for (which
>>> is _allowed_ by POSIX).
>>>  
>>>       
>> But that's not limited DMA (or at least, not limited up-front).  And 
>> it's easily corrected, place a while loop around preadv/pwritev, no need 
>> to split a request a priori somewhere up the stack.
>>     
>
> Sure, and I could do the same in the block-vbd driver, thus then my
> original remark "it should be centralized in the block layer instead of
> placing the burden on all block format drivers".  Just to make sure: I'm
> _not_ saying that should be done in the DMA code.  I said it should be
> done in the block layer, shared by all block drivers.
>   

A generic fix will have to issue a new aio request.  block-raw-posix 
need not do that, just a while loop.


>> And it wouldn't be right for block-vbd - you should split your requests 
>> as late as possible, IMO.
>>     
>
> Why making it "late"?  Exposing the lower limits to let upper layers
> decide how they should manage fragmentation usually gets better
> performance.  (Note that in my case there is no system involved, so it's
> really _not_ costly to do the fragmentation on the qemu side).
>   

If ring entries can be more than a page (if the request is contiguous), 
then the limit can be expanded.  In other words, it's a worst-case 
limit, not a hard limit.  Exposing the worst case limit will lead to 
pessimistic choices.

That's how virtio-blk works, don't know about xen vbd (might not work 
due to the need to transfer grants?)

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.