Introduce the DEFINE_STATIC_KEY() and bpf_static_branch_{unlikely,likely}
macros to mimic Linux Kernel Static Keys API in BPF.
Example of usage would be as follows:
DEFINE_STATIC_KEY(key);
void prog(void)
{
if (bpf_static_branch_unlikely(key))
/* rarely used code */
else
/* default hot path code */
}
or, using the likely variant:
void prog(void)
{
if (bpf_static_branch_likely(key))
/* default hot path code */
else
/* rarely used code */
}
The "unlikely" version of macro compiles in the code where the
else-branch (key is off) is fall-through, the "likely" macro
prioritises the if-branch.
Both macros push an entry in the new ".static_keys" section, which
contains the following information:
32 bits 32 bits 64 bits
offset of jump instruction | offset of jump target | flags
The corresponding ".rel.static_keys" relocations table entry contains
the static key name. This information is enough to construct corresponding
INSN_SET maps.
NOTE. This is an RFC version of the patch. The main design flow of it
is what to do when a static key is used in a noinline function and/or
in two BPF programs. Consider the following example:
DEFINE_STATIC_KEY(key);
static __noinline foo()
{
if (bpf_static_key_unlikely(&key)) {
/* do something special */
}
...
}
SEC("xdp")
int prog1(ctx) {
foo();
...
}
SEC("xdp")
int prog2(ctx) {
foo();
...
}
The problem here is that when such an ELF object is parsed and loaded
by libbpf, then, from the kernel point of view, two programs are
loaded: prog1 + a copy of "foo", then prog2 + a copy of "foo".
However, the static key "key" can only be used in one program (and,
of course, it will point to different instructions in both cases, as
prog1/prog2 have different sizes + there might be more relocations).
The solution is to actually create private copies of the key "key"
per "load object". This automatically allows to reuse the "same"
static key for multiple programs.
