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