Eric Dumazet <eric.dumazet@...> wrote: Sorry, I cannot resist. The GRO code is really bad regarding icache pressure/usage, due to how everything is function pointers calling function pointers, e

Hi Brenden, I don't quite understand the semantics of the XDP userspace interface. We allow XDP programs to be (unconditionally) exchanged by another program, this avoids taking the link down+up and a

Hi Brenden, I don't quite understand the semantics of the XDP userspace interface. We allow XDP programs to be (unconditionally) exchanged by another program, this avoids taking the link down+up and a

Hi all, As promised, I've started documenting the XDP eXpress Data Path): [1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html IMHO the documentation have reached a stage wh

Brenden Blanco <bblanco@...> wrote: For the record, I'm not happy with this response. IHMO the XDP userspace API should have been thought more through. Where is the specification and document

Alexei Starovoitov <alexei.starovoitov@...> wrote: I do see this as kernel documentation that eventually should end-up in Jon's doc tree. Right now it is too volatile. Once XDP have "stabilized"

Tom Herbert <tom@...> wrote: Yes, I fully agree. I want to state very clearly, this document is not an attempt to hijack the XDP project and control the "spec". This is an attempt to colla

I want to publicly thanks Edward Cree for being the first contributor to the XDP documentation with formulation and grammar fixes. Pulled and pushed: https://github.com/netoptimizer/prototype-kernel/c

Let me try in a calm way (not like [1]) to explain how I imagine that the XDP processing RX-stage should be implemented. As I've pointed out before[2], I'm proposing splitting up the driver into RX-st

The idea is quite different. It has nothing to do with Edward's proposal[3]. The RX packet-vector is simply an array, either of pointers or index numbers (into the RX-ring). The needed changes are com

Hi IOvisor-group, I'm playing with kernels samples/bpf, and want so advice on debugging eBPF programs. First question: I noticed bpf_trace_printk(), but nothing shows up when I'm using it... what did

Jesper Dangaard Brouer <brouer@...> wrote: (So, let me answer my own question.) The trace "printk" output goes into: /sys/kernel/debug/tracing/trace_pipe And samples/bpf have a function read_tr

Hi IOvisor/eBPF people, Do we have some documentation on eBPF maps? Like that map types are available, and what they are useful for? Notice, just list listing[1] the enum is not so useful: enum bpf_ma

Thanks! - this seem rather BCC specific syntax, and I'm looking for documentation close for the kernel (samples/bpf/). The best documentation I found was the man-page for the syscall bpf(2): http://ma

Alexei Starovoitov <alexei.starovoitov@...> wrote: Thanks, I'm using that to write some doc. http://prototype-kernel.readthedocs.io/en/latest/bpf/ebpf_maps.html Gotten to BPF_MAP_TYPE_ARRAY http

Jesper Dangaard Brouer <brouer@...> wrote: I documented this myself, please correct me. http://prototype-kernel.readthedocs.io/en/latest/bpf/ebpf_maps.html#creating-a-map http://prototype-kerne

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:

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

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