From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al2OF-0008Qu-17 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 18:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1al2O9-0002ZK-Vw for qemu-devel@nongnu.org; Tue, 29 Mar 2016 18:45:34 -0400 Received: from barbershop.grep.be ([89.106.240.122]:34533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al2O9-0002Yf-Pf for qemu-devel@nongnu.org; Tue, 29 Mar 2016 18:45:29 -0400 Date: Wed, 30 Mar 2016 00:45:17 +0200 From: Wouter Verhelst Message-ID: <20160329224517.GB5466@grep.be> 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> <56FADEFA.8070207@redhat.com> <7E85EC50-7289-43CA-8DCC-D933B4B28A22@alex.org.uk> <20160329210545.GB19767@grep.be> <044DDAC6-039B-4C29-A83F-445B4E68AB0D@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <044DDAC6-039B-4C29-A83F-445B4E68AB0D@alex.org.uk> 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" , "qemu-devel@nongnu.org" 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 (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 was saying that should be up to the server. If the server wants to > >> write something easily decodable (and easier to maintain) at the expense > >> of a few more bytes on the wire, then let it. If it wants to use > >> unstructured replies occasionally, that's fine. > > > > In adding that flexibility, you're adding more code paths on the client > > (that need to be tested, etc), for (IMO) little benefit. > > > > I would instead prefer to specify per command whether the reply is going > > to be structured or not, and only have the read command be a special > > case were both are possible, for backwards compatibility only. That way, > > it can eventually be deprecated, too. > > I guess this is what comes of doing more NBD server work than client > work :-) I'd look at it the other way around and say that only one > code path is being exercised on the server, Yes, but both code paths need to _exist_, which isn't the case with having only one legal reply type per request type. The server just needs to send header X for replies A, B, C, and header Y for replies D, E, F. Forming the header is part of producing the reply type, and will be the same for every conversation -- except for read replies, where it could possibly be either (but that can't be avoided). > and that having multiple types of reply depending on command builds > fragility into the protocol. I'd think that having the legal reply type depend on context is actually more fragile. > If you want no choice in response type for the server for any given > session (i.e. code path minimisation on the client) my preference would > be what Eric didn't like, i.e. always send structured replies for > all commands if you negotiate structured replies, else always send > unstructured replies. 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. > We're talking an overhead of 8 bytes here (flags & error offset); > somehow I suspect the time to transmit 8 bytes is going to be > negligible compared to disk time or the rest of the network tx/rx > time. Sure, but I'm not worried about that. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12