fix(bpf): added function supported by arm64 #5
Conversation
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
bpf/mb_netns_cleanup.bpf.c
Outdated
| @@ -36,7 +36,12 @@ struct { | |||
| __uint(pinning, LIBBPF_PIN_BY_NAME); | |||
| } local_pod_ips SEC(".maps"); | |||
|
|
|||
| // arm64 doesn't support fexit/fenter | |||
There was a problem hiding this comment.
Can you maybe add a link to explain why kretprobe is the right substitute?
bpf/mb_netns_cleanup.bpf.c
Outdated
| SEC("fexit/net_ns_net_exit") | ||
| #endif | ||
| int BPF_PROG(net_ns_net_exit, struct net *net, long ret) |
There was a problem hiding this comment.
Probably for kprobe we need to change the type and parameters to BPF_KPROBE(net_ns_net_exit, struct net *net)
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
instead of cleaning by ourself we can use LRU_HASH map that after reaching max size the oldest element is removed Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
| __uint(type, BPF_MAP_TYPE_HASH); | ||
| __uint(max_entries, 1024); | ||
| __uint(type, BPF_MAP_TYPE_LRU_HASH); | ||
| __uint(max_entries, 65535); |
There was a problem hiding this comment.
Might be worth saying where this number is coming from
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
| // run 65535 unique pods, and if new one appears | ||
| // the oldest not accessed entry is going to be | ||
| // removed from the map by the kernel. This ensure | ||
| // that configuration of living pod is removed. |
There was a problem hiding this comment.
Random question could there be a problem with a pod receiving 0 traffic?
There was a problem hiding this comment.
Shouldn't be, if pod doesn't receive traffic the only situation in which it might be removed is when we deploy > 65535 pods in the cluster
There was a problem hiding this comment.
Yes but we're not talking about simultaneous pods right? So for example in a cluster that has batch jobs we create new pods all the time (that are short lived). Could this potentially be a problem?
This doesn't have to be fixed now as it's an edge case but might be worth at least understanding if it's possible
There was a problem hiding this comment.
Yes, that might be the edge case. 65k is the number of pods per node - not cluster. But true, if we have a lot of short-living pods their configuration is placed in the map and if we have a pod without any traffic(even healthcheck) it might cause this.
Looks like
fexitandfenterare not supported on arm64I've also tried to run an example application with fenter/fexit and it didn't work. I've created a macro that depends on the architecture use for arm64
kretprobeand for othersfexit.bpftrace/bpftrace#1833