[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on se

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on server
Date: Thu, 23 Feb 2017 09:38:56 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]