From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akxzH-0000vO-9T for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:03:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akxzE-0004b5-38 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:03:31 -0400 Received: from barbershop.grep.be ([89.106.240.122]:33973) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akxzD-0004ar-TX for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:03:28 -0400 Date: Tue, 29 Mar 2016 20:03:14 +0200 From: Wouter Verhelst Message-ID: <20160329180314.GA12469@grep.be> 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> <56FA9B42.2020503@redhat.com> <08706CF2-6DA1-421E-827D-6C08CC08A9EA@alex.org.uk> <56FABF49.8080205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FABF49.8080205@redhat.com> 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: Eric Blake Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Alex Bligh 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 them without any > > further requirements. > > Supporting DF merely transfers the burden of collection between server > and client. I suspect that there are cases where the server does NOT > want to support DF (because it would require the server to allocate > memory to collect the data before sending a single structured read > reply), 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 state that a server MAY reply to any request with DF set for a block larger than that minimum, with that error. Otherwise the client could conceivably send out heaps of requests for (UINT32_MAX - 8) bytes with DF set and basically DoS the server. > just as you have stated that there are cases where the client > has an additional burden if DF is not supported. So for v2, I'm going > to explicitly document a DF export flag, and recommend (but not require) > that the server support it. I'd prefer not to see 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