Is there anything that can go haywire if an eBPF map gets too big in an XDP program? I am looking into importing a large database of unique IPs (10,000-100,000) into a eBPF hash map in a XDP program

I want to messages from iovisor-dev@...

Can not now to compil my prog, to use bpf_get_mad_fd_by_id for just beggining, because dont know enough how to do it. To compile kern prog a lot of examples, but userspace prog can not find... Can you

This is exactly what `bpftool map` is doing. The source code https://github.com/torvalds/linux/blob/master/tools/bpf/bpftool/map.c You can find the map you are interested by iterating all the maps in

Can you give link or some code to understand, how can i get data from maps in c. I saw example, but as i begginer in such programming, i can understand map_fd, obj...etc. I create xdp prog, inserted

"Nic Viljoen" <nick.viljoen@...> wrote: Hint, do remember that you need to download a firmware that support eBPF from Netronome's homepage. But don't be scared it is painless to update/use

Yes currently i believe only Netronome NFP based Agilio CX NICs support xdpoffload.

If start() and stop() execute on two different cpus, their raw time may be backward since two different cpus mostly like have slightly different realtime clock numbers. Could you this be an issue for

29.11.2018, 07:07, "Y Song" <ys114321@...>: Thanks for your answer! I've tried to reproduce this with perf example from issue: perf record -F 9 --cpu 0 --clockid CLOCK_MONOTONIC -- sleep 1 But

<palvarez=akamai.com@...> wrote: Yes. bpf man page severely lags behind the current state. Yes, you can help make the change. linux-man mailing list is probably proper place to send

Good to know, thanks! There is no mention of the non-preemption in the bpf or tc-bpf man pages or the bcc tutorials. Is it possible to change that? I would be happy to add a note about this if

Maybe you want to check with bcc issue https://github.com/iovisor/bcc/issues/728. Basically there is a kernel bug related to bpf_ktime_get_ns() and it is fixed in 4.9. Not sure about your kernel

eBPF programs are never preempted by the kernel, this allows to keep counters in per_cpu maps without need to use synchronized primitives on them. This is also guaranteed that there is not preemption

The patch adds the test framework for OVS using afxdp. Most of the test cases are slightly modified from the existing test cases at system-traffic.at. All the veth creations, ADD_VETH, are replaced

There are still two issues causing some test cases failed. This patch provides an work-around. Signed-off-by: William Tu <u9012063@...> --- lib/dpif-netdev.c | 2 +-

The patch creates a new netdev type called "afxdp" and re-uses some of the AF_XDP API implementation from xdpsock_user.c at linux sample code. By default, it binds a device's queue 0 and uses the

The patch series introduces AF_XDP support for OVS netdev. AF_XDP is a new address family working together with eBPF. In short, a socket with AF_XDP family can receive and send packets from an

Thanks all for joining in to the call today. As usual, here are my notes. === Discussion === Jiong: Continuing work on jmp32 - some work on verifier side - needs to work on test support - new test

Dear eBPF community If I understand correctly, per_cpu maps are meant to avoid threading issues, and for example the need to call BPF_XADD to keep counters safe. There is something I am unclear

All LLVM versions ( >= 3.7.1) should work for x86, but to use some features like BPF debug=8 to dump the source embedded byte code, you need llvm 6.0 or later.