Re: [RFC PATCH bpf-next 0/4] bpf: Introduce bpf_netpoll

[Martin KaFai Lau <martin.lau@linux.dev>]

On 3/9/26 6:16 AM, Mahe Tardy wrote:
> This patch series introduces bpf_netpoll, a set of BPF kfuncs that allow
> BPF programs to send UDP packets via the netpoll infrastructure. This
> provides a mechanism for BPF programs (e.g., LSM hooks) to emit
> telemetry over UDP without depending on the regular networking stack.
> 
> For reference, this was discussed at LSF/MM/BPF 2025[^1] in Montreal,
> and again at Plumbers 2025 in Tokyo. Liam Wisehart mentioned this work
> during his presentation of BpfJailer[^2].
> 
> The main use case is to be able to completely dispense with
> agents/daemons for BPF programs after startup. In the case of
> Isovalent's Tetragon, the idea would be to be able to emit security
> alerts or export data from BPF even when the agent is down. For meta,
> according to Liam presentation[^2], this could replace logging via
> ringbuffers which created cross-binary versioning issues.
> 
> The implementation follows the established kfunc lifecycle pattern
> (create/acquire/release with refcounting, kptr map storage, dtor
> registration), for example used by the network bpf_crypto kfuncs.
> 
> Further patches would extend the bpf_netpoll_send kfunc to more program
> types. Note that network program types should not encounter recursion
> issues as netpoll bypasses the network stack and sends directly to the
> driver.

netpoll may be an easy replacement for bpf_ringbuf_output, which can be 
used in different running contexts. If it is to replace the user space 
daemon in production, it loses too many things from the networking 
stack: routing, tc, etc. It could escape the current tc/tracing bpf 
prog, monitoring, QoS marking, qdisc, etc. There is still the encryption 
piece as well.