Thanks for the reply Andrii. Managed to get a build working outside of the kernel tree for BPF programs. The two major things that I learned were that first, the order in which files are included in

No, HASH_OF_MAPS allows arbitrary-sized keys, just like normal HASHMAP. Libbpf recently got a support for nicer map-in-map declaration and initialization, you might want to check it out: [0]. [0]

Hi! For the future, I think cc'ing bpf@... would be a good idea, there are a lot of folks who are probably not watching iovisor mailing list, but could help with issues like this. I'd

Thanks for the suggestion, now I feel more confident about this solution. However, I have still problems with the map-in-map type: is it possible to use a map which has as key the 4 tcp-session

Hi all, hope everyone is staying healthy out there. I've been working on building BPF programs, and have run into a few issues that I think might be clang (vs gcc) based. It seems that either clang

Your approach seems okay. You can use two maps or use map-in-map. Using batch operation from user space should speedup the deletion operation.

Hi everybody, I am writing this email to ask for an opinion about how to address the following problem. Lately, I have been trying to develop an eBPF program that extracts some per-flow values and

<ys114321=gmail.com@...> wrote: I see the issue now. ip_hdr(skb) eventually transforms to static inline unsigned char *skb_network_header(const struct sk_buff *skb) { return

You did not show the code which actually caused the problem. There must be code after "if ( (ip_Hdr.protocol != IPPROTO_TCP)) return 0;" . You may need bpf_probe_read() for memory accesses there.

Hello - I am looking to trace ip_forward_finish. The intent is to trace latency of all TCP connections going through a linux based gateway router. Hence thought of tracing ip_forward_finish kernel

Hi Potential PhD student, Reminder: Application deadline 15.May 2020 is really soon for our PhD position located in Sweden, at Karlstads University. See: "PhD position in Computer Science,

You are not really accessing CPU registers, but you access their values before the program was interrupted. Those values are stored in pt_regs struct. It's a technicality in this case, but you can't

I've waited to reply, not wanting to clog the mailing list, but I thought it would be beneficial to follow up on the same topic with kprobes in addition to tracepoints. The main issue I had with

adding back mailing list Notice offsets, they are all (except for first 4 fields which fit in first 8 bytes) 8-byte aligned. You can do that in your struct definitions as: int __syscall_nr

Just answered on another Github issue (https://github.com/iovisor/bcc/issues/2855#issuecomment-609532793), please check it there as well. Short answer: no. Unless you can pretty much guarantee that it

I've spent a few days trying to solve this issue I've had, and I've learned a lot about both the past BPF APIs, and the new CO-RE API. I do have a couple questions though. Once a CO-RE program is

Yes. A lot of newer functionality relies on kernel BTF as well. But to compile portable BPF program you also need kernel BTF (for BPF CO-RE stuff). >

Will do. Does this mean that, going forward, BPF development will be encouraged to use kernels compiled with "CONFIG_DEBUG_INFO_BTF=y"? I've been using a default build up to now.

Take a closer look. libbpf-tools do not use bpf_load.h, that one is deprecated and its use is discouraged. libbpf-tools rely on code-generated BPF skeleton. But really, get a close look

I found out that the cloned the kernel tree from the Ubuntu repo (i.e. "git clone --depth 1 git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git") for Bionic was the issue. For some reason it doesn't have