Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

On 03/29/2016 08:37 AM, Alex Bligh wrote:
> Eric,
> 
>> I guess what I need to add is that in transmission phase, most commands
>> have exactly one response per request; but commands may document
>> scenarios where there will be multiple responses to a single request.
>> NBD_CMD_READ uses the multiple responses to make partial read and error
>> handling possible
> 
> Yes, this.
> 

>> Are you arguing that there should be a flag that controls whether reads
>> must be in-order vs. reassembled?  Reassembly must happen either way,
>> the question is whether having a way to allow out-of-order for
>> efficiency, vs. defaulting to in-order for easier computation, is worth it.
> 
> No, that sounds overengineered.
> 
> More a way of guaranteeing avoiding a fragmentation on 'simple' reads.
> Perhaps a 'DF' bit (don't fragment)! If the server doesn't like it, it
> can always error the command.

Okay, that makes sense.  Does reusing NBD_CMD_FLAG_FUA sound reasonable
for this purpose, or should it be a new flag?  I guess from the
standpoint of client/server negotiation, we want to support this
don't-fragment request even if NBD_FLAG_SEND_FUA was not listed in
export flags, so it sounds like a new flag is best.  Next, should it be
independently negotiated, or implied by negotiating
NBD_FLAG_C_STRUCTURED_REPLIES?  I'm leaning towards implied - it's
all-or-none for use of the improved read structures.  I'm also leaning
towards the name NBD_FLAG_C_STRUCTURED_READ, since elsewhere I'm
documenting that negotiating this particular global flag affects only
the replies to NBD_CMD_READ (other commands may use structured replies,
but those commands will be independently negotiated).


>>
>> Sure.  But keep in mind that if (when?) we add a flag for allowing the
>> server to skip read chunks on holes, we'll have to tweak the wording to
>> allow the server to send fewer chunks than the client's length, where
>> the client must then assume zeroes for all chunks not received.
> 
> Or alternatively a chunk representing a hole. I wonder whether you
> might be better to extend the chunk structure by 4 bytes to allow for
> future modifications like this (e.g. NBD_CHUNK_FLAG_HOLE means
> the chunk is full of zeroes and has no payload).

Seems reasonable (then I need to reword everything from len-8 to instead
be len-12 when dealing with data size within the len bytes of payload).
 Network traffic-wise, I think it's better to always send the chunk
flags, than it would be to try and make the sending of the chunk flags
dependent on the client's choice of command flags (that is, we already
argued that wire format should never be changed based merely on command
flags, as it makes the server stream harder to decipher in isolation).

Thanks for the good feedback, by the way; it will make v2 better.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]