(repost with subscribed email) Hi All, I've added a section to my eBPF documentation, about how to read the eBPF generated ELF binary, and deduct the size of the compiled program (mostly for kernel/sa

Daniel Borkmann <daniel@...> wrote: Thanks for input, added: https://github.com/netoptimizer/prototype-kernel/commit/0b31532f42cd8

Jesper Dangaard Brouer via iovisor-dev <iovisor-dev@...> wrote: Added a section, so I/we will document this feature later: https://github.com/netoptimizer/prototype-kernel/commit/8cec9ce

Alexei Starovoitov via iovisor-dev <iovisor-dev@...> wrote: True, we don't want this doc to be come distro specific. I do believe we need to doc the history of LLVM to give users a chanc

Jesper Dangaard Brouer <brouer@...> wrote: Fixed: https://github.com/netoptimizer/prototype-kernel/commit/c5cf59ff9a9b https://prototype-kernel.readthedocs.io/en/latest/bpf/troubleshooting.html

Notice, there are two mailing lists (Cc'ed) that you should likely ask these kind of questions on (instead of netdev), depending on if this is mostly related to bpf (iovisor-dev@...) or

Adel Fuchs <adelfuchs@...> wrote: I assume you are doing: sudo cat /sys/kernel/debug/tracing/trace_pipe The problem could be that the kernel need to be compiled with the right trace config optio

The prototype-kernel github repo[1] is actually originally meant for developing real kernel module. I guess, I should/could have placed the eBPF/XDP examples[3] in another github repo. [1] https://git

Jesper Dangaard Brouer <brouer@...> wrote: Done, updated the documentation in the prototype-kernel github repo. See three top commits in this link: https://github.com/netoptimizer/prototype-ker

Jiong Wang <jiong.wang@...> wrote: I think you send this to the wrong mailing list... this looks like a patch against the LLVM source code. Shouldn't you send to: llvm-dev@... ? T

I'll redirect that question to William Tu (Cc'ed).

"Mr. Haritsu via iovisor-dev" <iovisor-dev@...> wrote: It is frustrating that people keeps hitting this, and cannot figure out what the issue is... This is because the kernel return EPER

That is a good idea. Try it out via perf-record to see if it contains what you need: $ perf record -e bpf:bpf_map_update_elem -a $ perf script xdp_redirect_ma 2273 [011] 261187.968223: bpf:bpf_map_upd

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

Daniel Borkmann <daniel@...> wrote: Just to be clear: notice as Victor points out[2], they are programmable going though the IOCTL (SIOCETHTOOL) and not using cmdline tools. [2] https://gith

Victor Julien <lists@...> wrote: The code for querying should not be too difficult. It would likely be similar to how we currently "set"/attach an XDP program, via its BPF file-descriptor to

Jakub Kicinski <jakub.kicinski@...> wrote: Let's keep thing separate. I'm requesting something really simple. I want the driver to tell me what XDP actions it supports. We/I can implement an

Daniel Borkmann <daniel@...> wrote: Okay, you want to catch this in dev_ethtool(), that connected the dots for me, thanks. BUT it does feel a little fake and confusing to do this, as the dri

(Cc. iovisor-dev list) Jesper Dangaard Brouer <brouer@...> wrote: 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. Thu

Sebastiano Miano via iovisor-dev <iovisor-dev@...> wrote: Argh, this is likely an issue/bug due to the check xdp_map_invalid(), that was introduced in commit 7c3001313396 ("bpf: fix ri->