From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akyFG-0000PO-NS for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:20:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akyFD-00018K-Gp for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:20:02 -0400 Received: from barbershop.grep.be ([89.106.240.122]:53506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akyFD-000182-AI for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:19:59 -0400 Date: Tue, 29 Mar 2016 20:19:49 +0200 From: Wouter Verhelst Message-ID: <20160329181949.GB12469@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> <20160329180314.GA12469@grep.be> <56FAC47F.9010807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FAC47F.9010807@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" On Tue, Mar 29, 2016 at 12:07:59PM -0600, Eric Blake wrote: > On 03/29/2016 12:03 PM, Wouter Verhelst wrote: > > On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote: > >> 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. > > How does 64k sound? Dunno. It might make sense for this number to be based upon some "standard" minimum request size in things like ATA or SCSI if such a number exists there, but I don't know enough about either standard to answer that question myself. If such a number doesn't exist (or nobody who knows speaks up soon enough), 64k is certainly good enough, I suppose. -- < 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