[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] nbd/proto: introduce structured request

From: Eric Blake
Subject: Re: [PATCH 1/2] nbd/proto: introduce structured request
Date: Thu, 6 Feb 2020 07:05:59 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/5/20 10:43 AM, Vladimir Sementsov-Ogievskiy wrote:
Idea: reuse structured replies as requests too. For this:

Rename structured reply "structure" to structured message. And,
correspondingly structured reply chunk to structured message chunk.

Keep name "structured reply" for structured messages sent by server,
and name "structured request" a structured message sent by client.

Share almost all semantics around structured messages for client and
server except for chunk type (as reply types and request types are
orthogonal things). Still, share none-type chunk for both server and

Without looking at the doc patch itself, my initial worry is as follows:

For structured replies, we needed the ability to allow a server to have split replies (sparse reads were the primary reason behind that decision - the client does not know a priori which portions of the image are sparse, and the server needs some way to represent both data and holes each as efficiently as possible over the wire for a single read request). On the client side, this means that either the client has to track enough state to reassemble multiple server messages intermixed with one another, or the client can choose to serialize things so that the server only ever has at most one outstanding command. On the server side, some servers may already be smart enough to handle interleaved client requests such that structured replies can indeed end up interleaved, while others may serialize how they react to incoming client messages and send all chunks of a given reply (in the few cases where sending more than one chunk even makes sense) before parsing the next client message. Thus, while the protocol permits interleaving, it does not force either side to implement interleaving.

But if we allow structured requests to be split across multiple packets, we either have to mandate that clients CANNOT split requests across multiple packets, or we are FORCING the server to track additional state to deal with clients that fragment and interleave requests, even if most clients don't do that. While split replies make sense, I'm having a hard time seeing how split requests would ever be useful (a client does not need to try to do a write with holes in a single request; instead, write the data and write the holes via two separate write requests over smaller portions of the export). So while we may want to reuse the magic number and on-the-wire format of a structured message, I'd strongly argue that structured requests must be documented in a way that makes it obvious that they will always occupy exactly one chunk (reserving multiple chunks and the need for the DONE flag only for replies).

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]