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

[Alex Bligh]

On 29 Mar 2016, at 22:05, Wouter Verhelst <address@hidden> wrote:

>>> 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.
> 
> In adding that flexibility, you're adding more code paths on the client
> (that need to be tested, etc), for (IMO) little benefit.
> 
> I would instead prefer to specify per command whether the reply is going
> to be structured or not, and only have the read command be a special
> case were both are possible, for backwards compatibility only. That way,
> it can eventually be deprecated, too.

I guess this is what comes of doing more NBD server work than client
work :-) I'd look at it the other way around and say that only one
code path is being exercised on the server, and that having multiple
types of reply depending on command builds fragility into the protocol.

If you want no choice in response type for the server for any given
session (i.e. code path minimisation on the client) my preference would
be what Eric didn't like, i.e. always send structured replies for
all commands if you negotiate structured replies, else always send
unstructured replies. We're talking an overhead of 8 bytes here
(flags & error offset); somehow I suspect the time to transmit
8 bytes is going to be negligible compared to disk time or the
rest of the network tx/rx time.

-- 
Alex Bligh