Uploaded image for project: 'Network Observability'
  1. Network Observability
  2. NETOBSERV-1987

Find a durable way to tackle eBPF stack size issues

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • eBPF
    • None
    • False
    • None
    • False

      When developing new features in the eBPF agent, we often have to tackle stack size errors such as:

      time="2024-11-22T09:17:35Z" level=info msg="Verifier error: load program: permission denied:\n\tcombined stack size of 5 calls is 544. Too large\n\tprocessed 14389 insns (limit 1000000) max_states_per_insn 18 total_states 1182 peak_states 552 mark_read 41" component=ebpf.FlowFetcher
      time="2024-11-22T09:17:35Z" level=fatal msg="can't instantiate NetObserv eBPF Agent" error="loading and assigning BPF objects: field TcEgressFlowParse: program tc_egress_flow_parse: load program: permission denied: combined stack size of 5 calls is 544. Too large (1 line(s) omitted)"
      

      This is likely due to adding more and more stuff in the BPF maps.

      We should find a durable way to fix this problem to avoid the pain in every new feature.

      For instance, an idea could be to split maps into more chunks. Things like DNS info, Drops info, Network Events, etc. don't have to be in the main flow maps, especially as they are optional features. Split data could be merged back from user space. This should not only fix the stack size issue but also reduce memory consumption when those features aren't used.

              Unassigned Unassigned
              jtakvori Joel Takvorian
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: