BPF List
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org
Cc: martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
	yonghong.song@linux.dev, john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@google.com, haoluo@google.com,
	jolsa@kernel.org, bpf@vger.kernel.org,
	Alan Maguire <alan.maguire@oracle.com>
Subject: [RFC bpf-next 0/2] libbpf Userspace Runtime-Defined Tracing (URDT)
Date: Wed, 31 Jan 2024 16:20:01 +0000	[thread overview]
Message-ID: <20240131162003.962665-1-alan.maguire@oracle.com> (raw)

Adding userspace tracepoints in other languages like python and
go is a very useful for observability.  libstapsdt [1]
and language bindings like python-stapsdt [2] that rely on it
use a clever scheme of emulating static (USDT) userspace tracepoints
at runtime.  This involves (as I understand it):

- fabricating a shared library
- annotating it with ELF notes that describe its tracepoints
- dlopen()ing it and calling the appropriate probe fire function
  to trigger probe firing.

bcc already supports this mechanism (the examples in [2] use
bcc to list/trigger the tracepoints), so it seems like it
would be a good candidate for adding support to libbpf.

However, before doing that, it's worth considering if there
are simpler ways to support runtime probe firing.  This
small series demonstrates a simple method based on USDT
probes added to libbpf itself.

The suggested solution comprises 3 parts

1. functions to fire dynamic probes are added to libbpf itself
   bpf_urdt__probeN(), where N is the number of probe arguemnts.
   A sample usage would be
	bpf_urdt__probe3("myprovider", "myprobe", 1, 2, 3);

   Under the hood these correspond to USDT probes with an
   additional argument for uniquely identifying the probe
   (a hash of provider/probe name).

2. we attach to the appropriate USDT probe for the specified
   number of arguments urdt/probe0 for none, urdt/probe1 for
   1, etc.  We utilize the high-order 32 bits of the attach
   cookie to store the hash of the provider/probe name.

3. when urdt/probeN fires, the BPF_URDT() macro (which
   is similar to BPF_USDT()) checks if the hash passed
   in (identifying provider/probe) matches the attach
   cookie high-order 32 bits; if not it must be a firing
   for a different dynamic probe and we exit early.

Auto-attach support is also added, for example the following
would add a dynamic probe for provider:myprobe:

SEC("udrt/libbpf.so:2:myprovider:myprobe")
int BPF_URDT(myprobe, int arg1, char *arg2)
{
 ...
}

(Note the "2" above specifies the number of arguments to
the probe, otherwise it is identical to USDT).

The above program can then be triggered by a call to

 BPF_URDT_PROBE2("myprovider", "myprobe", 1, "hi");

The useful thing about this is that by attaching to
libbpf.so (and firing probes using that library) we
can get system-wide dynamic probe firing.  It is also
easy to fire a dynamic probe - no setup is required.

More examples of auto and manual attach can be found in
the selftests (patch 2).

If this approach appears to be worth pursing, we could
also look at adding support to libstapsdt for it.

Alan Maguire (2):
  libbpf: add support for Userspace Runtime Dynamic Tracing (URDT)
  selftests/bpf: add tests for Userspace Runtime Defined Tracepoints
    (URDT)

 tools/lib/bpf/Build                           |   2 +-
 tools/lib/bpf/Makefile                        |   2 +-
 tools/lib/bpf/libbpf.c                        |  94 ++++++++++
 tools/lib/bpf/libbpf.h                        |  94 ++++++++++
 tools/lib/bpf/libbpf.map                      |  13 ++
 tools/lib/bpf/libbpf_internal.h               |   2 +
 tools/lib/bpf/urdt.bpf.h                      | 103 +++++++++++
 tools/lib/bpf/urdt.c                          | 145 +++++++++++++++
 tools/testing/selftests/bpf/Makefile          |   2 +-
 tools/testing/selftests/bpf/prog_tests/urdt.c | 173 ++++++++++++++++++
 tools/testing/selftests/bpf/progs/test_urdt.c | 100 ++++++++++
 .../selftests/bpf/progs/test_urdt_shared.c    |  59 ++++++
 12 files changed, 786 insertions(+), 3 deletions(-)
 create mode 100644 tools/lib/bpf/urdt.bpf.h
 create mode 100644 tools/lib/bpf/urdt.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/urdt.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_urdt.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_urdt_shared.c

-- 
2.39.3


             reply	other threads:[~2024-01-31 16:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 16:20 Alan Maguire [this message]
2024-01-31 16:20 ` [RFC bpf-next 1/2] libbpf: add support for Userspace Runtime Dynamic Tracing (URDT) Alan Maguire
2024-01-31 16:20 ` [RFC bpf-next 2/2] selftests/bpf: add tests for Userspace Runtime Defined Tracepoints (URDT) Alan Maguire
2024-01-31 17:06 ` [RFC bpf-next 0/2] libbpf Userspace Runtime-Defined Tracing (URDT) Daniel Xu
2024-01-31 17:38   ` Alan Maguire
2024-01-31 18:01     ` Daniel Xu
2024-02-02 14:47 ` Alan Maguire
2024-02-02 21:39 ` Andrii Nakryiko
2024-02-06  9:49   ` Alan Maguire
2024-02-08  0:05     ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240131162003.962665-1-alan.maguire@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox