All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	lorenzo.bianconi@redhat.com, "David Ahern" <dsahern@kernel.org>
Subject: Re: [PATCH v2 bpf-next 8/8] selftest: add tests for XDP programs in CPUMAP entries
Date: Mon, 22 Jun 2020 22:55:34 -0700	[thread overview]
Message-ID: <CAEf4BzbroU6o8yp=ca0JQqSS6WEZ9VQRcufq+T0vkCOoQsjB2w@mail.gmail.com> (raw)
In-Reply-To: <ebad39bb3d961a65733c33ed530b9d1ade916afa.1592606391.git.lorenzo@kernel.org>

On Fri, Jun 19, 2020 at 9:55 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> Similar to what have been done for DEVMAP, introduce tests to verify
> ability to add a XDP program to an entry in a CPUMAP.
> Verify CPUMAP programs can not be attached to devices as a normal
> XDP program, and only programs with BPF_XDP_CPUMAP attach type can
> be loaded in a CPUMAP.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
>  .../bpf/prog_tests/xdp_cpumap_attach.c        | 70 +++++++++++++++++++
>  .../bpf/progs/test_xdp_with_cpumap_helpers.c  | 38 ++++++++++
>  2 files changed, 108 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c
>  create mode 100644 tools/testing/selftests/bpf/progs/test_xdp_with_cpumap_helpers.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c b/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c
> new file mode 100644
> index 000000000000..2baa41689f40
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c
> @@ -0,0 +1,70 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <uapi/linux/bpf.h>
> +#include <linux/if_link.h>
> +#include <test_progs.h>
> +
> +#include "test_xdp_with_cpumap_helpers.skel.h"
> +
> +#define IFINDEX_LO     1
> +
> +void test_xdp_with_cpumap_helpers(void)
> +{
> +       struct test_xdp_with_cpumap_helpers *skel;
> +       struct bpf_prog_info info = {};
> +       struct bpf_cpumap_val val = {
> +               .qsize = 192,
> +       };
> +       __u32 duration = 0, idx = 0;
> +       __u32 len = sizeof(info);
> +       int err, prog_fd, map_fd;
> +
> +       skel = test_xdp_with_cpumap_helpers__open_and_load();
> +       if (CHECK_FAIL(!skel)) {
> +               perror("test_xdp_with_cpumap_helpers__open_and_load");
> +               return;
> +       }
> +
> +       /* can not attach program with cpumaps that allow programs
> +        * as xdp generic
> +        */
> +       prog_fd = bpf_program__fd(skel->progs.xdp_redir_prog);
> +       err = bpf_set_link_xdp_fd(IFINDEX_LO, prog_fd, XDP_FLAGS_SKB_MODE);
> +       CHECK(err == 0, "Generic attach of program with 8-byte CPUMAP",
> +             "should have failed\n");
> +
> +       prog_fd = bpf_program__fd(skel->progs.xdp_dummy_cm);
> +       map_fd = bpf_map__fd(skel->maps.cpu_map);
> +       err = bpf_obj_get_info_by_fd(prog_fd, &info, &len);
> +       if (CHECK_FAIL(err))
> +               goto out_close;
> +
> +       val.bpf_prog.fd = prog_fd;
> +       err = bpf_map_update_elem(map_fd, &idx, &val, 0);
> +       CHECK(err, "Add program to cpumap entry", "err %d errno %d\n",
> +             err, errno);
> +
> +       err = bpf_map_lookup_elem(map_fd, &idx, &val);
> +       CHECK(err, "Read cpumap entry", "err %d errno %d\n", err, errno);
> +       CHECK(info.id != val.bpf_prog.id, "Expected program id in cpumap entry",
> +             "expected %u read %u\n", info.id, val.bpf_prog.id);
> +
> +       /* can not attach BPF_XDP_CPUMAP program to a device */
> +       err = bpf_set_link_xdp_fd(IFINDEX_LO, prog_fd, XDP_FLAGS_SKB_MODE);
> +       CHECK(err == 0, "Attach of BPF_XDP_CPUMAP program",
> +             "should have failed\n");
> +
> +       val.qsize = 192;
> +       val.bpf_prog.fd = bpf_program__fd(skel->progs.xdp_dummy_prog);
> +       err = bpf_map_update_elem(map_fd, &idx, &val, 0);
> +       CHECK(err == 0, "Add non-BPF_XDP_CPUMAP program to cpumap entry",
> +             "should have failed\n");
> +
> +out_close:
> +       test_xdp_with_cpumap_helpers__destroy(skel);
> +}
> +
> +void test_xdp_cpumap_attach(void)
> +{
> +       if (test__start_subtest("CPUMAP with programs in entries"))

These subtest names are supposed to be short and follow test names
(i.e., being more or less valid C identifiers). It makes it easier to
select or blacklist them (with -t and -b params). So something like
cpumap_with_progs or similar would be better in that regard and would
make it easier for me to maintain a blacklist of tests/subtests for
Travis CI, for instance.

I think there is similarly verbose DEVMAP subtest name, I'd love it to
be "simplified" as well... But can't get my hands on everything,
unfortunately.

> +               test_xdp_with_cpumap_helpers();
> +}
> diff --git a/tools/testing/selftests/bpf/progs/test_xdp_with_cpumap_helpers.c b/tools/testing/selftests/bpf/progs/test_xdp_with_cpumap_helpers.c
> new file mode 100644
> index 000000000000..acbbc62efa55
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/test_xdp_with_cpumap_helpers.c
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +
> +struct {
> +       __uint(type, BPF_MAP_TYPE_CPUMAP);
> +       __uint(key_size, sizeof(__u32));
> +       __uint(value_size, sizeof(struct bpf_cpumap_val));
> +       __uint(max_entries, 4);
> +} cpu_map SEC(".maps");
> +
> +SEC("xdp_redir")
> +int xdp_redir_prog(struct xdp_md *ctx)
> +{
> +       return bpf_redirect_map(&cpu_map, 1, 0);
> +}
> +
> +SEC("xdp_dummy")
> +int xdp_dummy_prog(struct xdp_md *ctx)
> +{
> +       return XDP_PASS;
> +}
> +
> +SEC("xdp_cpumap")
> +int xdp_dummy_cm(struct xdp_md *ctx)
> +{
> +       char fmt[] = "devmap redirect: dev %u len %u\n";
> +       void *data_end = (void *)(long)ctx->data_end;
> +       void *data = (void *)(long)ctx->data;
> +       unsigned int len = data_end - data;
> +
> +       bpf_trace_printk(fmt, sizeof(fmt), ctx->ingress_ifindex, len);

Is there any reason to use bpf_trace_printk as opposed to saving
ctx->ingress_ifindex into a global variable? bpf_trace_printk isn't
really testing anything, just pollutes trace_pipe.

> +
> +       return XDP_PASS;
> +}
> +
> +char _license[] SEC("license") = "GPL";
> --
> 2.26.2
>

      reply	other threads:[~2020-06-23  5:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 22:57 [PATCH v2 bpf-next 0/8] introduce support for XDP programs in CPUMAP Lorenzo Bianconi
2020-06-19 22:57 ` [PATCH v2 bpf-next 1/8] net: Refactor xdp_convert_buff_to_frame Lorenzo Bianconi
2020-06-21 15:15   ` Jesper Dangaard Brouer
2020-06-22 11:48     ` Lorenzo Bianconi
2020-06-19 22:57 ` [PATCH v2 bpf-next 2/8] samples/bpf: xdp_redirect_cpu_user: do not update bpf maps in option loop Lorenzo Bianconi
2020-06-21 15:26   ` Jesper Dangaard Brouer
2020-06-19 22:57 ` [PATCH v2 bpf-next 3/8] cpumap: formalize map value as a named struct Lorenzo Bianconi
2020-06-22  9:33   ` Jesper Dangaard Brouer
2020-06-22 11:50     ` Lorenzo Bianconi
2020-06-19 22:57 ` [PATCH v2 bpf-next 4/8] bpf: cpumap: add the possibility to attach an eBPF program to cpumap Lorenzo Bianconi
2020-06-22  9:48   ` Jesper Dangaard Brouer
2020-06-23 14:56   ` Jesper Dangaard Brouer
2020-06-23 15:23   ` Jesper Dangaard Brouer
2020-06-19 22:57 ` [PATCH v2 bpf-next 5/8] bpf: cpumap: implement XDP_REDIRECT for eBPF programs attached to map entries Lorenzo Bianconi
2020-06-19 22:57 ` [PATCH v2 bpf-next 6/8] libbpf: add SEC name for xdp programs attached to CPUMAP Lorenzo Bianconi
2020-06-23  5:50   ` Andrii Nakryiko
2020-06-19 22:57 ` [PATCH v2 bpf-next 7/8] samples/bpf: xdp_redirect_cpu: load a eBPF program on cpumap Lorenzo Bianconi
2020-06-19 22:57 ` [PATCH v2 bpf-next 8/8] selftest: add tests for XDP programs in CPUMAP entries Lorenzo Bianconi
2020-06-23  5:55   ` Andrii Nakryiko [this message]

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='CAEf4BzbroU6o8yp=ca0JQqSS6WEZ9VQRcufq+T0vkCOoQsjB2w@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=toke@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.