Hi Jesper and Quentin, Nice, I checked that logic. If I understand it right, that implementation would also need few operations to be atomic, for example the window movements(whenever R and B are

Thanks Andrii. __sync_fetch_and_add doesn't seem to work as expected, it is adding the increment, but it is returning the wrong value. I am actually hitting the same issue mentioned here:

2020-06-16 14:18 UTC+0200 ~ Jesper Dangaard Brouer <brouer@...> Hi Jesper, Kanthi, This token bucket implementation was realised in the context of a research project (BEBA), for which the OPP

Hi Kanthi and Quentin, You mention token counter as the use-case, for somehow ratelimiting (TCP connections in your case?). That reminds me that Quentin implemented[1] a two-color

You should use __sync_fetch_and_add() for both cases, and then yes, you won't lose any update. You probably would want __sync_add_and_fetch() to get the counter after update, but that's not supported

Thanks Song and Andrii for the response. Use-case is global rate-limiting for incoming TCP connections. And we want to implement the token bucket algorithm using XDP for this purpose. So we are

Replying here again for the record since you posted the same question on the k8s slack. Kubectl trace replaces $container_pid so you can access the pid folder in the host proc. it’s not specific

Ok, that I can help with, then. What's the kernel version? Where I can find repro? Steps, etc. Basically, a bit more context would help, as I wasn't part of initial discussion.

<andrii.nakryiko@...> wrote: just running ./test_xdp_veth.sh on the latest bpf-next with the latest clang I see: BTF debug data section '.BTF' rejected: Invalid argument (22)! - Length:

<brouer@...> wrote: This is newer Clang recording that function is global, not static. libbpf is sanitizing BTF to remove this flag, if kernel doesn't support this. But given this is

(Cross-posting to iovisor-dev) Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 fixes the issue ? -- Best

Hello all, I am trying to retrieve the keys of an LPM Trie in my user space program (similar to https://github.com/iovisor/bcc/blob/master/examples/networking/xdp/xdp_macswap_count.py) however, I am

Stating that spin locks are costly without empirical data seems premature. What's the scenario? What's the number of CPUs? What's the level of contention? Under light contention, spin locks in

BPF_XADD is to make one map element inside the kenel to update atomically. Could you filx an issue with more details? This way, we will have a better record. Not sure what do you mean here. yes, one

Could you file a separate issue so it is easy for people to help? Do you have a minimum reproducible test case? This will make it easy to debug. application without pid should work. A test case will

Hello, I am trying to introduce USDT probe to an application and my bcc script is failing with following error: <snip> Traceback (most recent call last): File "test.py", line 40, in <module>

Hi, I’ve been reading that hash map’s update element is atomic and also that we can use BPF_XADD to make the entire map update atomically. But I think that doesn’t guarantee that these updates

<mayfieldtristan@...> wrote: BTW, everyone seems to be using -O2 for compiling BPF programs. Not sure how well-supported -O3 will be. [...] "classic BPF" is entirely different thing, don't use

Thanks for the reply Andrii. Managed to get a build working outside of the kernel tree for BPF programs. The two major things that I learned were that first, the order in which files are included in

No, HASH_OF_MAPS allows arbitrary-sized keys, just like normal HASHMAP. Libbpf recently got a support for nicer map-in-map declaration and initialization, you might want to check it out: [0]. [0]