From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Song Liu <songliubraving@fb.com>,
open list <linux-kernel@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <Kernel-team@fb.com>,
john fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Daniel Xu <dlxu@fb.com>
Subject: Re: [PATCH bpf-next 5/5] selftests/bpf: add benchmark for uprobe vs. user_prog
Date: Wed, 5 Aug 2020 10:27:28 -0700 [thread overview]
Message-ID: <CAEf4BzYFfAubxo1QY6Axth=gwS9DfzwRkvnYLspfk9tLia0LPg@mail.gmail.com> (raw)
In-Reply-To: <20200805171639.tsqjmifd7eb3htou@ast-mbp.dhcp.thefacebook.com>
On Wed, Aug 5, 2020 at 10:16 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Aug 05, 2020 at 04:47:30AM +0000, Song Liu wrote:
> >
> > Being able to trigger BPF program on a different CPU could enable many
> > use cases and optimizations. The use case I am looking at is to access
> > perf_event and percpu maps on the target CPU. For example:
> > 0. trigger the program
> > 1. read perf_event on cpu x;
> > 2. (optional) check which process is running on cpu x;
> > 3. add perf_event value to percpu map(s) on cpu x.
>
> If the whole thing is about doing the above then I don't understand why new
> prog type is needed. Can prog_test_run support existing BPF_PROG_TYPE_KPROBE?
> "enable many use cases" sounds vague. I don't think folks reading
> the patches can guess those "use cases".
> "Testing existing kprobe bpf progs" would sound more convincing to me.
Was just about to propose the same :) I wonder if generic test_run()
capability to trigger test programs of whatever supported type on a
specified CPU through IPI can be added. That way you can even use the
XDP program to do what Song seems to need.
TRACEPOINTs might also be a good fit here, given it seems simpler to
let users specify custom tracepoint data for test_run(). Having the
ability to unit-test KPROBE and TRACEPOINT, however rudimentary, is
already a big win.
> If the test_run framework can be extended to trigger kprobe with correct pt_regs.
> As part of it test_run would trigger on a given cpu with $ip pointing
> to some test fuction in test_run.c. For local test_run the stack trace
> would include bpf syscall chain. For IPI the stack trace would include
> the corresponding kernel pieces where top is our special test function.
> Sort of like pseudo kprobe where there is no actual kprobe logic,
> since kprobe prog doesn't care about mechanism. It needs correct
> pt_regs only as input context.
> The kprobe prog output (return value) has special meaning though,
> so may be kprobe prog type is not a good fit.
It does? I don't remember returning 1 from KPROBE changing anything. I
thought it's only the special bpf_override_return() that can influence
the kernel function return result.
> Something like fentry/fexit may be better, since verifier check_return_code()
> enforces 'return 0'. So their return value is effectively "void".
> Then prog_test_run would need to gain an ability to trigger
> fentry/fexit prog on a given cpu.
next prev parent reply other threads:[~2020-08-05 17:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200801084721.1812607-1-songliubraving@fb.com>
[not found] ` <20200801084721.1812607-3-songliubraving@fb.com>
2020-08-03 1:40 ` [PATCH bpf-next 2/5] libbpf: support BPF_PROG_TYPE_USER programs Andrii Nakryiko
2020-08-03 4:21 ` Song Liu
2020-08-03 5:05 ` Andrii Nakryiko
2020-08-04 1:18 ` Song Liu
2020-08-05 1:38 ` Andrii Nakryiko
2020-08-05 3:59 ` Song Liu
2020-08-05 5:32 ` Andrii Nakryiko
2020-08-05 6:26 ` Song Liu
2020-08-05 6:54 ` Andrii Nakryiko
2020-08-05 7:23 ` Song Liu
2020-08-05 17:44 ` Andrii Nakryiko
[not found] ` <20200801084721.1812607-4-songliubraving@fb.com>
2020-08-03 1:43 ` [PATCH bpf-next 3/5] selftests/bpf: add selftest for BPF_PROG_TYPE_USER Andrii Nakryiko
2020-08-03 4:33 ` Song Liu
2020-08-03 5:07 ` Andrii Nakryiko
[not found] ` <20200801084721.1812607-5-songliubraving@fb.com>
2020-08-03 1:46 ` [PATCH bpf-next 4/5] selftests/bpf: move two functions to test_progs.c Andrii Nakryiko
2020-08-03 4:34 ` Song Liu
[not found] ` <20200801084721.1812607-6-songliubraving@fb.com>
2020-08-03 1:51 ` [PATCH bpf-next 5/5] selftests/bpf: add benchmark for uprobe vs. user_prog Andrii Nakryiko
2020-08-03 4:47 ` Song Liu
2020-08-03 5:10 ` Andrii Nakryiko
2020-08-04 20:54 ` Song Liu
2020-08-05 1:52 ` Andrii Nakryiko
2020-08-05 4:47 ` Song Liu
2020-08-05 5:47 ` Andrii Nakryiko
2020-08-05 7:01 ` Song Liu
2020-08-05 17:39 ` Andrii Nakryiko
2020-08-05 18:41 ` Song Liu
2020-08-05 17:16 ` Alexei Starovoitov
2020-08-05 17:27 ` Andrii Nakryiko [this message]
2020-08-05 17:45 ` Alexei Starovoitov
2020-08-05 17:56 ` Andrii Nakryiko
2020-08-05 18:56 ` Song Liu
2020-08-05 22:50 ` Alexei Starovoitov
2020-08-05 23:50 ` Song Liu
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='CAEf4BzYFfAubxo1QY6Axth=gwS9DfzwRkvnYLspfk9tLia0LPg@mail.gmail.com' \
--to=andrii.nakryiko@gmail.com \
--cc=Kernel-team@fb.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=dlxu@fb.com \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
/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;
as well as URLs for NNTP newsgroup(s).