search for: nbd_flag_send_fast_zero

...ite, than it is for the > client to have to perform the fallback to send NBD_CMD_WRITE with a > zeroed buffer. > > Add a protocol flag and corresponding transmission advertisement flag > to make it easier for clients to inform the server of their intent. If > the server advertises NBD_FLAG_SEND_FAST_ZERO, then it promises two > things: to perform a fallback to write when the client does not > request NBD_CMD_FLAG_FAST_ZERO (so that the client benefits from the > lower network overhead); and to fail quickly with ENOTSUP if the > client requested the flag but the server cannot write zeroe...

...the fallback to the slower write, than it is for the client to have to perform the fallback to send NBD_CMD_WRITE with a zeroed buffer. Add a protocol flag and corresponding transmission advertisement flag to make it easier for clients to inform the server of their intent. If the server advertises NBD_FLAG_SEND_FAST_ZERO, then it promises two things: to perform a fallback to write when the client does not request NBD_CMD_FLAG_FAST_ZERO (so that the client benefits from the lower network overhead); and to fail quickly with ENOTSUP if the client requested the flag but the server cannot write zeroes more efficiently t...

...the fallback to the slower write, than it is for the client to have to perform the fallback to send NBD_CMD_WRITE with a zeroed buffer. Add a protocol flag and corresponding transmission advertisement flag to make it easier for clients to inform the server of their intent. If the server advertises NBD_FLAG_SEND_FAST_ZERO, then it promises two things: to perform a fallback to write when the client does not request NBD_CMD_FLAG_FAST_ZERO (so that the client benefits from the lower network overhead); and to fail quickly with ENOTSUP, preferably without modifying the export, if the client requested the flag but the ser...

...index 3e3fb4e..04e93d3 100644 --- a/lib/nbd-protocol.h +++ b/lib/nbd-protocol.h @@ -108,6 +108,7 @@ struct nbd_fixed_new_option_reply { #define NBD_FLAG_SEND_DF (1 << 7) #define NBD_FLAG_CAN_MULTI_CONN (1 << 8) #define NBD_FLAG_SEND_CACHE (1 << 10) +#define NBD_FLAG_SEND_FAST_ZERO (1 << 11) /* NBD options (new style handshake only). */ #define NBD_OPT_EXPORT_NAME 1 @@ -250,6 +251,7 @@ struct nbd_structured_reply_error { #define NBD_EINVAL 22 #define NBD_ENOSPC 28 #define NBD_EOVERFLOW 75 +#define NBD_ENOTSUP 95 #define NBD_ESHUTDOWN 108 #...

...ave to implement all of the extensions, each extension that can be orthogonally implemented and show an improvement on its own is still worthwhile; and my cover letter has shown that fast zeroes on their own make a measurable difference to certain workloads. >> + If the server advertised `NBD_FLAG_SEND_FAST_ZERO` but >> + `NBD_CMD_FLAG_FAST_ZERO` is not set, then the server MUST NOT fail >> + with `NBD_ENOTSUP`, even if the operation is no faster than a >> + corresponding `NBD_CMD_WRITE`. Conversely, if >> + `NBD_CMD_FLAG_FAST_ZERO` is set, the server MUST fail quickly w...

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a

...w if it can send NBD_CMD_FLAG_FAST_ZERO). So we may still want to use NBD_OPT_* to get the initial zero extension, but NBD_FLAG to advertise the fast zero extension. On the other hand, it's also worth thinking about which extensions are easy for servers to implement - NBD_FLAG_INIT_ZEROES and NBD_FLAG_SEND_FAST_ZERO are orthogonal enough that I could see a full 2x2 mix of servers (unsupported, either one of the two supported, or both supported), and where clients may make optimization choices based on any of those four combinations. [and if we're keeping score, other extension proposals that I want revisi...

...90 100644 --- a/common/protocol/protocol.h +++ b/common/protocol/protocol.h @@ -96,6 +96,7 @@ extern const char *name_of_nbd_flag (int); #define NBD_FLAG_SEND_DF (1 << 7) #define NBD_FLAG_CAN_MULTI_CONN (1 << 8) #define NBD_FLAG_SEND_CACHE (1 << 10) +#define NBD_FLAG_SEND_FAST_ZERO (1 << 11) /* NBD options (new style handshake only). */ extern const char *name_of_nbd_opt (int); @@ -223,10 +224,11 @@ extern const char *name_of_nbd_cmd (int); #define NBD_CMD_BLOCK_STATUS 7 extern const char *name_of_nbd_cmd_flag (int); -#define NBD_CMD_FLAG_FUA (1<&l...

