On 29 Mar 2016, at 23:45, Wouter Verhelst 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 w
On Tue, Mar 29, 2016 at 11:05:38PM +0100, Alex Bligh wrote:
>
> On 29 Mar 2016, at 22:05, Wouter Verhelst 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 (onl
On 29 Mar 2016, at 22:05, Wouter Verhelst 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 pro
Hi Alex,
On Tue, Mar 29, 2016 at 09:44:39PM +0100, Alex Bligh wrote:
> Eric,
> > 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
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-struct
On 29 Mar 2016, at 21:00, Eric Blake wrote:
> I'm liking it - then we aren't sending a mandatory 0 error field on read
> chunks.
I'm writing it up as a strawman. I'll comment in a sec in further detail.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 03/29/2016 01:39 PM, Alex Bligh wrote:
> I think we are paying too much attention to trying to keep NBD_RESPONSE
> intact. The justification for this was (I think) that it made it easier
> for existing protocol analysers. It doesn't, really, as all the data
> is going to come BEFORE the NBD_RESP
On 29 Mar 2016, at 19:51, Wouter Verhelst wrote:
>>
>> But I was envisioning the opposite: the server must NOT send X bytes
>> unless it knows they are valid; if it encounters a read error at Z,
>> then it sends a structured read of Z-1 bytes before the final normal
>> message that reports over
On Tue, Mar 29, 2016 at 08:51:57PM +0200, Wouter Verhelst wrote:
> On Tue, Mar 29, 2016 at 12:23:31PM -0600, Eric Blake wrote:
> > Unfortunately, I chose the design of 0 or more structured replies
> > followed by a normal reply, so that the normal reply is a reliable
> > indicator that the read is
On Tue, Mar 29, 2016 at 12:23:31PM -0600, Eric Blake wrote:
> On 03/29/2016 11:53 AM, Wouter Verhelst wrote:
> > Hi Eric,
> >
> > Having read this in more detail now:
> >
> > On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> >> + The server MUST ensure that each read chunk lies withi
On 03/29/2016 12:19 PM, Wouter Verhelst wrote:
> On Tue, Mar 29, 2016 at 12:07:59PM -0600, Eric Blake wrote:
>> On 03/29/2016 12:03 PM, Wouter Verhelst wrote:
>>> On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
Supporting DF merely transfers the burden of collection between server
On 03/29/2016 11:53 AM, Wouter Verhelst wrote:
> Hi Eric,
>
> Having read this in more detail now:
>
> On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
>> + The server MUST ensure that each read chunk lies within the original
>> + offset and length of the original client request, MUS
On Tue, Mar 29, 2016 at 12:07:59PM -0600, Eric Blake wrote:
> On 03/29/2016 12:03 PM, Wouter Verhelst wrote:
> > On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
> >> Supporting DF merely transfers the burden of collection between server
> >> and client. I suspect that there are cases w
On 29 Mar 2016, at 19:03, Wouter Verhelst wrote:
> There are other ways to handle that; e.g., the server could have a
> "request too large for non-fragmented read" error message. The spec
> should give a minimum size that the server MUST support (which should be
> reasonably large), and should s
On 03/29/2016 12:03 PM, Wouter Verhelst wrote:
> On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
>> On 03/29/2016 11:34 AM, Alex Bligh wrote:
>>> I would agree. I think if it supports the structured reply semantics,
>>> it should also support 'DF'. So if you know the server supports
>>>
On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
> On 03/29/2016 11:34 AM, Alex Bligh wrote:
> > I would agree. I think if it supports the structured reply semantics,
> > it should also support 'DF'. So if you know the server supports
> > structured replies, you know you can set DF on th
Hi Eric,
Having read this in more detail now:
On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> + The server MUST ensure that each read chunk lies within the original
> + offset and length of the original client request, MUST NOT send read
> + chunks that would cover the same offse
On 03/29/2016 11:34 AM, Alex Bligh wrote:
>
> On 29 Mar 2016, at 16:12, Eric Blake wrote:
>>>
>>> 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 ma
On 29 Mar 2016, at 16:12, Eric Blake wrote:
>>
>> 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 re
On Tue, Mar 29, 2016 at 09:12:02AM -0600, Eric Blake wrote:
> 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 b
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 multi
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
> han
On 03/29/2016 02:24 AM, Alex Bligh wrote:
>
> On 29 Mar 2016, at 04:56, Eric Blake wrote:
>
>> The existing transmission phase protocol is difficult to sniff,
>> because correct interpretation of the server stream requires
>> context from the client stream (or risks false positives if
>> data pa
On 29 Mar 2016, at 04:56, Eric Blake wrote:
> The existing transmission phase protocol is difficult to sniff,
> because correct interpretation of the server stream requires
> context from the client stream (or risks false positives if
> data payloads happen to contain the protocol magic numbers)
Hi Eric,
After applying some of the other outstanding patches, this one doesn't apply
anymore. Can you rebase?
On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> The existing transmission phase protocol is difficult to sniff,
> because correct interpretation of the server stream requir
25 matches
Mail list logo
