[LSF/MM/BPF TOPIC] Re-thinking BPF logging

[LSF/MM/BPF TOPIC] Re-thinking BPF logging

[Andrii Nakryiko]

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