From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akzp3-0005dw-F1 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 16:01:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akzoz-0003XE-0Y for qemu-devel@nongnu.org; Tue, 29 Mar 2016 16:01:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akzoy-0003Wo-PR for qemu-devel@nongnu.org; Tue, 29 Mar 2016 16:01:00 -0400 References: <1459173555-4890-1-git-send-email-eblake@redhat.com> <1459223796-28474-2-git-send-email-eblake@redhat.com> <20160329175319.GA8628@grep.be> <56FAC823.8070206@redhat.com> <20160329185157.GC12469@grep.be> From: Eric Blake Message-ID: <56FADEFA.8070207@redhat.com> Date: Tue, 29 Mar 2016 14:00:58 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MiN4J0rdNru92x8eGWnL0gqbul8S43hr6" Subject: Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh , Wouter Verhelst Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MiN4J0rdNru92x8eGWnL0gqbul8S43hr6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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_RESPONSE (unlike in NBD_CMD_READ in > other situations). >=20 > I think we should therefore look at this the other way around. Here's > a straw man proposal as an alternative for the reply bits. For > a structured reply ALL we get is the chunks. The final chunk > (possibly the only chunk) is marked specially. Each chunk looks somethi= ng > like: >=20 > offset+ > 0000 32 bit NBD_STRUCTURED_REPLY_MAGIC > 0004 64 bit handle > 000C 32 bit Flags > 0010 32 bit Payload length >=20 >=20 > We have a couple of flags defined: >=20 > NBD_CHUNK_IS_DATA: the chunk is data, and the payload is a 64 bit offse= t > plus the data read >=20 > NBD_CHUNK_IS_HOLE: the chunk is zeroes, and the payload is a 64 bit off= set > (only) >=20 > NBD_CHUNK_IS_END: (must be the final chunk). The payload is a 64 bit of= fset > plus a 32 bit error code, or zero. If no error, the offset must be set = to > the total amount read. If there is an error, the offset MAY indicate th= e > position of the error. If an error occurs, no more chunks should be sen= t. I'm liking it - then we aren't sending a mandatory 0 error field on read chunks. Although I might use '32 bit Type' rather than '32 bit Flags', since you don't really want to allow multiple reply types at once; rather each reply type id is documented on its specific payload layout. Another argument in favor of this over my original proposal: my proposal is context-free for determining reply boundaries, but still requires context in deciphering between a reply to NBD_CMD_READ vs. a reply to NBD_CMD_GET_LBA_STATUS (that is, there was nothing in the reply that said what the payload represents, only how many bytes to skip). However, with a '32 bit Type', the wireshark detector can be taught every type of payload, and as long as every command with a structured reply uses 1 or more distinct types, the dissector can display more details about the payload when it recognizes the type, and still skip the payload on extensions it does not recognize. >=20 > 4. It would be possible to allow EVERY server reply to be a structured > reply that simply set NBD_CHUNK_IS_END. That gives us a convenient > route to servers which only implement structured replies. With DF, > this would be little harder than implementing the current > protocol. 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'm okay if a new command sometimes returns data and sometimes does not; in which case, that command can always return a single structured reply where the id of the reply says whether the payload will be length 0 or not, but only new commands should get that treatment. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --MiN4J0rdNru92x8eGWnL0gqbul8S43hr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW+t76AAoJEKeha0olJ0NqnMwH+wcJpY+S1Xicx4as1JE+YDTx PwjOar39Xoa+ZA6+3qOjyOno8ghCDUWkEmeU8fEvtrDuoeL5TB7vlME6OwZ7fceO 0h4V7R0dGnorE496kRTH5xTB6TIyEAwzO9tyQjmVJbVzh/yLWXHoXzZNn6iUK47/ lsY6pvXMbEQScL9lOa6xdQNfbS0w5kXr+aKgi16L1qMDojGea/aIU1bYwCqaHy+q X+NlNICHu7aSPJN+F+JuxjyPOomdGHf/k8dsnAQoCwUhslV6UX2VCvoka7SzRCwb aSZntfFEmD4mrsuiScFhvxLg2oB4/SEQhAIyzSLYmUBKt8We1ZKpaq4n4ctQZHE= =REYB -----END PGP SIGNATURE----- --MiN4J0rdNru92x8eGWnL0gqbul8S43hr6--