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

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

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

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

"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

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

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

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

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

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

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

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

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

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

(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

Alexei Starovoitov <alexei.starovoitov@...> wrote: Okay, understood. I did see locks in the hash map code, but I've not documented that map type yet. I've completely rewritten the section: "Inte

Alexei Starovoitov <alexei.starovoitov@...> wrote: [...] [...] Looking at the memcpy code in array_map_update_elem(), I don't see anything preventing two processes from data-update racing with e

Alexei Starovoitov <alexei.starovoitov@...> wrote: Good idea, but I'll take this round of review first, before pushing it to the kernel tree. I also want a build-env section. Also considering sp

Brendan Gregg <brendan.d.gregg@...> wrote: Hi Brendan, I also included BCC in my documentation, please correct me: http://prototype-kernel.readthedocs.io/en/latest/bpf/bcc_tool_chain.html https: