On 8/25/20 10:44 AM, Lorenz Bauer wrote:
Hi Yonghong,
I'm currently looking at adding support to iterate sockmap elements.
For that purpose, the context passed to the iterator program needs to
contain PTR_TO_SOCKET, like so:
.ctx_arg_info = {
{ offsetof(struct bpf_iter__bpf_map_elem, key),
PTR_TO_RDONLY_BUF_OR_NULL },
{ offsetof(struct bpf_iter__bpf_map_elem, value),
PTR_TO_SOCKET },
},
This is in contrast to PTR_TO_RDWR_BUF_OR_NULL. I think I could just
add a separate bpf_sockmap_elem iterator, but I'm guessing that this
is counter to how you would approach this. What do you think is the
best way to achieve this?
We already has a special case for bpf_sk_storage map which has
.ctx_arg_info = {
{ offsetof(struct bpf_iter__bpf_sk_storage_map, sk),
PTR_TO_BTF_ID_OR_NULL },
{ offsetof(struct bpf_iter__bpf_sk_storage_map, value),
PTR_TO_RDWR_BUF_OR_NULL },
},
In this case, the key is a sock pointer represented as a BTF_ID_OR_NULL.
This way, the bpf program is able to access all fields and do pointer
tracing in sock structure.
In your case, sockmap and sockhash should be able to share
the same bpf program signature (similar to hash map and array map
sharing the same). It is totally okay to define a different signature.
The general key/value as a buf signature won't work for bpf_sk_storage
either.
Maybe rename it to be bpf_iter__bpf_sockmap? For the value, there
are two ways for the type, one is BTF_ID_OR_NULL which is tracing style.
Another is PTR_TO_SOCKET_OR_NULL, which is networking style. I guess
you like it to be PTR_TO_SOCKET_OR_NULL since you want to do map_update
with that as a parameter. I guess this should work.
Best
Lorenz
