[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZ8+_GYecvgGUXdOFj4Oca=U3_23PLWBJSAi0A8=gwReg@mail.gmail.com>
Date: Thu, 19 Dec 2019 13:14:46 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
Networking <netdev@...r.kernel.org>,
Alexei Starovoitov <ast@...com>,
Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 2/3] libbpf/tools: add runqslower tool to libbpf
On Thu, Dec 19, 2019 at 7:41 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> On Wed, Dec 18, 2019 at 11:06:57PM -0800, Andrii Nakryiko wrote:
> > Convert one of BCC tools (runqslower [0]) to BPF CO-RE + libbpf. It matches
> > its BCC-based counterpart 1-to-1, supporting all the same parameters and
> > functionality.
> >
> > runqslower tool utilizes BPF skeleton, auto-generated from BPF object file,
> > as well as memory-mapped interface to global (read-only, in this case) data.
> > Its makefile also ensures auto-generation of "relocatable" vmlinux.h, which is
> > necessary for BTF-typed raw tracepoints with direct memory access.
> >
> > [0] https://github.com/iovisor/bcc/blob/11bf5d02c895df9646c117c713082eb192825293/tools/runqslower.py
> >
> > Signed-off-by: Andrii Nakryiko <andriin@...com>
> > ---
> > tools/lib/bpf/tools/runqslower/.gitignore | 2 +
> > tools/lib/bpf/tools/runqslower/Makefile | 60 ++++++
> > .../lib/bpf/tools/runqslower/runqslower.bpf.c | 101 ++++++++++
> > tools/lib/bpf/tools/runqslower/runqslower.c | 187 ++++++++++++++++++
> > tools/lib/bpf/tools/runqslower/runqslower.h | 13 ++
>
> tools/lib/bpf/tools/ is rather weird, please add to tools/bpf/ which is the
> more appropriate place we have for small tools. Could also live directly in
> there, e.g. tools/bpf/runqslower.{c,h,bpf.c} and then built/run from selftests,
> but under libbpf directly is too odd.
runqslower is as much as a showcase of how to build a stand-alone tool
with libbpf and CO-RE, as a separate tool, which is why I put it under
libbpf directory. It's also not really BPF-specific tool, wouldn't
that make it weird to put it under tools/bpf along the bpftool? If we
added few more such tools using BPF CO-RE + libbpf, would you feel
it's still a good idea to put them under tools/bpf?
I tried to follow BCC structure, which has tools/ subdirectory with
all kinds of examples/tools built with BCC (but not necessarily used
by BCC itself). This is the same idea here.
>
> Thanks,
> Daniel
Powered by blists - more mailing lists