Bytecode optimizations

[qdeslandes]

Catch-all task to improve the efficiency of bpfilter-generated bytecode, some ideas:

• Do not use dynamic pointers if not-needed
• Prevent unused protocols pre-processing
• Limit logged data size

bfoptimizer can be leveraged to explore specific optimizations.

[javierhonduco]

Do not use dynamic pointers if not-needed

I am interested in this but from another angle. Most of the dynamic pointer features require very modern kernels. This is not a problem for Facebook engineers since the kernels you run are very modern but can make running bpfilter in other environments very hard. Would be great to make this a runtime flag using .rodata or a compilation option

[qdeslandes]

Do not use dynamic pointers if not-needed

I am interested in this but from another angle. Most of the dynamic pointer features require very modern kernels. This is not a problem for Facebook engineers since the kernels you run are very modern but can make running bpfilter in other environments very hard. Would be great to make this a runtime flag using .rodata or a compilation option

That's a very valid argument. Do you have a specific use case in mind, or is it more of a generic comment? The dynamic pointers kfunc we use (e.g. bpf_dynptr_slice) have been introduced in v6.4. I have a prototype without dynptrs, but it won't solve two things:

• Netfilter hooks would not be supported on a kernel without dynamic pointers (required by design)
• Other features or kfuncs could be blocking if we want to run on older kernel (bpf_ringbuf_* for logging requires 5.8, bpf_probe_read_kernel also for logging requires 5.5, without logging 4.8 could be compatible)

[javierhonduco]

That's a very valid argument. Do you have a specific use case in mind, or is it more of a generic comment?

Yes, running in RHEL / AlmaLinux 9 machines, or compatible. Don't believe what uname tells you, it has tons of BPF backports. They seem to support the following dyn_ptr helpers:

• bpf_dynptr_from_mem
• bpf_ringbuf_reserve_dynptr
• bpf_ringbuf_submit_dynptr
• bpf_ringbuf_discard_dynptr
• bpf_dynptr_read
• bpf_dynptr_write
• bpf_dynptr_data

bpf_ringbuf_* and bpf_probe_read_kernel won't be a problem, I believe they were added in RHEL / AlmaLinux 8, and I use both without any issues

[qdeslandes]

That's a very valid argument. Do you have a specific use case in mind, or is it more of a generic comment?

Yes, running in RHEL / AlmaLinux 9 machines, or compatible. Don't believe what uname tells you, it has tons of BPF backports. They seem to support the following dyn_ptr helpers:

• bpf_dynptr_from_mem
• bpf_ringbuf_reserve_dynptr
• bpf_ringbuf_submit_dynptr
• bpf_ringbuf_discard_dynptr
• bpf_dynptr_read
• bpf_dynptr_write
• bpf_dynptr_data

Yes, we should not rely on the kernel version too much, but probably probe the kernel dynamically (libbpf does it IIRC).

bpf_ringbuf_* and bpf_probe_read_kernel won't be a problem, I believe they were added in RHEL / AlmaLinux 8, and I use both without any issues

There is an opt branch on my fork with a lot of bytecode generation optimizations, including removing dynamic pointers for XDP. Would you be able to try it out? All tests are green on this branch, so we don't expect any broken behaviour. If you can use bpfilter from this branch, we can fast track a review and merge of the dynptr-less XDP, and apply it to TC and cgroup hooks too.

[javierhonduco]

Thanks for the pointer. Just checked it locally but it still fails due to not having support for bpf_dynptr_slice. I believe this is still present in the source code.

Built it based off:

commit 42671a7bf9477eca2aa95e370b6845150ee41a21 (HEAD -> opt, quentin/opt)
Author: Quentin Deslandes <qde@naccy.de>
Date:   Tue Jul 7 15:30:40 2026 +0200

    cgen: pin flavor context in r6 on no-parse chains

[qdeslandes]

Looking deeply into this, there's a bit more work than expected, I'll have to dedicate a bit more effort to it. I'll update this issue when I've made some progress :)