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

[Wouter Verhelst <w@uter.be>]

On Tue, Mar 29, 2016 at 11:05:38PM +0100, Alex Bligh wrote:
> 
> On 29 Mar 2016, at 22:05, Wouter Verhelst <w@uter.be> 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,

Yes, but both code paths need to _exist_, which isn't the case with
having only one legal reply type per request type. The server just needs
to send header X for replies A, B, C, and header Y for replies D, E, F.
Forming the header is part of producing the reply type, and will be the
same for every conversation -- except for read replies, where it could
possibly be either (but that can't be avoided).

> and that having multiple types of reply depending on command builds
> fragility into the protocol.

I'd think that having the legal reply type depend on context is actually
more fragile.

> 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.

Doing that requires performing a lookup to negotiated state (and a code
branch) for every response type that can possibly be structured or
nonstructured, and introduces exactly the two code paths that I think
should be avoided.

With what I'm suggesting, this will still be required for read requests,
but only while we retain backwards compatibility.

> 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.

Sure, but I'm not worried about that.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12