Investigate better eBPF approach(s)

[ariasmn]

Right now, the approach that strait follows is:

• Create a main cgroup called strait, which has multiple child cgroups with the PID, which are the ones that the BPF programs handle.
• Two BPF programs of type BPF_PROG_TYPE_CGROUP_SKB, one for ingress and another for egress. These two attach to each cgroup and handle the limiting.

This approach has a problem which is (if I understood correctly by reading the docs) that whenever we limit a PID, it create a new instance/maps to be attached to each cgroup. I also started with the idea of having a single cgroup under strait using a lookup shared BPF map, which should be easy, but kept on getting problems, and also saw that the bpf_get_current_pid_tgid is only from kernel 6.10 onwards, which doesn't work for me since I still have a Bookworm machine with kernel 6.1 (that I need to update, I know 🥲 ).

There's a better approach for sure, but since I'm still learning about eBPF I need to investigate lots of stuff, like BPF_PROG_TYPE_NETFILTER and BPF_PROG_TYPE_SCHED_CLS.

The only thing that I need to do is:

• Per PID limits
• Interface agnostic (for now I don't want to mess with different limits per interface)
• Different values for egress/ingress

[ariasmn]

I have been taking a look and making some prototyping and I'll be moving forward with the current approach for now.

When I started this, my idea was to mimic what you could do with net_cls, which is way I relied on cgroups. Current approach works ok, and it's true that maybe it's inefficient (2x BPF programs + 2x BPF maps per PID limited). I took a look using bpftool and, if I understood correctly, my programs + maps per PID take around ~8.6KB of memory (I read that memlock is what we need to use if we want to understand the actual memory footprint):

115: cgroup_skb  name egress_rate_limit  tag 8cc5821cc0b6694c  gpl
    loaded_at 2026-01-31T12:21:09+0100  uid 0
    xlated 488B  jited 320B  memlock 4096B  map_ids 37,38
    btf_id 140
116: cgroup_skb  name ingress_rate_limit  tag 67358864b70fb296  gpl
    loaded_at 2026-01-31T12:21:09+0100  uid 0
    xlated 464B  jited 303B  memlock 4096B  map_ids 37,38
    btf_id 140
---------------------------------------------------------------------------------------------------------------
37: array  name rate_limits  flags 0x0
    key 4B  value 8B  max_entries 2  memlock 320B
    btf_id 140
38: array  name rate_state  flags 0x0
    key 4B  value 16B  max_entries 2  memlock 336B
    btf_id 140

To mention what I've gathered (sadly documentation related to eBPF and Linux networking is somewhat hard to find, or probably it's just skill issue on my side 😞 ):

• BPF_PROG_TYPE_NETFILTER: The only hook that works in process context is NF_INET_LOCAL_OUT, which means that I'd need to track the ingress traffic somehow using the data from the egress traffic.
• BPF_PROG_TYPE_SCHED_CLS / SCHED_ACT: attach to network interfaces, and works on softirq context, thus no process information there.
• BPF_PROG_TYPE_XDP: works on ingress and in the earliest point of the whole network stack, don't think there's a way to track PID here.

Other options maybe are using socket programs, but seems to be quite complex and maybe not worth the effort. Other option I haven't look into is using probes, but I don't think that those are suitable for rate limiting and should be solely used for tracing.

Anyway, if someone with more knowledge about eBPF/Linux comes across this, I'd appreciate some feedback around this quick investigation, letting me know if there's something wrong about my assumptions and also explaining if there's a better way of achieving what I want to achieve.