iovisor-dev@lists.iovisor.org

Home Messages Hashtags Subgroups

This group is locked. No changes can be made to the group while it is locked.

Messages

Between

and

Re: Building BPF programs and kernel persistence

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

By Tristan Mayfield · #1851 ·

Re: eBPF map - Control and Data plane concurrency #bcc

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]

By Andrii Nakryiko · #1850 ·

Re: Building BPF programs and kernel persistence

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

By Andrii Nakryiko · #1849 ·

Re: eBPF map - Control and Data plane concurrency #bcc

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

By Simone Magnani · #1848 ·

Building BPF programs and kernel persistence

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

By Tristan Mayfield · #1847 ·

Re: eBPF map - Control and Data plane concurrency #bcc

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.

By Yonghong Song · #1846 ·

eBPF map - Control and Data plane concurrency #bcc

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

By Simone Magnani · #1845 ·

Re: #bcc - skb_network_header crashes in a BPF Kernel trace function #bcc

<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

By Yonghong Song · #1844 ·

Re: #bcc - skb_network_header crashes in a BPF Kernel trace function #bcc

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.

By Yonghong Song · #1843 ·

#bcc - skb_network_header crashes in a BPF Kernel trace function #bcc

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

By vigs.prof@... · #1842 ·

Seeking candidates for PhD position related to XDP/eBPF

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,

By Jesper Dangaard Brouer · #1841 ·

Re: Extracting data from tracepoints (and anything else)

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

By Andrii Nakryiko · #1840 ·

Re: Extracting data from tracepoints (and anything else)

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

By Tristan Mayfield · #1839 ·

Re: Extracting data from tracepoints (and anything else)

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

By Andrii Nakryiko · #1838 ·

Re: Extracting data from tracepoints (and anything else)

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

By Andrii Nakryiko · #1837 ·

Re: Extracting data from tracepoints (and anything else)

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

By Tristan Mayfield · #1836 ·

Re: Extracting data from tracepoints (and anything else)

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). >

By Andrii Nakryiko · #1835 ·

Re: Extracting data from tracepoints (and anything else)

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.

By Tristan Mayfield · #1834 ·

Re: Extracting data from tracepoints (and anything else)

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

By Andrii Nakryiko · #1833 ·

Re: Extracting data from tracepoints (and anything else)

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

By Tristan Mayfield · #1832 ·

181 - 200 of 2029

Home Hashtags Subgroups Terms