> ... But your argument that 16 bits is at a premium may be worth > considering an alternative representation for the same information. > > Possibility 1: when we run out of our current 16 transmission flags, > we'll need a way to extend the protocol to support more than that. To > do that, we'd probably want a new Handshake flag > NBD_FLAG_LARGE_TRANSMISSION_FLAGS sent by the server, and which must be > answered by the client sending a new Client flag > NBD_FLAG_C_LARGE_TRANSMISSION_FLAGS, so that both sides know that all > subsequent places in the protocol that send transmission flags will now > send 64 bits instead of 16 bits (old-style negotiation cannot benefit > from this, and is permanently stuck at 16 bits, but we discourage > old-style negotiation). We'd still want to prioritize which bits land > in the first 16 positions, for maximum compatibility with older servers > or clients (where the higher bit positions are used for data that is > more suited for optimizations, rather than controlling correct usage) - > thus NBD_FLAG_INIT_ZEROES would serve as an example to live in the > extended positions.
Well, to me, this just reads like the transmission flags aren't limited to 16 bits as you've demonstrated a workaround. Any client/server needing to interpret more bits than the 16 just needs to also understand extended transmission bit flags. I don't that that's an unreasonable requirement, so I don't actually buy the prioritisation argument. So this seems to me like a good argument we should proceed how you originally suggested and Wouter should be less worried about your flag-burning activities :-) > Possibility 2: Leverage the extension-info branch: Add a new > NBD_INFO_INIT_ZERO information datum. NBD_BLOCK_INFO already exists to I think you mean NBD_INFO_BLOCK_SIZE? > let server and client exchange as much per-export information as they > want during handshake without burning any new transmission flags, and > with a specification that gracefully ignores unknown requests from the > client and unknown advertisements from the server. There's the drawback > that the server can't advertise the known-zero-init optimization to > clients that don't use NBD_OPT_GO, but that's not too bad (especially if > qemu is the first client with code to actually make use of the > optimization, since I am already trying to get qemu to be one of the > first adopters of NBD_OPT_GO). I think you are suggesting add NBD_INFO_SOMETHINGELSE which could be extended transmission flags. Fair enough. Possibility #3: we modify NBD_INFO_EXPORT (which is still experimental) *now* to have an extended transmission flags 64 bits. This is where transmission flags SHOULD go, and just as we'll run out of them in NBD_OPT_EXPORT_NAME we'll also run out of the same 16 flags in NBD_OPT_GO. So it seems a good idea to free us from that limitation now. And all clients (one hopes) will use NBD_OPT_GO eventually. This has the minor disadvantage of breaking clients that rely on the current state of the experimental extension, but that's why it's experimental. Newer clients can talk to older servers if they are so inclined by checking the length field on the option (which will extend to 16 from 12). > We'll probably have to eventually use something along the lines of > possibility 1 for more transmission flags for some other reason down the > road (since we have lately been adding one flag per new command/command > group as we add extensions), but I agree that it is a bit heavy for now. > So it sounds like I should rework the proposal along the lines of > possibility 2, which also implies that we should get extension-info > ready for promotion to current. And that means that my current proposal > to the extension-write-zeroes branch is probably not ideal, but it > reopens the question of whether extension-write-zeroes as it currently > stands is ready for promotion to stable now that qemu 2.8 implements it. My view is: #0 (your original proposal) is actually fine. #1 seems too heavy #2 also seems pretty heavyweight - adding a whole new info command for one bit #3 is pretty simple, but carries the disadvantage that you won't be able to provide a reference implementation without also putting NBD_OPT_GO support into the reference implementation. Oh hang on, perhaps that's an advantage :-) So I'd either go with #0 or #3. -- Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
