Hi, Jiong, To follow up the iovisor meeting discussion, the below is my prototype for an end_loop instruction in llvm: https://github.com/yonghong-song/llvm/commit/b83226772100317092cae6478229ed6ca3b9

<palvarez=akamai.com@...> wrote: -O0 won't work as helper call will become an indirect call static void *(*bpf_map_lookup_elem)(void *map, void *key) = (void *) BPF_FUNC_map_lookup_elem;

#verifier

If you use BPF constructor debug=16 flag, it will print out the register state for every insn if you are even more curious. To resolve this issue, llvm may need to do more: - prevent/undo optimization

#verifier

Hi, Jiong, Thanks for your interest to help with this issue. You can reproduce with the code at https://github.com/sbernard31/udploadbalancer/tree/bf71e99fbd0c3f806a43076fc12a47e966422839 Using comman

#verifier

Maybe. I have not looked at this yet from compiler side. Sometimes you won't have an easy compiler option to turn off. Tuning -O may not help. Lowering -O to -O1/-O0 may help to remove this particular

#verifier

This is a tough issue. I spent a couple of hours trying various source workaround and did not succeed. To illustrate my experiment, the following is what I tried to do to move the code udp_len calcula

#verifier

<ys114321=gmail.com@...> wrote: The reason for the failure is due spill/reload does not preserve the original register state for scalar value. Look at the kernel function: static bool is

#verifier

I took a brief look. Indeed, it is very strange. I can see proper value of udp_len is stored into r10 - 40, but when it is retrieved later, the value became unkown.... I will try to experiment with th

#verifier

The be16 is to convert r3 with big endian encoding. If the host system is big endian, it will do nothing. Otherwise, it will convert from little endian to big endian. Yes, there is no documentation. I

#verifier

This is caused by compiler optimizations. r3 get the value from memory, its value could be any one as permitted by the type. test is done by r2. We indeed get better range for r2 (below: R2=inv(id=0,u

#verifier

You should be able to do the work with C as well. Just use APIs from libbpf.h, e.g., bpf_prog_get_next_id, bpf_prog_get_fd_by_id, bpf_map_get_fd_by_id. Yes, we may miss bpf_map_get_next_id and bpf_obj

In examples/cpp, we have UseExternalMap.cc, which gives an example of how to share maps between two processes with C++ interface. Basically, if you know the ID of the map in another application (you c

<mauricio.vasquez@...> wrote: There are some memory model discussion in the netdev mailing list. I think this shows bpf memory model is really tied to underlying arch indeed. Some kinds of lock

<mauricio.vasquez@...> wrote: not just cache line, you mean not in its naturally aligned boundary? One load/store is actually broken into multiple loads/stores by the compiler? So you mean both

It is not recommended to do delete() during get_next_key() loop. The delete() may change kernel internal hash table structure and get_next_key() may not function as expected. You can do one loop with

You can take a look at bcc/tests/cc/{test_array_table.cc, test_hash_table.cc, test_bpf_table.cc}. There are a few examples there testing percpu maps.

It should be as long as the total memory is less than 4GB (your table memory + some overhead for each table entry).

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

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

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