...FAST_ZERO). So we may still want to use NBD_OPT_* to get > the initial zero extension, but NBD_FLAG to advertise the fast zero > extension. > > On the other hand, it's also worth thinking about which extensions are > easy for servers to implement - NBD_FLAG_INIT_ZEROES and > NBD_FLAG_SEND_FAST_ZERO are orthogonal enough that I could see a full > 2x2 mix of servers (unsupported, either one of the two supported, or > both supported), and where clients may make optimization choices based > on any of those four combinations. > > [and if we're keeping score, other extension pro...

...2 /* Per-export flags. */ -extern const char *name_of_nbd_flag (int); #define NBD_FLAG_HAS_FLAGS (1 << 0) #define NBD_FLAG_READ_ONLY (1 << 1) #define NBD_FLAG_SEND_FLUSH (1 << 2) @@ -99,7 +97,6 @@ extern const char *name_of_nbd_flag (int); #define NBD_FLAG_SEND_FAST_ZERO (1 << 11) /* NBD options (new style handshake only). */ -extern const char *name_of_nbd_opt (int); #define NBD_OPT_EXPORT_NAME 1 #define NBD_OPT_ABORT 2 #define NBD_OPT_LIST 3 @@ -113,7 +110,6 @@ extern const char *name_of_nbd_opt (int); #define NBD...

...11 )) do_nbdkit () { @@ -133,8 +134,8 @@ EOF #---------------------------------------------------------------------- # can_write=true # -# NBD_FLAG_SEND_WRITE_ZEROES is set on writable connections -# even when can_zero returns false, because nbdkit reckons it +# NBD_FLAG_SEND_WRITE_ZEROES and NBD_FLAG_SEND_FAST_ZERO are set on writable +# connections even when can_zero returns false, because nbdkit reckons it # can emulate zeroing using pwrite. do_nbdkit <<'EOF' @@ -145,8 +146,8 @@ case "$1" in esac EOF -[ $eflags -eq $(( HAS_FLAGS|SEND_WRITE_ZEROES|SEND_DF )) ] || - fail &quot...

...y been + enabled. + ### Transmission phase #### Flag fields @@ -1725,6 +1882,17 @@ valid may depend on negotiation during the handshake phase. `NBD_CMD_WRITE`, then the server MUST fail quickly with an error of `NBD_ENOTSUP`. The client MUST NOT set this unless the server advertised `NBD_FLAG_SEND_FAST_ZERO`. +- bit 5, `NBD_CMD_FLAG_PAYLOAD_LEN`; only valid if extended headers + were negotiated via `NBD_OPT_EXTENDED_HEADERS`. If set, the + *length* field of the header describes a (nonzero) payload length of + data to be sent alongside the header; if the flag is clear, the + header *length* is ins...

v2 was here: https://lists.debian.org/nbd/2022/11/msg00030.html The bulk of the changes since then are: - forbid NBD_OPT_EXPORT_NAME once extended headers are negotiated (Wouter) - consistently use 'maximum payload', rather than a haphazard mix of 'maximum block payload' (Vladimir) At this point, I want to make sure we are happy with the spec before re-posting patches for

...LY; - fl = backend_can_zero (backend); + fl = backend_can_zero (top); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_WRITE_ZEROES; - fl = backend_can_fast_zero (backend); + fl = backend_can_fast_zero (top); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_FAST_ZERO; - fl = backend_can_trim (backend); + fl = backend_can_trim (top); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_TRIM; - fl = backend_can_fua (backend); + fl = backend_can_fua (top); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_FUA; -...

We should have only one NBD protocol file. Let's make nbdkit's version the canonical one, and use it in libnbd. Rich.

...d_can_zero (backend, conn); + fl = backend_can_zero (backend); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_WRITE_ZEROES; - fl = backend_can_fast_zero (backend, conn); + fl = backend_can_fast_zero (backend); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_FAST_ZERO; - fl = backend_can_trim (backend, conn); + fl = backend_can_trim (backend); if (fl == -1) return -1; if (fl) eflags |= NBD_FLAG_SEND_TRIM; - fl = backend_can_fua (backend, conn); + fl = backend_can_fua (backend); if (fl == -1) return -1; if (fl) eflags |= NB...

v1 was here: https://www.redhat.com/archives/libguestfs/2020-February/msg00081.html v2 replaces struct connection *conn = GET_CONN; with GET_CONN; which sets conn implicitly and asserts that it is non-NULL. If we actually want to test if conn is non-NULL or behave differently, then you must use threadlocal_get_conn() instead, and some existing uses do that. Rich.

The third patch is a large but mechanical change which gets rid of passing around struct connection * entirely within the server, preferring instead to reference the connection through thread-local storage. I hope this is a gateway to simplifying other parts of the code. Rich.