From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvJR-0007It-8I for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:12:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvJM-00076Y-AN for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:12:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvJL-00076P-SX for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:12:04 -0400 References: <1459173555-4890-1-git-send-email-eblake@redhat.com> <1459223796-28474-2-git-send-email-eblake@redhat.com> <55B49D68-2F63-4742-9B60-F6B428ABB3E9@alex.org.uk> <56FA8F5B.8060800@redhat.com> <88E5F63B-B036-45C7-B2FD-B555D54E88F4@alex.org.uk> From: Eric Blake Message-ID: <56FA9B42.2020503@redhat.com> Date: Tue, 29 Mar 2016 09:12:02 -0600 MIME-Version: 1.0 In-Reply-To: <88E5F63B-B036-45C7-B2FD-B555D54E88F4@alex.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="00f93ITSolJcO3LTGdIGKosOB0daMAJGn" 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 Cc: "nbd-general@lists.sourceforge.net" , Wouter Verhelst , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --00f93ITSolJcO3LTGdIGKosOB0daMAJGn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2016 08:37 AM, Alex Bligh wrote: > Eric, >=20 >> I guess what I need to add is that in transmission phase, most command= s >> 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 erro= r >> handling possible >=20 > Yes, this. >=20 >> Are you arguing that there should be a flag that controls whether read= s >> must be in-order vs. reassembled? Reassembly must happen either way, >> the question is whether having a way to allow out-of-order for >> efficiency, vs. defaulting to in-order for easier computation, is wort= h it. >=20 > No, that sounds overengineered. >=20 > 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 reasonable for this purpose, or should it be a new flag? I guess from the standpoint of client/server negotiation, we want to support this don't-fragment request even if NBD_FLAG_SEND_FUA was not listed in export flags, so it sounds like a new flag is best. Next, should it be independently negotiated, or implied by negotiating NBD_FLAG_C_STRUCTURED_REPLIES? I'm leaning towards implied - it's all-or-none for use of the improved read structures. I'm also leaning towards the name NBD_FLAG_C_STRUCTURED_READ, since elsewhere I'm documenting that negotiating this particular global flag affects only the replies to NBD_CMD_READ (other commands may use structured replies, but those commands will be independently negotiated). >> >> Sure. But keep in mind that if (when?) we add a flag for allowing the= >> server to skip read chunks on holes, we'll have to tweak the wording t= o >> allow the server to send fewer chunks than the client's length, where >> the client must then assume zeroes for all chunks not received. >=20 > Or alternatively a chunk representing a hole. I wonder whether you > might be better to extend the chunk structure by 4 bytes to allow for > future modifications like this (e.g. NBD_CHUNK_FLAG_HOLE means > the chunk is full of zeroes and has no payload). Seems reasonable (then I need to reword everything from len-8 to instead be len-12 when dealing with data size within the len bytes of payload). Network traffic-wise, I think it's better to always send the chunk flags, than it would be to try and make the sending of the chunk flags dependent on the client's choice of command flags (that is, we already argued that wire format should never be changed based merely on command flags, as it makes the server stream harder to decipher in isolation). Thanks for the good feedback, by the way; it will make v2 better. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --00f93ITSolJcO3LTGdIGKosOB0daMAJGn 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+ptCAAoJEKeha0olJ0NqJDYH/1rMkKS+lMoSe3vmk5yWRSzs SdBQi/2xGSfyrfFUJzfNRx6k79s/k3K+z6a6WM0nEyCoFzxZUn0rkq2BwDKTsd+u msiGNH4lcm7FAILfCtfbrTg+TTUwL9DDt0H/cl+0Kj9aHlAssRviakhQHva/VNnO uSLJ6kF7ZusPdGy1Oup+Zi968/ocbqq9Tb6uPy83E9QVfc15kDams+IbcItSSqyg zASMNVP7eAF7UTGbppLFZdGywLpcdk4oawyEPeSc9vn8M+k/foXmHBAeK77j0p0/ gv7t7g/thBvz9ysJDIjk1UknijCZSozZaSFJXqhbly1LKxMn80n/y7Vy2Xf3NKo= =P7ea -----END PGP SIGNATURE----- --00f93ITSolJcO3LTGdIGKosOB0daMAJGn--