12 Oct, 2020

1 commit

  • To avoid confusion caused by the increasing fragmentation of the BPF
    Loader program, this commit would like to change to the libbpf loader
    instead of using the bpf_load.

    Thanks to libbpf's bpf_link interface, managing the tracepoint BPF
    program is much easier. bpf_program__attach_tracepoint manages the
    enable of tracepoint event and attach of BPF programs to it with a
    single interface bpf_link, so there is no need to manage event_fd and
    prog_fd separately.

    This commit refactors xdp_monitor with using this libbpf API, and the
    bpf_load is removed and migrated to libbpf.

    Signed-off-by: Daniel T. Lee
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20201010181734.1109-2-danieltimlee@gmail.com

    Daniel T. Lee
     

16 Jun, 2020

1 commit

  • Memset on the pointer right after malloc can cause a NULL pointer
    deference if it failed to allocate memory. A simple fix is to
    replace malloc()/memset() pair with a simple call to calloc().

    Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to xdp_rxq_info")
    Signed-off-by: Gaurav Singh
    Signed-off-by: Daniel Borkmann
    Acked-by: Jesper Dangaard Brouer
    Acked-by: John Fastabend

    Gaurav Singh
     

25 May, 2018

2 commits


15 May, 2018

2 commits


18 Apr, 2018

1 commit


20 Jan, 2018

1 commit

  • The xdp_redirect_cpu sample have some "builtin" monitoring of the
    tracepoints for xdp_cpumap_*, but it is practical to have an external
    tool that can monitor these transpoint as an easy way to troubleshoot
    an application using XDP + cpumap.

    Specifically I need such external tool when working on Suricata and
    XDP cpumap redirect. Extend the xdp_monitor tool sample with
    monitoring of these xdp_cpumap_* tracepoints. Model the output format
    like xdp_redirect_cpu.

    Given I needed to handle per CPU decoding for cpumap, this patch also
    add per CPU info on the existing monitor events. This resembles part
    of the builtin monitoring output from sample xdp_rxq_info. Thus, also
    covering part of that sample in an external monitoring tool.

    Performance wise, the cpumap tracepoints uses bulking, which cause
    them to have very little overhead. Thus, they are enabled by default.

    Signed-off-by: Jesper Dangaard Brouer
    Signed-off-by: Daniel Borkmann

    Jesper Dangaard Brouer
     

07 Oct, 2017

2 commits

  • Other concurrent running programs, like perf or the XDP program what
    needed to be monitored, might take up part of the max locked memory
    limit. Thus, the xdp_monitor tool have to set the RLIMIT_MEMLOCK to
    RLIM_INFINITY, as it cannot determine a more sane limit.

    Using the man exit(3) specified EXIT_FAILURE return exit code, and
    correct other users too.

    Signed-off-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Jesper Dangaard Brouer
     
  • Also monitor the tracepoint xdp_exception. This tracepoint is usually
    invoked by the drivers. Programs themselves can activate this by
    returning XDP_ABORTED, which will drop the packet but also trigger the
    tracepoint. This is useful for distinguishing intentional (XDP_DROP)
    vs. ebpf-program error cases that cased a drop (XDP_ABORTED).

    Drivers also use this tracepoint for reporting on XDP actions that are
    unknown to the specific driver. This can help the user to detect if a
    driver e.g. doesn't implement XDP_REDIRECT yet.

    Signed-off-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Jesper Dangaard Brouer
     

02 Oct, 2017

1 commit

  • Make local functions static to fix

    HOSTCC samples/bpf/xdp_monitor_user.o
    samples/bpf/xdp_monitor_user.c:64:7: warning: no previous prototype for ‘gettime’ [-Wmissing-prototypes]
    __u64 gettime(void)
    ^~~~~~~
    samples/bpf/xdp_monitor_user.c:209:6: warning: no previous prototype for ‘print_bpf_prog_info’ [-Wmissing-prototypes]
    void print_bpf_prog_info(void)
    ^~~~~~~~~~~~~~~~~~~
    Fixes: 3ffab5460264 ("samples/bpf: xdp_monitor tool based on tracepoints")
    Signed-off-by: Stephen Hemminger
    Acked-by: Alexei Starovoitov
    Acked-by: Jesper Dangaard Brouer
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

30 Aug, 2017

1 commit

  • This tool xdp_monitor demonstrate how to use the different xdp_redirect
    tracepoints xdp_redirect{,_map}{,_err} from a BPF program.

    The default mode is to only monitor the error counters, to avoid
    affecting the per packet performance. Tracepoints comes with a base
    overhead of 25 nanosec for an attached bpf_prog, and 48 nanosec for
    using a full perf record (with non-matching filter). Thus, default
    loading the --stats mode could affect the maximum performance.

    This version of the tool is very simple and count all types of errors
    as one. It will be natural to extend this later with the different
    types of errors that can occur, which should help users quickly
    identify common mistakes.

    Because the TP_STRUCT was kept in sync all the tracepoints loads the
    same BPF code. It would also be natural to extend the map version to
    demonstrate how the map information could be used.

    Signed-off-by: Jesper Dangaard Brouer
    Acked-by: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Jesper Dangaard Brouer