and current bcc won't be > pass to parse it since it takes the file name as > "jna9005484735610534564.tmp (deleted)" > The file name is actually taken from /proc/<pid>/maps. > > I

and current bcc won't be pass to parse it since it takes the file name as "jna9005484735610534564.tmp (deleted)" The file name is actually taken from /proc/<pid>/maps.

and current bcc won't be pass to parse it since it takes the file name as "jna9005484735610534564.tmp (deleted)" The file name is actually taken from /proc/<pid>/maps.

Currently debugging a very strange behaviour with eBPF hash maps and was wondering if anyone else has run into a similar issue?

; const char *filename; long flags; long mode; }; /** * Using the magic macro SEC this struct declares * and creates a new bpf map of a type PERF that we * can use to pass data to userspace

p=,,,20,0,0,0::Created,,Userspace+Maps,20,2,0,23673879 that discusses the possibility of this in C++ and BCC.

I have attempted pinning the entire BPF object, various programs and various maps, and no matter what I've tried the kernel BPF program terminates when the userspace process terminates

Finally, for long-term monitoring solutions and passing readable data, do most programs rely on pinning maps to the vfs instead of using perf buffers or passing directly to a userspace

map defined: struct bpf_map_def SEC("maps/protocount") proto_count = { .type = BPF_MAP_TYPE_PERCPU_ARRAY, .key_size = sizeof(__u32), .value_size = sizeof(__u32), .max_entries = 1, }

* No silver bullet for all use cases * Hesitation for creating a new object to describe existing objects (bpf progs, maps) * BTF is metadata conceptually different from maps, progs

maps.h +++ b/bpf/maps.h @@ -153,6 +153,18 @@ BPF_PERCPU_ARRAY(percpu_executing_key, 1 ); +/* af_xdp map: + * key can be anything by our design, + * value is the receive queue id the userspace

maps.h +++ b/bpf/maps.h @@ -153,6 +153,18 @@ BPF_PERCPU_ARRAY(percpu_executing_key, 1 ); +/* af_xdp map: + * key can be anything by our design, + * value is the receive queue id the userspace

AF_XDP packet forwarding from one netdev (ovs-p0) to another netdev (ovs-p1) goes through the following path: 1) xdp program at ovs-p0 copies packet to kernel (SKB_MODE) 2) kernel maps

Facebook has used the same mechanism for a while to access externally-pinned maps. bpf_obj_get() intends to be used in userspace, not kernel.

return ___constant_swab64((OVS_FORCE u64)x); +} + +static ovs_be64 bpf_htonll(u64 x) { + return (OVS_FORCE ovs_be64)___constant_swab64(x); +} + +/* helper macro to place programs, maps

It enables userspace applications to customize and extend the Linux kernel’s functionality.

+ +#ifndef BPFMAP_OPENVSWITCH_H +#define BPFMAP_OPENVSWITCH_H 1 + +#include "api.h" +#include "openvswitch.h" +#include "ovs-p4.h" + +/* ovs-vswitchd as a writer will update these maps

It enables userspace applications to customize and extend the Linux kernel’s functionality.

to bpf tail calls and maps used as return values).

- Same problem for maps - Include offload check at load time instead - New system call for "BPF_PROG_PREPARE", in between load and offload - jit a loaded bpf prog for a specific arch