[Libguestfs] [libnbd PATCH 3/4] api: Add new nbd_stats_*() statistics counters
Richard W.M. Jones
rjones at redhat.com
Mon Sep 5 13:07:57 UTC 2022
On Mon, Sep 05, 2022 at 02:12:24PM +0200, Laszlo Ersek wrote:
> On 09/03/22 18:30, Richard W.M. Jones wrote:
> > On Fri, Sep 02, 2022 at 05:14:24PM -0500, Eric Blake wrote:
> >> I was trying to write a test that determined whether a failure was due
> >> to a short-circuit test on the client side or an actual failure
> >> returned by the server. Such a test is a lot easier if we can watch
> >> status counters increase according to how much traffic goes over the
> >> wire. We may add more stats later (for example, how many bytes were
> >> written by nbd_[aio_]pread, or even how many times we had to grab the
> >> lock as part of an nbd_* command); or even to reset the counters for
> >> determining the protocol overhead around a particular set of I/O
> >> options, but this is a fun start.
> >>
> >> In this patch, update an example to serve as a compile time test of
> >> the new API; the next patch will add a runtime test of some simple
> >> uses while also checking the language bindings.
> >> ---
> >> docs/libnbd.pod | 20 ++++++++
> >> generator/API.ml | 78 +++++++++++++++++++++++++++++-
> >> lib/handle.c | 28 +++++++++++
> >> examples/strict-structured-reads.c | 13 ++++-
> >> 4 files changed, 135 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/docs/libnbd.pod b/docs/libnbd.pod
> >> index 7a01179a..d256cd65 100644
> >> --- a/docs/libnbd.pod
> >> +++ b/docs/libnbd.pod
> >> @@ -940,6 +940,26 @@ should return C<1> on all control paths, even when handling errors
> >> (note that with automatic retirement, assigning into C<error> is
> >> pointless as there is no later API to see that value).
> >>
> >> +=head1 STATISTICS COUNTERS
> >> +
> >> +Libnbd tracks several statistics counters, useful for tracking how
> >> +much traffic was sent over the connection. The counters track the
> >> +number of bytes sent and received, as well as the number of protocol
> >> +chunks (a group of bytes delineated by a magic number).
> >> +
> >> + printf ("bytes: sent=%" PRIu64 " received=%" PRIu64,
> >> + nbd_stats_bytes_sent (nbd), nbd_stats_bytes_received (nbd));
> >> + printf ("chunks: sent=%" PRIu64 " received=%" PRIu64,
> >> + nbd_stats_chunks_sent (nbd), nbd_stats_chunks_received (nbd));
> >
> > You probably also want to note that if TLS is enabled these don't
> > relate closely to either bytes or packets sent.
> >
> >> +Note that if a command fails early at the client without needing to
> >> +consult the server, the counters will not be incremented; conversely,
> >> +the chunk counts can increase by more than one for a single API call
> >> +(for example, L<nbd_opt_go(3)> defaults to sending a two-option
> >> +sequence of C<NBD_OPT_SET_META_CONTEXT> and C<NBD_OPT_GO>, and the
> >> +server in turn replies with multiple C<NBD_REP_INFO> before concluding
> >> +with C<NBD_REP_ACK>).
> >
> > The trouble is that by writing this down, we need to keep supporting
> > this. If you don't write it down, but it's implicit in our tests then
> > we can change the API later if it turns out to be hard to support. So
> > my preference would be to simply delete this paragraph and similar
> > below ...
>
> We ought to be able to document the (originally) intended purpose of a
> feature such that it does not come with "support strings attached".
> Commit messages are good, code comments are good too, yes, but what
> about explicit documentation? E.g. "p2v-hacking.pod" is a great thing.
>
> Anyway I don't insist; I just thought (without realizing the "support
> strings attached") that exactly those paragraphs were the nicest touch ;)
In libnbd we've committed to supporting the ABI as long as the project
is around, so that means the barrier to entry for new features is a
bit higher. I'm wary in particular of features that appear to depend
on internal implementations because that makes things very hard to
change in future.
Counting bytes seems to be OK though because NBD is always going to
send bytes on a wire (and if it doesn't, we return 0).
This could also be about where the documentation goes or whether it is
defended with suitable disclaimers about "this may change / break in
future". But as written above it looks like something supported.
Rich.
> So either way:
>
> Acked-by: Laszlo Ersek <lersek at redhat.com>
>
> Laszlo
>
> >
> >> =head1 SIGNALS
> >>
> >> Libnbd does not install signal handlers. It attempts to disable
> >> diff --git a/generator/API.ml b/generator/API.ml
> >> index e4e2ea0a..dbfde284 100644
> >> --- a/generator/API.ml
> >> +++ b/generator/API.ml
> >> @@ -307,6 +307,70 @@ "clear_debug_callback", {
> >> callback was associated this does nothing.";
> >> };
> >>
> >> + "stats_bytes_sent", {
> >> + default_call with
> >> + args = []; ret = RUInt64;
> >> + may_set_error = false;
> >> + shortdesc = "statistics of bytes sent over socket so far";
> >> + longdesc = "\
> >> +Return the number of bytes that the client has sent to the server.";
> >> + see_also = [Link "stats_chunks_sent";
> >> + Link "stats_bytes_received"; Link "stats_chunks_received"];
> >> + };
> >> +
> >> + "stats_chunks_sent", {
> >> + default_call with
> >> + args = []; ret = RUInt64;
> >> + may_set_error = false;
> >> + shortdesc = "statistics of chunks sent over socket so far";
> >> + longdesc = "\
> >> +Return the number of chunks that the client has sent to the
> >> +server, where a chunk is a group of bytes delineated by a magic
> >> +number that cannot be further subdivided without breaking the
> >> +protocol.
> >> +
> >> +This number increments when a request is sent to the server;
> >> +it is unchanged for an API that fails during initial client-side
> >> +sanity checking (see L<nbd_set_strict_mode(3)>), and can
> >> +increment by more than one for APIs that wrap multiple
> >> +underlying requests (such as L<nbd_opt_go(3)>).";
> >
> > ^ This one.
> >
> >> + see_also = [Link "stats_bytes_sent";
> >> + Link "stats_bytes_received"; Link "stats_chunks_received";
> >> + Link "set_strict_mode"];
> >> + };
> >> +
> >> + "stats_bytes_received", {
> >> + default_call with
> >> + args = []; ret = RUInt64;
> >> + may_set_error = false;
> >> + shortdesc = "statistics of bytes received over socket so far";
> >> + longdesc = "\
> >> +Return the number of bytes that the client has received from the server.";
> >> + see_also = [Link "stats_chunks_received";
> >> + Link "stats_bytes_sent"; Link "stats_chunks_sent"];
> >> + };
> >> +
> >> + "stats_chunks_received", {
> >> + default_call with
> >> + args = []; ret = RUInt64;
> >> + may_set_error = false;
> >> + shortdesc = "statistics of chunks received over socket so far";
> >> + longdesc = "\
> >> +Return the number of chunks that the client has received from the
> >> +server, where a chunk is a group of bytes delineated by a magic
> >> +number that cannot be further subdivided without breaking the
> >> +protocol.
> >> +
> >> +This number increments when a reply is received from the server;
> >> +it is unchanged for an API that fails during initial client-side
> >> +sanity checking (see L<nbd_set_strict_mode(3)>), and can
> >> +increment by more than one when the server utilizes structured
> >> +replies (see L<nbd_get_structured_replies_negotiated(3)>).";
> >
> > ^ This one.
> >
> >> + see_also = [Link "stats_bytes_received";
> >> + Link "stats_bytes_sent"; Link "stats_chunks_sent";
> >> + Link "get_structured_replies_negotiated"];
> >> + };
> >> +
> >> "set_handle_name", {
> >> default_call with
> >> args = [ String "handle_name" ]; ret = RErr;
> >> @@ -945,8 +1009,14 @@ "set_strict_mode", {
> >> such, when attempting to relax only one specific bit while keeping
> >> remaining checks at the client side, it is wiser to first call
> >> L<nbd_get_strict_mode(3)> and modify that value, rather than
> >> -blindly setting a constant value.";
> >> - see_also = [Link "get_strict_mode"; Link "set_handshake_flags"];
> >> +blindly setting a constant value.
> >> +
> >> +When commands are not being attempted in parallel, it is possible
> >> +to observe whether a given command was filtered at the client
> >> +or triggered a server response by whether the statistics
> >> +counters increase (such as L<nbd_stats_bytes_sent(3)>).";
> >
> > ^ This one.
> >
> >> + see_also = [Link "get_strict_mode"; Link "set_handshake_flags";
> >> + Link "stats_bytes_sent"; Link "stats_bytes_received"];
> >> };
> >>
> >> "get_strict_mode", {
> >> @@ -3274,6 +3344,10 @@ let first_version =
> >> (* Added in 1.15.x development cycle, will be stable and supported in 1.16. *)
> >> "poll2", (1, 16);
> >> "supports_vsock", (1, 16);
> >> + "stats_bytes_sent", (1, 16);
> >> + "stats_chunks_sent", (1, 16);
> >> + "stats_bytes_received", (1, 16);
> >> + "stats_chunks_received", (1, 16);
> >>
> >> (* These calls are proposed for a future version of libnbd, but
> >> * have not been added to any released version so far.
> >> diff --git a/lib/handle.c b/lib/handle.c
> >> index 7fcdc8cd..d4426260 100644
> >> --- a/lib/handle.c
> >> +++ b/lib/handle.c
> >> @@ -548,3 +548,31 @@ nbd_unlocked_set_uri_allow_local_file (struct nbd_handle *h, bool allow)
> >> h->uri_allow_local_file = allow;
> >> return 0;
> >> }
> >> +
> >> +/* NB: may_set_error = false. */
> >> +uint64_t
> >> +nbd_unlocked_stats_bytes_sent (struct nbd_handle *h)
> >> +{
> >> + return h->bytes_sent;
> >> +}
> >> +
> >> +/* NB: may_set_error = false. */
> >> +uint64_t
> >> +nbd_unlocked_stats_chunks_sent (struct nbd_handle *h)
> >> +{
> >> + return h->chunks_sent;
> >> +}
> >> +
> >> +/* NB: may_set_error = false. */
> >> +uint64_t
> >> +nbd_unlocked_stats_bytes_received (struct nbd_handle *h)
> >> +{
> >> + return h->bytes_received;
> >> +}
> >> +
> >> +/* NB: may_set_error = false. */
> >> +uint64_t
> >> +nbd_unlocked_stats_chunks_received (struct nbd_handle *h)
> >> +{
> >> + return h->chunks_received;
> >> +}
> >> diff --git a/examples/strict-structured-reads.c b/examples/strict-structured-reads.c
> >> index 6ea17006..b56a4825 100644
> >> --- a/examples/strict-structured-reads.c
> >> +++ b/examples/strict-structured-reads.c
> >> @@ -4,6 +4,10 @@
> >> * qemu-nbd -f $format -k $sock -r image
> >> * ./strict-structured-reads $sock
> >> *
> >> + * With nbdkit (but less useful until nbdkit learns to send holes):
> >> + *
> >> + * nbdkit -U- sparse-random 1G --run './strict-structured-reads "$unixsocket"'
> >> + *
> >
> > Is this hunk meant to be included?
> >
> >> * This will perform read randomly over the image and check that all
> >> * structured replies comply with the NBD spec (chunks may be out of
> >> * order or interleaved, but no read succeeds unless chunks cover the
> >> @@ -257,8 +261,11 @@ main (int argc, char *argv[])
> >> exit (EXIT_FAILURE);
> >> }
> >>
> >> - nbd_close (nbd);
> >> -
> >> + printf ("traffic:\n");
> >> + printf (" bytes sent: %10" PRIu64 "\n", nbd_stats_bytes_sent (nbd));
> >> + printf (" bytes received: %10" PRIu64 "\n", nbd_stats_bytes_received (nbd));
> >> + printf (" chunks sent: %10" PRIu64 "\n", nbd_stats_chunks_sent (nbd));
> >> + printf (" chunks received: %10" PRIu64 "\n", nbd_stats_chunks_received (nbd));
> >> printf ("totals:\n");
> >> printf (" data chunks: %10d\n", total_data_chunks);
> >> printf (" data bytes: %10" PRId64 "\n", total_data_bytes);
> >> @@ -270,5 +277,7 @@ main (int argc, char *argv[])
> >> printf (" bytes read: %10" PRId64 "\n", total_bytes);
> >> printf (" compliant: %10d\n", total_success);
> >>
> >> + nbd_close (nbd);
> >> +
> >> exit (EXIT_SUCCESS);
> >> }
> >> --
> >
> > Rich.
> >
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
More information about the Libguestfs
mailing list