Re: [Qemu-devel] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on server

[Eric Blake]

On 02/23/2017 07:13 AM, Paolo Bonzini wrote:
> 
> 
> On 22/02/2017 21:34, Eric Blake wrote:
>>
>>> Oh, so it's the smallest "good" transfer size, or the preferred
>>> alignment.  That's not the same as the SCSI definition, which is:
>>>
>>>    If a device server receives one of these commands with a transfer
>>>    size greater than this value, then the device server may incur
>>>    delays in processing the command. An OPTIMAL TRANSFER LENGTH field
>>>    set to 0000_0000h indicates that the device server does not report
>>>    an optimal transfer size.
>> Hmm - that's yet another limit. I don't know if our block layer exposes
>> it, or if it should expose it.
> 
> It exposes it in opt_transfer. :)  The only driver that sets
> opt_transfer is the iSCSI driver and uses the SCSI meaning.

>> Does that mean our BlockLimits structure documentation needs a tweak,
>> too?  It currently reads:
>>
>>     /* Optimal transfer length in bytes.  A power of 2 is best but not
>>      * mandatory.  Must be a multiple of bl.request_alignment, or 0 if
>>      * no preferred size */
>>     uint32_t opt_transfer;
>>
>> Are we trying to track both optimum size in the SCSI sense _and_ block
>> size in the O_DIRECT sense?
> 
> As of now, just in the SCSI sense.

Okay, sounds like I need a pre-requisite patch to beef up the
BlockLimits documentation, and maybe adding in a preferred size for yet
another parameter that we learn from stat() on files (there really are
performance benefits for performing I/O on a file in aligned requests,
even if it can do byte-wise manipulations).  And maybe the NBD
documentation needs a tweak too - which values are the most beneficial
to expose over the wire?  Should NBD be exposing more than just
min/preferred/max?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature