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

[Alex Bligh <alex@...872...>]

On 29 Mar 2016, at 23:45, Wouter Verhelst <w@...112...> wrote:

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

OK, I *think* I've encapsulated all 3 options in the revised version I
just sent.

>From the other email:

>> As a third option then:
>> 
>> Each chunk consists of the following:
>> 
>> S: 32 bits, 0x668e33ef, magic (NBD_STRUCTURED_REPLY_MAGIC)
>> S: 8 bits: type
>> S: 8 bits: reserved (must be zero)
>> S: 16 bits, flags
>> S: 64 bits, handle
>> S: 32 bits, payload length S: (length bytes of payload data)
>> 
>> The flags have the following meanings:
>> 
>> • bits 0-15: reserved (server MUST set these to zero)
> 
> That seems better in that context, yes. The reserved byte could later on
> be assigned as extra flags if need be.

Or for compatibility with NBD_CMD, it could be 2 16 bit quantities. Missed
this on v2.

> The reason why I suggested zero is that it doesn't require special-case
> code. If an error offset implies that everything beyond that offset is
> invalid, then having an offset of zero implies that the whole read is
> invalid -- which is correct if the server encountered an error, but
> doesn't know or doesn't want to say (for whatever reason) where.

I think that's wrong. As reads can be disordered, then if you get
a chunk at offset X, then a chunk at offset 0, then an end chunk
specifying an error, you (at least in theory) need to disambiguate
the two so you know whether the chunk at offset X was OK. That's
why I'm using 0xffffffff (now) to say "don't know where the error
is".

-- 
Alex Bligh