netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Eric Sage <eric@sage.org>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>,
	Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andriin@fb.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	john fastabend <john.fastabend@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH] samples/bpf: Add xdp_stat sample program
Date: Fri, 10 Jan 2020 12:53:21 -0800	[thread overview]
Message-ID: <CAEf4BzbGvmy97q4RMyBSdK0zAyyCfkZaz5-ZZbTb18DX0vCcGQ@mail.gmail.com> (raw)
In-Reply-To: <20191229225103.311569-1-eric@sage.org>

On Sun, Dec 29, 2019 at 2:51 PM Eric Sage <eric@sage.org> wrote:
>
> At Facebook we use tail calls to jump between our firewall filters and
> our L4LB. This is a program I wrote to estimate per program performance
> by swapping out the entries in the program array with interceptors that
> take measurements and then jump to the original entries.
>
> I found the sample programs to be invaluable in understanding how to use
> the libbpf API (as well as the test env from the xdp-tutorial repo for
> testing), and want to return the favor. I am currently working on
> my next iteration that uses fentry/fexit to be less invasive,
> but I thought it was an interesting PoC of what you can do with program
> arrays.
>
> Signed-off-by: Eric Sage <eric@sage.org>
> ---

Hey Eric,

Thanks for contributing this to samples. Ideally this would use BPF
skeleton to simplify all the map and program look ups, but given
samples/bpf doesn't have a infrastructure set up for this, it might be
a bit too much effort at this point. So I think it's ok to do it this
way, even though it would be really nice to try.

But please update the old-style bpf_map_def to BTF-defined maps before
this gets merged (see below).

>  samples/bpf/Makefile          |   3 +
>  samples/bpf/xdp_stat_common.h |  28 ++
>  samples/bpf/xdp_stat_kern.c   | 169 ++++++++
>  samples/bpf/xdp_stat_user.c   | 746 ++++++++++++++++++++++++++++++++++
>  4 files changed, 946 insertions(+)
>  create mode 100644 samples/bpf/xdp_stat_common.h
>  create mode 100644 samples/bpf/xdp_stat_kern.c
>  create mode 100644 samples/bpf/xdp_stat_user.c
>

[...]

> +#include <uapi/linux/bpf.h>
> +#include "bpf_helpers.h"
> +
> +#include "xdp_stat_common.h"
> +
> +#define MAX_PROG_ARRAY 64
> +
> +/* NR is used to map interceptors to the programs that are being intercepted. */
> +#define INTERCEPTOR(INDEX)                                                     \
> +       SEC("xdp/interceptor_" #INDEX)                                         \
> +       int interceptor_##INDEX(struct xdp_md *ctx)                            \
> +       {                                                                      \
> +               return interceptor_impl(ctx, INDEX);                           \
> +       }
> +
> +       /* Required to use bpf_ktime_get_ns() */
> +       char _license[] SEC("license") = "GPL";

Wrong indentation?

> +
> +/* interception_info holds a single record per CPU to pass global state between
> + * interceptor programs.
> + */
> +struct bpf_map_def SEC("maps") interception_info = {
> +       .type = BPF_MAP_TYPE_PERCPU_ARRAY,
> +       .key_size = sizeof(__u32),
> +       .value_size = sizeof(struct interception_info_rec),
> +       .max_entries = 1,
> +};

With BTF-define maps this would be

struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 1);
    __type(key, __u32);
    __type(value, struct interception_info_rec);
} interception_info SEC(".maps");

Can you please switch all the maps to this new syntax?

> +
> +/* interceptor_stats maps interceptor indexes to measurements of an intercepted
> + * BPF program. Index 0 maps the interceptor entrypoint to measurements of the
> + * original entrypoint.
> + */
> +struct bpf_map_def SEC("maps") prog_stats = {
> +       .type = BPF_MAP_TYPE_PERCPU_ARRAY,
> +       .key_size = sizeof(__u32),
> +       .value_size = sizeof(struct prog_stats_rec),
> +       .max_entries = MAX_PROG_ARRAY,
> +};
> +

[...]

> +static struct intercept_ctx *intercept__setup(char *mappath, int ifindex)
> +{
> +       struct intercept_ctx *ctx = malloc(sizeof(struct intercept_ctx));
> +
> +       ctx->ifindex = ifindex;
> +
> +       ctx->stats_enabled_oldval =
> +               _update_sysctl("/proc/sys/kernel/bpf_stats_enabled", 1);
> +       if (ctx->stats_enabled_oldval < 0)
> +               perror("ERR: set bpf_stats_enabled sysctl failed\n");
> +
> +       if (bpf_prog_load(FILENAME_XDP_STAT_KERN, BPF_PROG_TYPE_XDP,
> +                         &ctx->bpf_obj, &ctx->entry_fd)) {

bpf_object__open() + bpf_object__load() is preferred over
bpf_prog_load() way to open and load BPF object files, would be nice
to use that instead.

Alternative is BPF skeleton, but as I said, it will require a bit more
set up in Makefile (you'd need to generate skeleton with `bpftool gen
skeleton <your-bpf-object>.o`). Few benefits of BPF skeleton, though:
  - you wouldn't need to look up maps and programs by name, they would
be accessible as struct fields of skeleton (e.g.,
skel->maps.interception_info);
  - BPF object file would be embedded into userspace program, so when
distributing this you wouldn't need to drag along a separate .o file.


> +               fprintf(stderr, "ERR: failed to load %s\n",
> +                       FILENAME_XDP_STAT_KERN);
> +               return NULL;
> +       }
> +

[...]

  reply	other threads:[~2020-01-10 20:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-29 22:51 [PATCH] samples/bpf: Add xdp_stat sample program Eric Sage
2020-01-10 20:53 ` Andrii Nakryiko [this message]
2020-01-12  4:02 ` [PATCH v2] " Eric Sage
2020-01-13 20:35   ` Andrii Nakryiko
2020-01-29  3:54     ` [PATCH v3] " Eric Sage
2020-01-30 18:52       ` Andrii Nakryiko
2020-02-17 15:22       ` Daniel Borkmann

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=CAEf4BzbGvmy97q4RMyBSdK0zAyyCfkZaz5-ZZbTb18DX0vCcGQ@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eric@sage.org \
    --cc=hawk@kernel.org \
    --cc=jakub.kicinski@netronome.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=yhs@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).