From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aky3s-0003U1-HG for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:08:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aky3c-0006Sy-Vc for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:08:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aky3c-0006Ss-OS for qemu-devel@nongnu.org; Tue, 29 Mar 2016 14:08:00 -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> <56FA9B42.2020503@redhat.com> <08706CF2-6DA1-421E-827D-6C08CC08A9EA@alex.org.uk> <56FABF49.8080205@redhat.com> <20160329180314.GA12469@grep.be> From: Eric Blake Message-ID: <56FAC47F.9010807@redhat.com> Date: Tue, 29 Mar 2016 12:07:59 -0600 MIME-Version: 1.0 In-Reply-To: <20160329180314.GA12469@grep.be> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OVBe5mMIfNi4cgSI2AKvIOnC4nxqFIaB5" 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: Wouter Verhelst Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Alex Bligh This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OVBe5mMIfNi4cgSI2AKvIOnC4nxqFIaB5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2016 12:03 PM, Wouter Verhelst wrote: > 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), >=20 > 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 b= e > 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? >=20 > Otherwise the client could conceivably send out heaps of requests for > (UINT32_MAX - 8) bytes with DF set and basically DoS the server. Point taken. >=20 >> 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 requir= e) >> that the server support it. >=20 > I'd prefer not to see that. Okay, good thing I haven't sent v2 yet; I'm making more edits to drop the export flag, and require unconditional support for the command flag once structured reads are negotiated. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OVBe5mMIfNi4cgSI2AKvIOnC4nxqFIaB5 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+sR/AAoJEKeha0olJ0NqipAIAJt7Sd4mE4GfJkbABQBAbHqJ prmCcrOYTwlwi/7MQPdIXnf8Ff6pz2p0JzjG9eYCtnRsyPZHK8jwLUWwdzX7J0Hy rlqfPAlMZ4gXp7Okp+Gzfs4QJeiHoUBHiVwnu9YcPmcDIBiE3+AnMZJXW+spE6Kg YCj+znsFq7eyNTPu0i+Nyo3J+Nlzwb/0qKW+nB63aOUXH1r97oORm3XaFFwwiynl QEYwmdMjimxuoCPQ/JN526yzm/Fk30heQkk4W4K+FGaUMZhQGiaUNeY5NMZH+H+A ZkQhPsUnxVUdVGc/Yp4b/m4yqA5LrhcLGw0bontUENdYohwOKiRGpGXAUOQ29YQ= =jS4I -----END PGP SIGNATURE----- --OVBe5mMIfNi4cgSI2AKvIOnC4nxqFIaB5--