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

[Alex Bligh]

Eric,

> I'm liking it - then we aren't sending a mandatory 0 error field on read
> chunks.

Straw man patch sent through. Alternatively at:

https://github.com/abligh/nbd/commit/3c40272704904ac74040ceb099fee0b44e355e1e

and in markdown format at:

https://github.com/abligh/nbd/blob/strawman-structured-reply/doc/proto.md

Very much off the top of my head.

>  Although I might use '32 bit Type' rather than '32 bit Flags',
> since you don't really want to allow multiple reply types at once;
> rather each reply type id is documented on its specific payload layout.

I used the bottom byte of the flags for this, so we can keep the flags.

>> 4. It would be possible to allow EVERY server reply to be a structured
>>   reply that simply set NBD_CHUNK_IS_END. That gives us a convenient
>>   route to servers which only implement structured replies. With DF,
>>   this would be little harder than implementing the current
>>   protocol.
> 
> For all remaining existing commands, that is just more overhead on the
> wire.  The existing non-structured replies do not send any data; they
> are 16 bytes each (only NBD_CMD_READ sends more than 16 bytes in one
> reply).  But your proposal inflates that to a minimum of 20 bytes (if
> length is 0) or longer (if an error is set).  I'm still strongly in
> favor of keeping the existing non-structured replies to commands that
> don't have to return data.

I was saying that should be up to the server. If the server wants to
write something easily decodable (and easier to maintain) at the expense
of a few more bytes on the wire, then let it. If it wants to use
unstructured replies occasionally, that's fine.

> I'm okay if a new command sometimes returns data and sometimes does not;
> in which case, that command can always return a single structured reply
> where the id of the reply says whether the payload will be length 0 or
> not, but only new commands should get that treatment.

I think we are at cross purposes. I am saying that if you've negotiated
structured replies, you should be be able to return either for any
command, as the client can disambiguate using the magic number.

Clearly some future commands might REQUIRE structured replies as there
would be no way to represent them in an unstructured reply.

--
Alex Bligh

signature.asc
Description: Message signed with OpenPGP using GPGMail