Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF land Y

Hi, I'm getting an "invalid indirect read from stack" when trying to run the following bcc script: paul$ cat tmp.py from bcc import BPF bpf_text = """ #include <uapi/linux/ptrace.h> #include <net/sock

Hello, My name is Usman. I am interested to contribute an example code for OpenStack VLAN traffic monitoring. Regarding this can you please guide me how I can submit my code on GitHub (Since I could n

Hi All, Thanks for joining the discussion today. As usual, here are my notes. -Brenden === Discussion === John: - sockmap fixes pushed - fixed broken tests - sockmap hash impl next - bounded loop rfc

Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF land Y

Hi, We're hitting a BPF verifier error saying "dereference of modified ctx ptr R1 off=36+0, ctx+const is allowed, ctx+const+const is not " but actually the 2nd const is 0. I don't know why compiler ge

Currently, helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. This patchset allows these helpers to directly access map values by passing register

Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. Allow these helpers to directly access map values by passing registers of type PTR_TO_MAP_VALUE

This patch adds new test cases for accesses to map values from map helpers. Signed-off-by: Paul Chaignon <paul.chaignon@...> --- tools/testing/selftests/bpf/test_verifier.c | 266 +++++++++++++++++++++

Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. Allow these helpers to directly access map values by passing registers of type PTR_TO_MAP_VALUE

This patch adds new test cases for accesses to map values from map helpers. Signed-off-by: Paul Chaignon <paul.chaignon@...> --- tools/testing/selftests/bpf/test_verifier.c | 266 +++++++++++++++++++++

Currently, helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. This patchset allows these helpers to directly access map values by passing register

Dear all I'm a student at Paris-VI Univercity and currently I'm working on a project involving eBPF with linux network stack ,and I need some guidence. If we attach the eBPF program to a kprobe ,and t

(Cc. iovisor-dev list) So, I figured out why this happens. What does bpftool use BFD for? I need the BFD lib and include file: /usr/include/bfd.h. Thus, on fedora I need to install package binutils-de

Hi All, Thanks for attending the meeting today. As usual, here are my notes. Cheers, Brenden === Discussion === Alexei - bpf-next queue is quite large, please have patience with delays in clearing the

Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF land Y

Hi Suricata people, When Eric Leblond (and I helped) integrated XDP in Suricata, we ran into the issue, that at Suricata load/start time, we cannot determine if the chosen XDP config options, like xdp

Dear developers, Is it a good idea to export kernel compression/decompression (lib/zlib_*, lib/lz*) as helper functions to enable corresponding use cases? Has this been tried before? Thanks, Ashish

I think if it would use the ioctl ETHTOOL interface it'd be easiest for us, as we already have code for this in place to check for offloading settings. See [1]. Do you have an example of how this is q

Extending the ethtools mechanism seems like a clean solution here. It is, by design, a 50% reporting tool and the XDP feature set would be just yet another feature here.