On 04/03/2018 01:03 PM, Wouter Verhelst wrote: >>> + A client MUST NOT send a cache request unless `NBD_FLAG_SEND_CACHE` >>> + was set in the transmission flags field. > > This presumably conflicts with xNBD, which does send out CMD_CACHE > without that flag (at least, the flag is not reserved, so...). However, > I do think that it's better to negotiate the cache command before trying > to use it, so I would just append the following to your proposed wording: > > However, implementations already exist that do send out NBD_CMD_CACHE > without negotiating its use through NBD_FLAG_SEND_CACHE; therefore, > implementations desiring maximum portability should allow for this > possibility. So, restating things to make sure I'm following: We're documenting that a server should be prepared for the client to call NBD_CMD_CACHE even though the server has not advertised it (existing xNBD clients); and that clients must be prepared for the call to return an error (most existing servers which don't recognize the command; but also possible even for servers that advertise the command). There is no requirement or visible return indication whether it even has an impact. The ONLY reason the command exists is that if the client knows how to use it, AND the server knows how to honor it, then you can get speedups; but we can't guarantee those speedups. Thus, even if the server always rejects the command as unknown, a client that sends the command for uniformity of command stream with other servers that can honor it, and there should be no observable difference in actual data behavior (just wasted overhead on the commands). On the other hand, if the server doesn't advertise support for NBD_CMD_CACHE, then the client is guessing whether the command makes a difference (it might offer speedups, but more likely does not); whereas when the server DOES advertise support, a client has some indication that caching may make a difference (even if some caching requests are rejected as errors due to alignment issues or even lack of cache space). So it looks like Vladimir's proposal is close, but that a v2 for some wording tweaks would help. Should this go directly into the mainline (since xNBD has already implemented NBD_CMD_CACHE), or into an extension branch for a bit (since NBD_FLAG_SEND_CACHE is new, although it has a proposal for inclusion in qemu 2.13)? It also looks like this is very easy to add (at least as a no-op) into any existing server implementation. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature