From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akxiB-0002cs-1j for qemu-devel@nongnu.org; Tue, 29 Mar 2016 13:45:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akxi6-0008Be-T8 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 13:45:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akxi6-0008BQ-Kb for qemu-devel@nongnu.org; Tue, 29 Mar 2016 13:45:46 -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> From: Eric Blake Message-ID: <56FABF49.8080205@redhat.com> Date: Tue, 29 Mar 2016 11:45:45 -0600 MIME-Version: 1.0 In-Reply-To: <08706CF2-6DA1-421E-827D-6C08CC08A9EA@alex.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EQFOGdqVcixCjXE79KC5NsCpkEDBGAjFH" 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) --EQFOGdqVcixCjXE79KC5NsCpkEDBGAjFH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2016 11:34 AM, Alex Bligh wrote: >=20 > On 29 Mar 2016, at 16:12, Eric Blake wrote: >>> >>> More a way of guaranteeing avoiding a fragmentation on 'simple' reads= =2E >>> Perhaps a 'DF' bit (don't fragment)! If the server doesn't like it, i= t >>> can always error the command. >> >> Okay, that makes sense. Does reusing NBD_CMD_FLAG_FUA sound reasonabl= e >> 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. >=20 > I think it should be separate from FUA, as there are possibly > servers out there that support FUA but not this, but ... >=20 >> 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. >=20 > 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), 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. >=20 >> 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). >=20 > I suspect the name is the thing that makes the least difference, and > hence do not feel strongly at all, but: >=20 > a) Why '_C_'? Matches existing convention on client flags; but Wouter's idea of using NBD_OPT_ instead of global/client flags is better, so the _C_ disappears in v2. >=20 > b) Throughout the current documentation you've called them 'structured > replies', not 'structured reads' and said that in the future multipl= e > commands might support them. So you should arguably call the flag > '*_STRUCTURED_REPLY' or change the text. I'm changing the text, and favoring the name STRUCTURED_READ except in the description of the transmission phase, where Structured Reply is the header used for ANY form of reply with data (to make it more obvious that structured read is a subset of structured replies), while at the same time emphasizing that NBD_CMD_READ is the only command that can get away with data in a non-structured reply, and only when structured read was not negotiated. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --EQFOGdqVcixCjXE79KC5NsCpkEDBGAjFH 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+r9JAAoJEKeha0olJ0NqPK4H/iWidVQ+PcJAMCLXxVGe6kCL XCr3eHaL6JbOOekdSl07KqHs/FRy94Q414SfC+wnlJaVnFCjI9r1sK8qUbscap5J n+nBdeZ0E4KfgeXfkRCslvMZIfb7ykQQaJRhNejvAH44W2W1mkMDtGn1s21L6gHc RpsaWHXjqIrWLMAxzHxiUawuETTnSu1z/HLouvts2cDT0lVej9YHEvroNFrPWLw1 b3UoIHvu2T8DIAEU2ZQOqh1LxPgPlP0jpJNIHLIMqe0jlUscFvehqIN4YlBQkt5f BNP3QEPgwNQGwPwwgwpYW0S8AFHbQn8XHcUqhnIzHB4otQfJZE1o/IiugUQ7n14= =Se00 -----END PGP SIGNATURE----- --EQFOGdqVcixCjXE79KC5NsCpkEDBGAjFH--