I'd be interested to participate in the BPF track to discuss the following topics on BPF, motivated from recent experiences in building Cilium and a Go eBPF library. * Improving verifier friendliness. Cilium generates complex BPF programs which can trigger poor verifier behaviour, eg. a program would be rejected unless we provided a log buffer of 64MB[0]. Would like to discuss improvements here like allowing the verifier to treat the user buffer as a ring buffer via opt-in flag, so that users can bound the verifier log size and capture only the last N relevant bytes of verification failure. * Improving the map iteration interactions. During development of cilium/ebpf go library, we hit issues defining a clean API providing guarantees around iteration bounding and completeness of dump[1]. These could be improved via kernel extension, such as opt-in ability to detect when dumping next key leads to iteration reset to beginning of map. Also interested in potential for kernel assistance on LRU eviction handling. * Development of pure-Go eBPF library. Depending on the audience appetite this could be hallway track but syncing on library status, next steps, kernel API pain points. * Any further updates on socket redirection following LPC discussions. Detail unclear given that this is in flux. * Future of BPF interaction with other subsystems / unstable BPF helpers API per recent discussion on the list.[2] [0] https://github.com/cilium/cilium/issues/9809 , https://github.com/cilium/cilium/issues/7770#issuecomment-558343180, other PRs. [1] https://github.com/cilium/ebpf/pull/11 [2] https://www.spinics.net/lists/netdev/msg628451.html
