From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Wang Nan <wangnan0@huawei.com>
Cc: jolsa@redhat.com, brendan.d.gregg@gmail.com,
linux-kernel@vger.kernel.org, pi3orama@163.com,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Alexei Starovoitov <ast@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Li Zefan <lizefan@huawei.com>
Subject: Re: [RFC PATCH 06/13] bpf tools: Introduce ubpf_vm to program instance union
Date: Wed, 20 Apr 2016 16:30:43 -0300 [thread overview]
Message-ID: <20160420193043.GV3677@kernel.org> (raw)
In-Reply-To: <1461175313-38310-7-git-send-email-wangnan0@huawei.com>
Em Wed, Apr 20, 2016 at 06:01:46PM +0000, Wang Nan escreveu:
> Add 'struct ubpf_vm *' into prog_instance union. Introduce if_engine()
> macro to merge common code.
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Li Zefan <lizefan@huawei.com>
> ---
> tools/lib/bpf/libbpf.c | 76 ++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 68 insertions(+), 8 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 3755846..3a969fd 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -141,6 +141,9 @@ int libbpf_strerror(int err, char *buf, size_t size)
>
> union prog_instance {
> int fd;
> +#ifdef HAVE_UBPF_SUPPORT
> + struct ubpf_vm *vm;
> +#endif
> };
>
> /*
> @@ -176,6 +179,56 @@ struct bpf_program {
> bpf_program_clear_priv_t clear_priv;
> };
>
> +#ifdef HAVE_UBPF_SUPPORT
> +# define __if_engine(p, d, k, u) \
> + do { \
> + switch (p->engine) { \
> + default: \
> + case ENGINE_UNKNOWN: { \
> + d; \
> + } \
> + case ENGINE_KBPF: { \
> + k; break; \
> + } \
> + case ENGINE_UBPF: { \
> + u; break; \
> + } \
> + } \
> + } while(0)
These macro tricks are getting unecessarily overly complicated :-\
> +
> +/*
> + * ubpf_destroy() doesn't accept NULL input. This wrapper makes
> + * it similar to zclose.
> + */
> +# define __ubpf_destroy(vm) do { \
> + if (vm) \
> + ubpf_destroy(vm); \
> + (vm) = NULL; \
> +} while(0)
> +
> +#else
> +# define __if_engine(p, d, k, u) \
> + do { k; } while(0)
> +#endif
Why use just one letter parameters, give them proper names
> +
> +#define instan_fd(i) instances.array[i].fd
> +#define instan_vm(i) instances.array[i].vm
> +
> +#define if_engine(p, k, u) __if_engine(p, do { } while(0), k, u)
> +#define set_instance(p, i, k, u) \
> + if_engine(p, \
> + p->instan_fd(i) = k, \
> + p->instan_vm(i) = u)
If you had used a void pointer for instances->entries you wouldn't have
to play such tricks, right?
> +
> +static inline void init_instance_array(struct bpf_program *prog)
> +{
> + size_t size = sizeof(prog->instances.array[0]) * prog->instances.nr;
> +
> + if_engine(prog,
> + memset(prog->instances.array, -1, size),
> + memset(prog->instances.array, 0, size));
> +}
> +
> struct bpf_map {
> int fd;
> char *name;
> @@ -239,7 +292,9 @@ static void bpf_program__unload(struct bpf_program *prog)
> */
> if (prog->instances.nr > 0) {
> for (i = 0; i < prog->instances.nr; i++)
> - zclose(prog->instances.array[i].fd);
> + if_engine(prog,
> + zclose(prog->instan_fd(i)),
> + __ubpf_destroy(prog->instan_vm(i)));
So if we have more types of instances this will become a
switch_engine()?
> } else if (prog->instances.nr != -1) {
> pr_warning("Internal error: instances.nr is %d\n",
> prog->instances.nr);
> @@ -966,7 +1021,7 @@ bpf_program__load(struct bpf_program *prog,
> return -ENOMEM;
> }
> prog->instances.nr = 1;
> - prog->instances.array[0].fd = -1;
> + set_instance(prog, 0, -1, NULL);
And here we would go on adding more and more values? Why not have some
struct bpf_engine {
void (*init)(struct bpf_program *prog);
void (*fini)(struct bpf_program *prog);
}
One for the kernel "engine", the other for the userspace one?
> }
>
> if (!prog->preprocessor) {
> @@ -977,7 +1032,7 @@ bpf_program__load(struct bpf_program *prog,
> err = load_program(prog->insns, prog->insns_cnt,
> license, kern_version, &fd);
> if (!err)
> - prog->instances.array[0].fd = fd;
> + prog->instan_fd(0) = fd;
> goto out;
> }
>
> @@ -997,7 +1052,7 @@ bpf_program__load(struct bpf_program *prog,
> if (!result.new_insn_ptr || !result.new_insn_cnt) {
> pr_debug("Skip loading the %dth instance of program '%s'\n",
> i, prog->section_name);
> - prog->instances.array[i].fd = -1;
> + prog->instan_fd(i) = -1;
> if (result.pfd)
> *result.pfd = -1;
> continue;
> @@ -1015,7 +1070,7 @@ bpf_program__load(struct bpf_program *prog,
>
> if (result.pfd)
> *result.pfd = fd;
> - prog->instances.array[i].fd = fd;
> + prog->instan_fd(i) = fd;
> }
> out:
> if (err)
> @@ -1301,12 +1356,11 @@ int bpf_program__set_prep(struct bpf_program *prog, int nr_instances,
> return -ENOMEM;
> }
>
> - /* fill all fd with -1 */
> - memset(array, -1, sizeof(array[0]) * nr_instances);
> -
> prog->instances.nr = nr_instances;
> prog->instances.array = array;
> prog->preprocessor = prep;
> +
> + init_instance_array(prog);
> return 0;
> }
>
> @@ -1314,6 +1368,12 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n)
> {
> int fd;
>
> + if (prog->engine != ENGINE_KBPF) {
> + pr_warning("Can't get fd from program %s: engine not KBPF or not loaded\n",
> + prog->section_name);
> + return -EINVAL;
> + }
> +
> if (n >= prog->instances.nr || n < 0) {
> pr_warning("Can't get the %dth fd from program %s: only %d instances\n",
> n, prog->section_name, prog->instances.nr);
> --
> 1.8.3.4
next prev parent reply other threads:[~2016-04-20 19:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 18:01 [RFC PATCH 00/13] perf tools: Support uBPF script Wang Nan
2016-04-20 18:01 ` [RFC PATCH 01/13] bpf tools: Add map related BPF helper Wang Nan
2016-04-20 18:01 ` [RFC PATCH 02/13] tools: Add ubpf feature test Wang Nan
2016-04-20 19:11 ` Arnaldo Carvalho de Melo
2016-04-20 18:01 ` [RFC PATCH 03/13] bpf tools: Add ubpf include and makefile options Wang Nan
2016-04-20 18:01 ` [RFC PATCH 04/13] bpf tools: Replace fd array to union array Wang Nan
2016-04-20 19:20 ` Arnaldo Carvalho de Melo
2016-04-20 18:01 ` [RFC PATCH 05/13] bpf tools: Save engine type in bpf_program Wang Nan
2016-04-20 19:23 ` Arnaldo Carvalho de Melo
2016-04-20 19:29 ` pi3orama
2016-04-20 18:01 ` [RFC PATCH 06/13] bpf tools: Introduce ubpf_vm to program instance union Wang Nan
2016-04-20 19:30 ` Arnaldo Carvalho de Melo [this message]
2016-04-20 18:01 ` [RFC PATCH 07/13] bpf tools: Load ubpf program Wang Nan
2016-04-20 19:34 ` Arnaldo Carvalho de Melo
2016-04-20 18:01 ` [RFC PATCH 08/13] bpf tools: Add API for fetching ubpf_vm Wang Nan
2016-04-20 18:01 ` [RFC PATCH 09/13] bpf tools: Register extern functions for ubpf programs Wang Nan
2016-04-20 18:01 ` [RFC PATCH 10/13] perf tools: Register basic UBPF helpers Wang Nan
2016-04-20 18:01 ` [RFC PATCH 11/13] perf bpf: Accept ubpf programs Wang Nan
2016-04-20 18:01 ` [RFC PATCH 12/13] perf record: Add UBPF hooks at beginning and end of perf record Wang Nan
2016-04-20 18:01 ` [RFC PATCH 13/13] perf tests: Add UBPF test case Wang Nan
2016-04-20 22:06 ` [RFC PATCH 00/13] perf tools: Support uBPF script Alexei Starovoitov
2016-04-21 8:17 ` Wangnan (F)
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=20160420193043.GV3677@kernel.org \
--to=acme@kernel.org \
--cc=acme@redhat.com \
--cc=ast@kernel.org \
--cc=brendan.d.gregg@gmail.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=pi3orama@163.com \
--cc=wangnan0@huawei.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).