forgot to add [LSF/MM/BPF TOPIC] prefix, sorry, will re-send. On Tue, Jan 21, 2020 at 3:56 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > Re-thinking BPF logging > ======================= > > BPF historically had a very restricted logging capabilities through > bpf_printk macro. It's almost never used in production due to its > limitations and because of how heavy-weight it is. BPF developers > would just sprinkle few logging statements here and there while > debugging issue, and will immediately remove them once they are done. > But real-world production BPF applications need easy-to-use and > flexible logging capabilities, both for debugging at scale in > production, as well as for ad-hoc local development needs. Its hard to > anticipate what needs to be logged in case of production issue, so > logging has to be shipped with production version of BPF application, > but enabled whenever issue arises. BPF needs to re-think its logging > approach to satisfy real-world needs: zero-overhead when disabled, > low-overhead and reliable while turned on. All this without > sacrificing code clarity and developer productivity. We pose that with > all the recent BPF advancements (BTF, global variables, BPF text > poking, etc), it's now possible to have a qualitatively different > logging capabilities in a modern BPF application. > > -- Andrii
