Lines Matching refs:programs
19 * [Building eBPF programs](#building-ebpf-programs)
36 features. While BPF programs are originally intended to run in the kernel, the
38 it contains an interpreter, an x86_64 JIT-compiler for eBPF programs, as well as
120 * `struct EbpfVmFixedMbuff` has one purpose: enabling the execution of programs
130 * `struct EbpfVmRaw` is for programs that want to run directly on packet data.
209 useful for programs that should be compatible with the Linux kernel and
278 // Instantiate a struct EbpfVmNoData. This is an eBPF VM for programs that
306 // This is an eBPF VM for programs reading from a given memory area (it
386 `sk_buff` used by eBPF programs in the kernel, without having to manually
387 create a new buffer for each packet. It may be useful for programs compiled for
443 // This is an eBPF VM for programs using a virtual metadata buffer, similar
444 // to the sk_buff that eBPF programs use with tc and in Linux kernel.
466 ## Building eBPF programs
468 Besides passing the raw hexadecimal codes for building eBPF programs, two other
537 The other way to build programs is to chain commands from the instruction
540 programs this way, it works just as well. If we take again the same sample as
608 * Some constants, such as the maximum length for programs or the length for the
622 * As for performance: theoretically the JITted programs are expected to run at
624 than rbpf. But this has not been asserted yet. Benchmarking both programs
629 No. This crate only works with extended BPF (eBPF) programs. For cBPF programs,
636 Running and JIT-compiling eBPF programs work. There is also a mechanism to
650 in the kernel (if on Linux), to communicate with in-kernel eBPF programs for
658 kernel verifier, which means that it accepts programs that may not be safe. On
685 should not be a problem for the majority of eBPF programs.
693 * Improve safety of JIT-compiled programs with runtime memory checks.
696 * Improve verifier. Could we find a way to directly support programs compiled